From nobody Thu Feb 1 15:04:26 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7046212F29B; Thu, 1 Feb 2018 15:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gQy4ha05Tb9m; Thu, 1 Feb 2018 15:04:21 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6309B12F280; Thu, 1 Feb 2018 15:04:20 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id g21so20743887wrb.13; Thu, 01 Feb 2018 15:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S1bJWXry7T1fXKZY1QPGHlRK1pFWDOTQw6HnUaDZjtA=; b=p3dMQi1K7RKQJ1ohWHdWV32eOIUoIWxSZgye5UfAEkza5VQC5cUa1zmE73j2ZRT+yM gdL5VZwcMv0u/mLW9lTzsh9xygHn1fe5aNqI0t5sLyO1kMi3xD/O7dUMUknV9k361pA5 L7UIdHt/9PnwlHtCl6EnSglUMkGibhB+eMZpqojhDEarNbzLBiMyQ4gLUdIuFDWFJdSn 2QhBXczOWnik55IS07q79ISz5Qgc43kFyNGa8UWpytiayhQCNdOCUFGBKSBW7YcqQzhs zhZrCoq4mOBxpKQIysYk3vEXbhXE/ui41HdaPBV8bMEfKqQUf8p3seamWyTOzGT6IrxG kwxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S1bJWXry7T1fXKZY1QPGHlRK1pFWDOTQw6HnUaDZjtA=; b=U21JW2tVxAXDzqVItmf96AVdE+PKjcpC/SdgUbL0BR6pn2wAoCBKAVMo48p0LIBvba dlgnyxsB/g+NdYo7L4g7YQTpv7ZCawgJ0BDxFtwVnyjtUiUepYaW/fSwTkuXkglngHwb VkcqhyD57bnKBeZjm6JKoCh5tbh3nO6RBegdNBSfXtvfwEOYgh7k7Y4xv1DqJiPg3i9A tNXzJRC8j83vErF15RKB2pWrTgi1aMlynzQshqIvP1K5EDrfVoY4XqVMtWR54GnaE3Z/ F257yifVL957+nMEpozQLLBOtwE8t3ys68GPBPQ1ko2gKaIl0VSszF5Kvdmk+Ucs0q7S Kr9w== X-Gm-Message-State: AKwxytdcw9ypaTx6a2/CcskOLys8Cha9ljA6z6zeP508wY/S6hmkIF5F /dyc9FCTROuPOiMfSB3fo+GGddz5Td21x5bGFwA= X-Google-Smtp-Source: AH8x224oGsr239M3yF6QEtStakw1n1ks13+WWmmzYJ4EfeOqtVus2PLUOYBm6VxWtisi7ba3EtVr0i/+sX/r5V971DM= X-Received: by 10.223.178.9 with SMTP id u9mr29493757wra.149.1517526258814; Thu, 01 Feb 2018 15:04:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.37.135 with HTTP; Thu, 1 Feb 2018 15:04:18 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> From: Subir Das Date: Thu, 1 Feb 2018 18:04:18 -0500 Message-ID: To: Christer Holmberg Cc: Adam Roach , STIR Chairs , "stir@ietf.org" , "draft-ietf-stir-rph.all@tools.ietf.org" Content-Type: multipart/alternative; boundary="f403045eaca898160605642e9d7a" Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 23:04:25 -0000 --f403045eaca898160605642e9d7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Christer, The signing entity does not have always the authority to assert the caller identity in rph. We are submitting ver-03 draft and it is clarified as follows: "The credentials (e.g., authority responsible for authorizing Resource-Priority) used to create the signature must have authority over the namespace of the=E2=80=9Crph" claim.." -Subir On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Another question for clarification. > > > > Section 3 contains the following example: > > > > { "orig":{"tn":"12155551212 <(215)%20555-1212>"} > > "dest":{["tn":"12125551213 <(212)%20555-1213>"]}, > > "iat":1443208345, > > "rph":{"auth":["ets.0","wps.0"]} > > > > =E2=80=A6and the following text: > > > > =E2=80=9CThe credentials (e.g., authority responsible for authorizing = Resource- > > Priority) used to create the signature must have authority over the > > "rph" claim=E2=80=A6=E2=80=9D > > > > Since the claim also contains =E2=80=9Corig=E2=80=9D, is the assumption t= hat the signing > entity always also has authority to assert the callers identity? I think = it > would be good to explicitly mention it. > > > > Regards, > > > > Christer > > > > > > > > > > > > > > *From:* stir [mailto:stir-bounces@ietf.org] *On Behalf Of *Adam Roach > *Sent:* 20 January 2018 00:15 > *To:* STIR Chairs ; stir@ietf.org; > draft-ietf-stir-rph.all@tools.ietf.org > *Subject:* [stir] AD Review: draft-ietf-stir-rph-02 > > > > I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who > has worked on this document, and the authors and chairs in particular. > > The technical content here looks generally good to me. I'd like to see a > few issues addressed before IETF LC. In short sumary: > > - The validation section needs to add a discussion of how to treat > calls when the priority values in "rph" passports and SIP > "Resource-Priority" header fields aren't 100% identical. > - The examples need some adjustment. > - There is a minor point of ambiguity in the Security Section, but > this should be easy to fix, as long as the WG knows what was intended. > - The IANA actions need a little bit of adjustment. > - There are a number of minor editorial issues to be cleaned up. > > Detailed comments on these points are inline in the document below. I've > removed some portions of the document on which I have no comments. > > > > > Abstract > > This document extends the STIR PASSporT specification to allow the > > > > "...the Secure Telephone Identity Revisited (STIR) Personal Assertion > Token (PASSporT) specification defined in RFC 8122..." > > (See > for guidance > on abbreviations) > > > > inclusion of cryptographically-signed assertions of authorization for > the values populated in the SIP 'Resource-Priority' header field, > which is used for communications resource prioritization. > > ... > > 1. Introduction > > PASSporT [I-D.ietf-stir-passport] is a token format based on JWT > [RFC7519] for conveying cryptographically-signed information about > the identities involved in personal communications; it is used with > STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the > identity of the participants in real-time communications established > via a protocol like SIP. This specification extends PASSporT to > > > > "...like SIP [RFC3261]..." > > (We want to cite SIP the first time it is mentioned) > > > > allow cryptographic-signing of the SIP 'Resource-Priority' header > field defined in [RFC4412]. > > [RFC4412] defines the SIP 'Resource-Priority' header field for > communications Resource Priority. As specified in [RFC4412], the > 'Resource-Priority' header field may be used by SIP user agents > [RFC3261], including, Public Switched Telephone Network (PSTN) > > > > "...including Public Switched..." > > (remove the comma) > > > > gateways and terminals, and SIP proxy servers to influence > > > > "...and by SIP proxy servers, to influence..." > > (add "by" and comma) > > > > prioritization afforded to communication sessions,including PSTN > > > > "...sessions, including..." > > (space after comma) > > > > calls. However, the SIP 'Resource-Priority' header field could be > spoofed and abused by unauthorized entities. > > The STIR architecture [RFC7340]assumes that an authority on the > > > > "...STIR architecture [RFC7340] assumes..." > > (space before "assumes") > > > > originating side of a call provides a cryptographic assurance of the > validity of the calling party number in order to prevent > impersonation attacks. The STIR architecture allows extension that > > > > "...allows extensions..." > > > > can be utilized by authorities supporting real-time communication > services using the 'Resource-Priority' header field to > cryptographically sign the SIP 'Resource-Priority' header field and > convey assertion of the authorization for 'Resource-Priority'. For > example, the authority on the originating side verifying the > authorization of a particular communication for Resource-Priority can > > > > Single quotes around 'Resource-Priority'. > > > > use a PASSPorT claim to cryptographically-sign the SIP 'Resource- > > > > "...cryptographically sign..." > > > > Priority' header field and convey an assertion of the authorization > for 'Resource-Priority'. This will allow a receiving entity > (including entities located in different network domains/boundaries) > to verify the validity of assertions authorizing Resource-Priority. > > > > Single quotes around 'Resource-Priority'. > > > > Cryptographically-signed SIP 'Resource-Priority' headers will allow a > > > > "...cryptographically signed SIP 'Resource-Priority' header fields..." > > (remove hyphen, and replace "headers" with "header fields") > > > > receiving entity to verify and act on the information with confidence > that the information have not been spoofed or compromised. > > > > "...has not been spoofed or compromised." > > > > > This specification documents an optional extension to PASSporT and > the associated STIR mechanisms to provide a function to sign the SIP > 'Resource-Priority' header field. This PASSporT object is used to > provide attestation of a calling user authorization for priority > communications. This is necessary in addition to the PASSporT object > that is used for calling user telephone number attestation. How the > optional extension to PASSporT is used for real-time communications > supported using SIP 'Resource-Priority' header field is defined in > other documents and is outside the scope of this document. > > > > I assume these other documents are under development? If so, they should > be cited here. > > > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > > > This document has several non-normative uses of "must", "should," and > "may," and so it needs to use the RFC8174 boilerplate instead of the > RFC2119 boilerplate. > > > > > 3. PASSporT 'rph' Claim > > This specification defines a new JSON Web Token claim for "rph", > which provides an assertion for information in SIP 'Resource- > Priority'header. > > > > "...Priority' header field." > > (space after closing quotation mark, "header field" instead of "header") > > > > > The creator of a PASSporT object adds a "ppt" value of "rph" to the > header of a PASSporT object, in which case the PASSporT claims MUST > contain a "rph" claim, and any entities verifying the PASSporT object > will be required to understand the "ppt" extension in order to > process the PASSporT in question. A PASSPorT header with the "ppt" > included will look as follows: > > { "typ":"passport", > "ppt":"rph", > "alg":"ES256", > "x5u":"https://www.example.org/cert.cer" > } > > > > Ideally, this would be either pretty-printed or canonicalized. Since it's > too long to fit on a line in canonical form, I propose: > > { > "typ":"passport", > "ppt":"rph", > "alg":"ES256", > "x5u":"https://www.example.org/cert.cer" > > } > > > > > The "rph" claim will provide an assertion of authorization,"auth", > > > > "...authorization, "auth", ..." > > (space between comma and opening quotation mark) > > > > for information in the SIP "Resource-Priority" header field (i.e., > Resource-Priority: namespace "." r-priority) based on [RFC4412]. > > > > The use of the string 'namespace "." r-priority' here and elsewhere in th= e > document has a detrimental impact on readability. I strongly suggest > replacing it with "r-value" (the name of this production in RFC4412) > everywhere. > > > > Specifically, the "rph" claim includes assertion of the priority- > level of the user to be used for a given communication session. The > value of the "rph" claim is an array containing one or more of JSON > objects for the content of the SIP 'Resource-Priority' header that is > being asserted of which one of the "rph" object, is mandatory. > > > > This last sentence is very hard to parse; and (based on the example) the > value is intended to be a JSON Object (curly braces) rather than a JSON > Array (square braces). I suggest: 'The value of the "rph" claim is an > Object with one or more keys. Each key is associated with a JSON Array. > These arrays contain Strings that correspond to the r-values indicated in > the SIP "Resource-Priority" header field.' (note: "header field", not > "header") > > > > > The following is an example "rph" claim for a SIP "Resource-Priority" > header field with a "namespace "." r-priority" value of "ets.0" and > with a "namespace "." r-priority" value of "wps.0". > > { "orig":{"tn":"12155551212 <(215)%20555-1212>"} > "dest":{["tn":"12125551213 <(212)%20555-1213>"]}, > "iat":1443208345, > "rph":{"auth":["ets.0","wps.0"]} > > > > As above, I recommend pretty-printing this. It's also missing a comma > after the "orig" value, and the top-level structure is missing a closing > brace. The value for "iat" needs to be enclosed in quotes. > > The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much > of which remains assignable (cf com/pdf/NRUF/ATIS-0300115.pdf> > ). > > Putting all this together, I believe what you want is: > > { > "orig":{"tn":"12155550112 <(215)%20555-0112>"}, > "dest":{["tn":"12125550113 <(212)%20555-0113>"]}, > "iat":"1443208345", > "rph":{"auth":["ets.0","wps.0"]} > } > > > > > After the header and claims PASSporT objects have been constructed, > their signature is generated normally per the guidance in > [I-D.ietf-stir-passport] using the full form of PASSPorT. The > credentials (e.g., authority responsible for authorizing Resource- > Priority) used to create the signature must have authority over the > "rph" claim and there is only one authority per claim. The authority > MUST use its credentials (i.e., CERT) associated with the specific > service supported by the SIP namespace in the claim. > > 4. 'rph' in SIP > > This section specifies SIP-specific usage for the "rph" claim in > PASSporT. > > 4.1. Authentication Service Behavior > > The Authentication Service will create the "rph" claim using the > values discussed in section 3 based on [RFC4412]. The construction > of "rph" claim follows the steps described in Section 4 of > [I-D.ietf-stir-rfc4474bis]. > > The resulting Identity header for "rph" might look as follows: > > > > "...header field..." > > > > > "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd > ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO > aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW > EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW > pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR > VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z > aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D > l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ > oos2P2Dyw"; info=3D "https://www.example.org/cert.cer" > ;alg=3DES256; > ppt=3D"rph" > > > > This example has a number of issues: > > - In the Identity header field, the signed-identity-digest shouldn't > be quoted. > - In the Identity header field, info is enclosed in <> rather than "". > - In the Identity header field, ppt is a token rather than a quoted > string. > - The signed-identity-digest header needs to indicate a "typ" of > "passport" rather than JWT, and it needs to include both a "ppt" and "= x5u" > field. > - The signed-identity-digest body should contain only the passport > claim rather than a JSON object that itself contains a base64-encoded = JWS > header concatenated with a claim. > - I believe that, even when the body is included, values in the header > and body need to be be canonicalized (i.e., all on one line, no spaces= , in > alphabetical order, etc.) > > I would also recommend following the convention of indicating that > line-wraps are only for readability, and including the header field name = in > the example. Putting all this together, I believe what you want is: > > For example, a Identity header field for "rph" might look > as follows (backslashes shown for line folding only): > > Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ > iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ > Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ > 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ > AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ > 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D >;alg=3DES256;ppt=3Drph > > (Note: this example assumes the calling and called party numbers in the > previous example are changed to 12155550112 <(215)%20555-0112> and > 12155550113 <(215)%20555-0113>, respectively) > > > > > A SIP authentication service typically will derive the value of "rph" > from the 'Resource-Priority' header field based on policy associated > with service specific use of the "namespace "." r-priority" values > based on [RFC4412]. The authentication service derives the value of > the PASSPorT claim by verifying the authorization for Resource- > Priority (i.e., verifying a calling user privilege for Resource- > Priority based on its identity) which might be derived from customer > profile data or from access to external services. > > [RFC4412] allows multiple "namespace "." r-priority" pairs, either in > a single SIP Resource-Priority header or across multiple SIP > > > > Single quotes around 'Resource-Priority'. > > "...header field..." > > > > Resource-Priority headers. However, it is not necessary to sign all > > > > Single quotes around 'Resource-Priority'. > > "...header fields..." > > > > content of a SIP Resource-Priority header or all SIP Resource- > > > > Single quotes around 'Resource-Priority'. > > "...header field..." > > > > Priority headers in a given SIP message. An authority is only > > > > Single quotes around 'Resource-Priority'. > > "...header fields..." > > > > responsible for signing the content of a SIP Resource-Priority header > > > > Single quotes around 'Resource-Priority'. > > "...header field..." > > > > for which it has authority (e.g., a specific "namespace "." > r-priority"). > > 4.2. Verification Service Behavior > > [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that > specifications defining "ppt" values describe any additional verifier > behavior. The behavior specified for the "ppt" values of "rph" is as > follows: > > The verification service MUST extract the value associated with the > "auth" key in a full form PASSPorT with a "ppt" value of "rph". If > the signature validates, then the verification service can use the > value of the "rph" claim as validation that the calling party is > authorized for Resource-Priority, which would in turn be used for > > > > Single quotes around 'Resource-Priority'. > > This text is ambiguous about whether the validation indicates that the > calling party is authorized to use the priorities indicated in the passpo= rt > object, or the values in the SIP 'Resource-Priority' header field; and > (taken on its face) implies the latter, when the intention here should > clearly be the former. > > "...authorized for 'Resource-Priority' indicated in the claim. This value > would in turn be used for..." > > The text also needs to say something about comparing values in the claim > to values in the 'Resource-Priority' header field, and what a mismatch > might mean. The document says elsewhere that the signature might only cov= er > some of the r-values, which makes it entirely possible that the > 'Resource-Priority' field might contain more values than are signed. On t= he > other hand, intermediaries might reasonably remove r-values as the call i= s > processed. This probably means that those removed priorities should not b= e > used, even if they are present in the passport. It seems reasonable to sa= y > that *typical* processing by a receiving party would be to take the *unio= n* > of all RPH passports that they trust, and *intersect* that with the > priorities in 'Resource-Priority' header fields to get the actual priorit= y > or priorities to be applied to the call (subject to local policy). > > > > priority treatment in accordance with local policy for the associated > communication service. > > In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires > "iat" value in "rph" claim to be verified. > > The behavior of a SIP UAs upon receiving an INVITE containing a > > > > "...of a SIP UA upon..." > > or > > "...of SIP UAs upon..." > > > > PASSporT object with a "rph" claim will largely remain a matter of > implementation policy for the specific communication service. In > most cases,implementations would act based on confidence in the > > > > "...cases, implementations..." > > (space after comma) > > > > veracity of this information. The use of the compact form of > > > > Paragraph break before "The". > > > > PASSporT is not specified in this document. > > 5. Further Information Associated with Resource-Priority > > > > Single quotes around 'Resource-Priority'. > > > > > There may be additional information about the calling party or the > call that could be relevant to authorization for Resource-Priority. > > > > Single quotes around 'Resource-Priority'. > > > > This may include information related to the device subscription of > the caller, or to any institutions that the caller or device is > associated with, or even categories of institutions. All of these > data elements would benefit from the secure attestations provided by > the STIR and PASSporT frameworks. The specification of the "rph" > claim could entail the optional presence of one or more such > additional information fields. > > A new IANA registry has been defined to hold potential values of the > "rph" array; see Section 6.2. The definition of the "rph" claim may > have one or more such additional information field(s). Details of > such "rph" claim to encompass other data elements are left for future > version of this specification. > > 6. IANA Considerations > > 6.1. JSON Web Token Claims Registration > > > > I think there's some confusion here. You're registering a PASSporT ppt > value, not a new JWT claim. That is to say, you're adding an entry to thi= s > table: > > https://www.iana.org/assignments/passport/passport.xhtml > > Not to this table: > > https://www.iana.org/assignments/jwt/jwt.xhtml > > You would only use the second table if you had a new key to add to the > PASSporT header -- this specification does not do that. > > This section also needs some introductory text to let the IANA know > exactly what to do; e.g. "This document registers a new value for the > "Personal Assertion Token (PASSporT) Extensions" table. > > > o ppt value: "rph" > > o Specification Document(s): Section 3 of [RFCThis] > > 6.2. PASSporT 'rph' Types > > This document requests that the IANA add a new entry to the PASSporT > Types registry for the type "rph" which is specified in [RFCThis]. > > > > There isn't an IANA table called "PASSporT Types." I presume this is the > registration we just discussed in section 6.1, and so the above two lines > can be removed. > > > > This specification also requests that the IANA create a new registry > for PASSporT "rph" types. Registration of new PASSporT "rph" types > shall be under the specification required policy. This registry is > to be initially populated with a single value for "auth" which is > specified in [RFCThis]. > > > > This needs to be very clear about the fields to be included in this new > registry (e.g., "Registry entries must contain two fields: the name of th= e > 'rph' type and the specification in which the type is described"). > > > > > 7. Security Considerations > > The security considerations discussed in [I-D.ietf-stir-rfc4474bis] > in Section 10 are applicable here. > > 7.1. Avoidance of replay and cut and paste attacks > > The PASSporT extension with a "ppt" value of "rph" MUST only be sent > with SIP INVITE when 'Resource-Priority' header is used to convey the > > > > "...header field..." > > > > priority of the communication as defined in [RFC4412]. To avoid the > replay, and cut and paste attacks, the procedures described in > Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. > > 7.2. Solution Considerations > > The use of extension to PASSporT tokens with "ppt" value "rph" based > on the validation of the digital signature and the associated > certificate requires consideration of the authentication and > authority or reputation of the signer to attest to the identity being > asserted. The following considerations should be recognized when > using PASSporT extension with "ppt" value of "rph": > > o An authority (signer) is only allowed to sign the content of a SIP > 'Resource-Priority' header for which it has the right authority. > > > > "...header field..." > > > > The authority that signs the token MUST have a secure method for > authentication of the end user or the device. > > o The verification of the signature MUST include means of verifying > that the signer is authoritative for the signed content of the SIP > > > > It's not clear what authority is being claimed here. Is this supposed to > mean something like "...verifying that the signer is authoritative for th= e > originating tn in the PASSporT..."? Or "...authoritative for the resource > priority namespace in the PASSporT?" Whatever the server is purportedly > authoritative for needs to be clearly spelled out. > > > > 'Resource-Priority' header. > > > > "...header field." > > > > /a > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir > > --f403045eaca898160605642e9d7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Christer,
The signing entity does not= have always the authority to assert the caller identity in rph. We are sub= mitting ver-03 draft=C2=A0 and it is clarified=C2=A0 as follows:
<= div>"The credentials (e.g., authority responsible for authorizing Resource-Priority) used to create the signature must have authority over the namespace of the<= span style=3D"background:yellow none repeat scroll 0% 0%">=E2=80=9Cr= ph" claim.."

<= /div>
-Subir

On Mon, Jan 22, 2018 at 3:27 PM,= Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Another question for clarification.

=C2=A0

Section 3 contains the following exam= ple:

=C2=A0

=C2=A0=C2=A0=C2=A0 { "orig"= :{"tn":"12155551212"}

=C2=A0=C2=A0=C2=A0=C2=A0 "dest&q= uot;:{["tn":"12125551213"]},

=C2=A0=C2=A0=C2=A0=C2=A0 "iat&qu= ot;:1443208345,

=C2=A0=C2=A0=C2=A0=C2=A0 "rph&qu= ot;:{"auth":["ets.0","wps.0"]}=

=C2=A0

=E2=80=A6and the following text:

=C2=A0

=C2=A0=C2=A0 =E2=80=9CThe credentials= (e.g., authority responsible for authorizing Resource-

=C2=A0=C2=A0 Priority) used to create= the signature must have authority over the

=C2=A0=C2=A0 "rph" claim=E2= =80=A6=E2=80=9D

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

Since the claim also contains =E2=80= =9Corig=E2=80=9D, is the assumption that the signing entity always also has= authority to assert the callers identity? I think it would be good to explicitly mention it.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From:= stir [mailto:stir-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ie= tf.org
Subject: [stir] AD Review: draft-ietf-stir-rph-02

=C2=A0

I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone= who has worked on this document, and the authors and chairs in particular.=

The technical content here looks generally good to me. I'd like to s= ee a few issues addressed before IETF LC. In short sumary:

  • The validation section needs to add a discussion of how to treat calls when= the priority values in "rph" passports and SIP "Resource-Pr= iority" header fields aren't 100% identical.
    • The examples need some adjustment.
  • There is a minor point of ambiguity in the Security Section, but this shoul= d be easy to fix, as long as the WG knows what was intended.<= /li>
  • The IANA actions need a little bit of adjustment.
  • There are a number of minor editorial issues to be cleaned up.

Detailed comments on these points are inline in the document below. I= 9;ve removed some portions of the document on which I have no comments.<= /u>

=C2=A0


Abstract

=C2=A0=C2=A0 This document extends the STIR PASSporT specification to a= llow the

=C2=A0

"...the Secure Telephone Identity Revisited (STIR) Personal Asserti= on Token (PASSporT) specification defined in RFC 8122..."

(See <https://www.rfc-editor.org/materials/abbrev.e= xpansion.txt> for guidance on abbreviations)

=C2=A0

=C2=A0=C2=A0 in= clusion of cryptographically-signed assertions of authorization for<= /tt> =C2=A0=C2=A0 the values populated in the SIP 'Resource-Priority'= ; header field,
=C2=A0=C2=A0 which is used for communications resource prioritization.<= /tt>

...

1.=C2=A0 Introduction

=C2=A0=C2=A0 PASSporT [I-D.ietf-stir-passport] is a token format based = on JWT
=C2=A0=C2=A0 [RFC7519] for conveying cryptographically-signed informati= on about
=C2=A0=C2=A0 the identities involved in personal communications; it is = used with
=C2=A0=C2=A0 STIR [I-D.ietf-stir-rfc4474bis] to convey a signed asserti= on of the
=C2=A0=C2=A0 identity of the participants in real-time communications e= stablished
=C2=A0=C2=A0 via a protocol like SIP.=C2=A0 This specification extends = PASSporT to

=C2=A0

"...like SIP [RFC3261]..."

(We want to cite SIP the first time it is mentioned)

=C2=A0

=C2=A0=C2=A0 al= low cryptographic-signing of the SIP 'Resource-Priority' header

=C2=A0=C2=A0 ga= teways and terminals, and SIP proxy servers to influence=

=C2=A0

"...and by SIP proxy servers, to influence..."

(add "by" and comma)

=C2=A0

=C2=A0=C2=A0 pr= ioritization afforded to communication sessions,including PSTN<= u>

=C2=A0

"...sessions, including..."

(space after comma)

=C2=A0

=C2=A0=C2=A0 ca= lls.=C2=A0 However, the SIP 'Resource-Priority' header field could = be
=C2=A0=C2=A0 spoofed and abused by unauthorized entities.

=C2=A0=C2=A0 The STIR architecture [RFC7340]assumes that an authority o= n the

=C2=A0

"...STIR architecture [RFC7340] assumes..."

(space before "assumes")

=C2=A0

=C2=A0=C2=A0 or= iginating side of a call provides a cryptographic assurance of the =C2=A0=C2=A0 validity of the calling party number in order to prevent
=C2=A0=C2=A0 impersonation attacks.=C2=A0 The STIR architecture allows = extension that

=C2=A0

"...allows extensions..."

=C2=A0

=C2=A0=C2=A0 ca= n be utilized by authorities supporting real-time communication=
=C2=A0=C2=A0 services using the 'Resource-Priority' header fiel= d to
=C2=A0=C2=A0 cryptographically sign the SIP 'Resource-Priority'= header field and
=C2=A0=C2=A0 convey assertion of the authorization for 'Resource-Pr= iority'.=C2=A0 For
=C2=A0=C2=A0 example, the authority on the originating side verifying t= he
=C2=A0=C2=A0 authorization of a particular communication for Resource-P= riority can

=C2=A0

Single quotes around 'Resource-Priority'.

=C2=A0

=C2=A0=C2=A0 us= e a PASSPorT claim to cryptographically-sign the SIP 'Resource-<= /tt>

=C2=A0

"...cryptographically sign..."

=C2=A0

=C2=A0=C2=A0 Pr= iority' header field and convey an assertion of the authorization=
=C2=A0=C2=A0 for 'Resource-Priority'.=C2=A0 This will allow a r= eceiving entity
=C2=A0=C2=A0 (including entities located in different network domains/b= oundaries)
=C2=A0=C2=A0 to verify the validity of assertions authorizing Resource-= Priority.

=C2=A0

Single quotes around 'Resource-Priority'.

=C2=A0

=C2=A0=C2=A0 Cr= yptographically-signed SIP 'Resource-Priority' headers will allow a=

=C2=A0

"...cryptographically signed SIP 'Resource-Priority' header= fields..."

(remove hyphen, and replace "headers" with "header fields= ")

=C2=A0

=C2=A0=C2=A0 re= ceiving entity to verify and act on the information with confidence<= /tt> =C2=A0=C2=A0 that the information have not been spoofed or compromised.=

=C2=A0

"...has not been spoofed or compromised."

=C2=A0


=C2=A0=C2=A0 This specification documents an optional extension to PASS= porT and
=C2=A0=C2=A0 the associated STIR mechanisms to provide a function to si= gn the SIP
=C2=A0=C2=A0 'Resource-Priority' header field.=C2=A0 This PASSp= orT object is used to
=C2=A0=C2=A0 provide attestation of a calling user authorization for pr= iority
=C2=A0=C2=A0 communications.=C2=A0 This is necessary in addition to the= PASSporT object
=C2=A0=C2=A0 that is used for calling user telephone number attestation= .=C2=A0 How the
=C2=A0=C2=A0 optional extension to PASSporT is used for real-time commu= nications
=C2=A0=C2=A0 supported using SIP 'Resource-Priority' header fie= ld is defined in
=C2=A0=C2=A0 other documents and is outside the scope of this document.=

=C2=A0

I assume these other documents are under development? If so, they should= be cited here.

=C2=A0


2.=C2=A0 Terminology

=C2=A0=C2=A0 The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
=C2=A0=C2=A0 "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
=C2=A0=C2=A0 document are to be interpreted as described in RFC 2119 [R= FC2119].

=C2=A0

This document has several non-normative uses of "must", "= should," and "may," and so it needs to use the RFC8174 boile= rplate instead of the RFC2119 boilerplate.

=C2=A0


3.=C2=A0 PASSporT 'rph' Claim

=C2=A0=C2=A0 This specification defines a new JSON Web Token claim for = "rph",
=C2=A0=C2=A0 which provides an assertion for information in SIP 'Re= source-
=C2=A0=C2=A0 Priority'header.

=C2=A0

"...Priority' header field."

(space after closing quotation mark, "header field" instead of= "header")

=C2=A0


=C2=A0=C2=A0 The creator of a PASSporT object adds a "ppt" va= lue of "rph" to the
=C2=A0=C2=A0 header of a PASSporT object, in which case the PASSporT cl= aims MUST
=C2=A0=C2=A0 contain a "rph" claim, and any entities verifyin= g the PASSporT object
=C2=A0=C2=A0 will be required to understand the "ppt" extensi= on in order to
=C2=A0=C2=A0 process the PASSporT in question.=C2=A0 A PASSPorT header = with the "ppt"
=C2=A0=C2=A0 included will look as follows:

=C2=A0=C2=A0 {=C2=A0 "typ":"passport",
=C2=A0=C2=A0=C2=A0=C2=A0 "ppt":"rph",
=C2=A0=C2=A0=C2=A0=C2=A0 "alg":"ES256",
=C2=A0=C2=A0=C2=A0=C2=A0 "x5u":"https://www.example.org/cert.ce= r"}

=C2=A0

Ideally, this would be either pretty-printed or canonicalized. Since it&= #39;s too long to fit on a line in canonical form, I propose:=

{
=C2=A0 "typ":"passport",
=C2=A0 "ppt":"rph",
=C2=A0 "alg":"ES256",
=C2=A0 "x5u":"https://www.example.org/cert.cer" }

=C2=A0


=C2=A0=C2=A0 The "rph" claim will provide an assertion of aut= horization,"auth",

=C2=A0

"...authorization, "auth", ..."

(space between comma and opening quotation mark)

=C2=A0

=C2=A0=C2=A0 fo= r information in the SIP "Resource-Priority" header field (i.e.,<= /span>
=C2=A0=C2=A0 Resource-Priority: namespace "." r-priority) bas= ed on [RFC4412].

=C2=A0

The use of the string 'namespace "." r-priority' here = and elsewhere in the document has a detrimental impact on readability. I st= rongly suggest replacing it with "r-value" (the name of this prod= uction in RFC4412) everywhere.

=C2=A0

=C2=A0=C2=A0 Sp= ecifically, the "rph" claim includes assertion of the priority-
=C2=A0=C2=A0 level of the user to be used for a given communication ses= sion.=C2=A0 The
=C2=A0=C2=A0 value of the "rph" claim is an array containing = one or more of JSON
=C2=A0=C2=A0 objects for the content of the SIP 'Resource-Priority&= #39; header that is
=C2=A0=C2=A0 being asserted of which one of the "rph" object,= is mandatory.

=C2=A0

This last sentence is very hard to parse; and (based on the example) the= value is intended to be a JSON Object (curly braces) rather than a JSON Ar= ray (square braces). I suggest: 'The value of the "rph" claim= is an Object with one or more keys. Each key is associated with a JSON Array. These arrays contain Strings that corresp= ond to the r-values indicated in the SIP "Resource-Priority" head= er field.' (note: "header field", not "header")<= /u>

=C2=A0


=C2=A0=C2=A0 The following is an example "rph" claim for a SI= P "Resource-Priority"
=C2=A0=C2=A0 header field with a "namespace "." r-priori= ty" value of "ets.0" and
=C2=A0=C2=A0 with a "namespace "." r-priority" valu= e of "wps.0".

=C2=A0=C2=A0=C2=A0 { "orig":{"tn":"12155551212<= /a>"}
=C2=A0=C2=A0=C2=A0=C2=A0 "dest":{["tn":"1212555= 1213"]},
=C2=A0=C2=A0=C2=A0=C2=A0 "iat":1443208345,
=C2=A0=C2=A0=C2=A0=C2=A0 "rph":{"auth":["ets.0= ","wps.0"]}

=C2=A0

As above, I recommend pretty-printing this. It's also missing a comm= a after the "orig" value, and the top-level structure is missing = a closing brace. The value for "iat" needs to be enclosed in quot= es.

The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much= of which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pd= f>).

Putting all this together, I believe what you want is:

{
=C2=A0 "orig":{"tn":"12155550112"},
=C2=A0 "dest":{["tn":"12125550113"]},<= /tt>
=C2=A0 "iat":"1443208345",
=C2=A0 "rph":{"auth":["ets.0","wps.0= "]}
}

=C2=A0


=C2=A0=C2=A0 After the header and claims PASSporT objects have been con= structed,
=C2=A0=C2=A0 their signature is generated normally per the guidance in<= /tt>
=C2=A0=C2=A0 [I-D.ietf-stir-passport] using the full form of PASSPorT.= =C2=A0 The
=C2=A0=C2=A0 credentials (e.g., authority responsible for authorizing R= esource-
=C2=A0=C2=A0 Priority) used to create the signature must have authority= over the
=C2=A0=C2=A0 "rph" claim and there is only one authority per = claim.=C2=A0 The authority
=C2=A0=C2=A0 MUST use its credentials (i.e., CERT) associated with the = specific
=C2=A0=C2=A0 service supported by the SIP namespace in the claim.<= br>
4.=C2=A0 'rph' in SIP

=C2=A0=C2=A0 This section specifies SIP-specific usage for the "rp= h" claim in
=C2=A0=C2=A0 PASSporT.

4.1.=C2=A0 Authentication Service Behavior

=C2=A0=C2=A0 The Authentication Service will create the "rph"= claim using the
=C2=A0=C2=A0 values discussed in section 3 based on [RFC4412].=C2=A0 Th= e construction
=C2=A0=C2=A0 of "rph" claim follows the steps described in Se= ction 4 of
=C2=A0=C2=A0 [I-D.ietf-stir-rfc4474bis].

=C2=A0=C2=A0 The resulting Identity header for "rph" might lo= ok as follows:

=C2=A0

"...header field..."

=C2=A0


=C2=A0=C2=A0 "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.= eyJpc3MiOiJleUowZVhBaU9pSnd
=C2=A0=C2=A0 ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2Np= T2lKRlV6STFO
=C2=A0=C2=A0 aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsT= G1OdmJTOWpaW
=C2=A0=C2=A0 EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNm= V5SjBiaUk2SW
=C2=A0=C2=A0 pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNkl= qRXlNVEkxTlR
=C2=A0=C2=A0 VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNp= SnljR2dpT25z
=C2=A0=C2=A0 aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.= s37S6VC8HM6D
=C2=A0=C2=A0 l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18= vYYFy3blXvs3fslM_
=C2=A0=C2=A0 oos2P2Dyw"; info=3D "https://www.example.org/cert.cer&q= uot;;alg=3DES256;
=C2=A0=C2=A0 ppt=3D"rph"

=C2=A0

This example has a number of issues:

  • In the Identity header field, the signed-identity-digest shouldn't be q= uoted.
  • In the Identity header field, info is enclosed in <> rather than &quo= t;".
  • In the Identity header field, ppt is a token rather than a quoted string.
  • The signed-identity-digest header needs to indicate a "typ" of &q= uot;passport" rather than JWT, and it needs to include both a "pp= t" and "x5u" field.
  • The signed-identity-digest body should contain only the passport claim rath= er than a JSON object that itself contains a base64-encoded JWS header conc= atenated with a claim.
  • I believe that, even when the body is included, values in the header and bo= dy need to be be canonicalized (i.e., all on one line, no spaces, in alphab= etical order, etc.)

I would also recommend following the convention of indicating that line-= wraps are only for readability, and including the header field name in the = example. Putting all this together, I believe what you want is:

=C2=A0=C2=A0 For example, a Identit= y header field for "rph" might look
=C2=A0=C2=A0 as follows (backslashes shown for line folding only):=

=C2=A0=C2=A0 Identity: eyJhbGciOiJF= UzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \
=C2=A0=C2=A0 iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZX= IifQo.eyJkZXN0 \
=C2=A0=C2=A0 Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4M= zQ1Iiwib3JpZyI \
=C2=A0=C2=A0 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0= cy4wIiwid3BzLj \
=C2=A0=C2=A0 AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_9= 8oWBHvo-cl-n8MIhoCr \
=C2=A0=C2=A0 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D<https://www.example.org/<= wbr>cert.cer \
=C2=A0=C2=A0 >;alg=3DES256;ppt=3Drph

(Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550113, respectivel= y)

=C2=A0


=C2=A0=C2=A0 A SIP authentication service typically will derive the val= ue of "rph"
=C2=A0=C2=A0 from the 'Resource-Priority' header field based on= policy associated
=C2=A0=C2=A0 with service specific use of the "namespace ".&q= uot; r-priority" values
=C2=A0=C2=A0 based on [RFC4412].=C2=A0 The authentication service deriv= es the value of
=C2=A0=C2=A0 the PASSPorT claim by verifying the authorization for Reso= urce-
=C2=A0=C2=A0 Priority (i.e., verifying a calling user privilege for Res= ource-
=C2=A0=C2=A0 Priority based on its identity) which might be derived fro= m customer
=C2=A0=C2=A0 profile data or from access to external services.

=C2=A0=C2=A0 [RFC4412] allows multiple "namespace "." r-= priority" pairs, either in
=C2=A0=C2=A0 a single SIP Resource-Priority header or across multiple S= IP

=C2=A0

Single quotes around 'Resource-Priority'.

"...header field..."

=C2=A0

=C2=A0=C2=A0 Re= source-Priority headers.=C2=A0 However, it is not necessary to sign all

=C2=A0

Single quotes around 'Resource-Priority'.

"...header fields..."

=C2=A0

=C2=A0=C2=A0 co= ntent of a SIP Resource-Priority header or all SIP Resource-=

=C2=A0

Single quotes around 'Resource-Priority'.

"...header field..."

=C2=A0

=C2=A0=C2=A0 Pr= iority headers in a given SIP message.=C2=A0 An authority is only

=C2=A0

Single quotes around 'Resource-Priority'.

"...header fields..."

=C2=A0

=C2=A0=C2=A0 re= sponsible for signing the content of a SIP Resource-Priority header<= /tt>

=C2=A0

Single quotes around 'Resource-Priority'.

"...header field..."

=C2=A0

=C2=A0=C2=A0 fo= r which it has authority (e.g., a specific "namespace "."
=C2=A0=C2=A0 r-priority").

4.2.=C2=A0 Verification Service Behavior

=C2=A0=C2=A0 [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires tha= t
=C2=A0=C2=A0 specifications defining "ppt" values describe an= y additional verifier
=C2=A0=C2=A0 behavior.=C2=A0 The behavior specified for the "ppt&q= uot; values of "rph" is as
=C2=A0=C2=A0 follows:

=C2=A0=C2=A0 The verification service MUST extract the value associated= with the
=C2=A0=C2=A0 "auth" key in a full form PASSPorT with a "= ppt" value of "rph".=C2=A0 If
=C2=A0=C2=A0 the signature validates, then the verification service can= use the
=C2=A0=C2=A0 value of the "rph" claim as validation that the = calling party is
=C2=A0=C2=A0 authorized for Resource-Priority, which would in turn be u= sed for

=C2=A0

Single quotes around 'Resource-Priority'.

This text is ambiguous about whether the validation indicates that the c= alling party is authorized to use the priorities indicated in the passport = object, or the values in the SIP 'Resource-Priority' header field; = and (taken on its face) implies the latter, when the intention here should clearly be the former.

"...authorized for 'Resource-Priority' indicated in the cla= im. This value would in turn be used for..."

The text also needs to say something about comparing values in the claim= to values in the 'Resource-Priority' header field, and what a mism= atch might mean. The document says elsewhere that the signature might only = cover some of the r-values, which makes it entirely possible that the 'Resource-Priority' field might cont= ain more values than are signed. On the other hand, intermediaries might re= asonably remove r-values as the call is processed. This probably means that= those removed priorities should not be used, even if they are present in the passport. It seems reasonable to say= that *typical* processing by a receiving party would be to take the *union= * of all RPH passports that they trust, and *intersect* that with the prior= ities in 'Resource-Priority' header fields to get the actual priority or priorities to be applied to the call = (subject to local policy).

=C2=A0

=C2=A0=C2=A0 pr= iority treatment in accordance with local policy for the associated<= /tt> =C2=A0=C2=A0 communication service.

=C2=A0=C2=A0 In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4= requires
=C2=A0=C2=A0 "iat" value in "rph" claim to be verif= ied.

=C2=A0=C2=A0 The behavior of a SIP UAs upon receiving an INVITE contain= ing a

=C2=A0

"...of a SIP UA upon..."

or

"...of SIP UAs upon..."

=C2=A0

=C2=A0=C2=A0 PA= SSporT object with a "rph" claim will largely remain a matter of<= /span>
=C2=A0=C2=A0 implementation policy for the specific communication servi= ce.=C2=A0 In
=C2=A0=C2=A0 most cases,implementations would act based on confidence i= n the

=C2=A0

"...cases, implementations..."

(space after comma)

=C2=A0

=C2=A0=C2=A0 ve= racity of this information.=C2=A0 The use of the compact form of

=C2=A0

Paragraph break before "The".

=C2=A0

=C2=A0=C2=A0 PA= SSporT is not specified in this document.

5.=C2=A0 Further Information Associated with Resource-Priority

=C2=A0

Single quotes around 'Resource-Priority'.

=C2=A0


=C2=A0=C2=A0 There may be additional information about the calling part= y or the
=C2=A0=C2=A0 call that could be relevant to authorization for Resource-= Priority.

=C2=A0

Single quotes around 'Resource-Priority'.

=C2=A0

=C2=A0=C2=A0 Th= is may include information related to the device subscription of
=C2=A0=C2=A0 the caller, or to any institutions that the caller or devi= ce is
=C2=A0=C2=A0 associated with, or even categories of institutions.=C2=A0= All of these
=C2=A0=C2=A0 data elements would benefit from the secure attestations p= rovided by
=C2=A0=C2=A0 the STIR and PASSporT frameworks.=C2=A0 The specification = of the "rph"
=C2=A0=C2=A0 claim could entail the optional presence of one or more su= ch
=C2=A0=C2=A0 additional information fields.

=C2=A0=C2=A0 A new IANA registry has been defined to hold potential val= ues of the
=C2=A0=C2=A0 "rph" array; see Section 6.2.=C2=A0 The definiti= on of the "rph" claim may
=C2=A0=C2=A0 have one or more such additional information field(s).=C2= =A0 Details of
=C2=A0=C2=A0 such "rph" claim to encompass other data element= s are left for future
=C2=A0=C2=A0 version of this specification.

6.=C2=A0 IANA Considerations

6.1.=C2=A0 JSON Web Token Claims Registration=

=C2=A0

I think there's some confusion here. You're registering a PASSpo= rT ppt value, not a new JWT claim. That is to say, you're adding an ent= ry to this table:

https://www.iana.org/assignments/passport/passport.xhtml

Not to this table:

https://www.iana.org/assignments/jwt/jwt.xhtml<= /p>

You would only use the second table if you had a new key to add to the P= ASSporT header -- this specification does not do that.

This section also needs some introductory text to let the IANA know exac= tly what to do; e.g. "This document registers a new value for the &quo= t;Personal Assertion Token (PASSporT) Extensions" table.=


=C2=A0=C2=A0 o=C2=A0 ppt value: "rph"

=C2=A0=C2=A0 o=C2=A0 Specification Document(s): Section 3 of [RFCThis]<= /tt>

6.2.=C2=A0 PASSporT 'rph' Types

=C2=A0=C2=A0 This document requests that the IANA add a new entry to th= e PASSporT
=C2=A0=C2=A0 Types registry for the type "rph" which is speci= fied in [RFCThis].

=C2=A0

There isn't an IANA table called "PASSporT Types." I presu= me this is the registration we just discussed in section 6.1, and so the ab= ove two lines can be removed.

=C2=A0

=C2=A0=C2=A0 Th= is specification also requests that the IANA create a new registry =C2=A0=C2=A0 for PASSporT "rph" types.=C2=A0 Registration of = new PASSporT "rph" types
=C2=A0=C2=A0 shall be under the specification required policy.=C2=A0 Th= is registry is
=C2=A0=C2=A0 to be initially populated with a single value for "au= th" which is
=C2=A0=C2=A0 specified in [RFCThis].

=C2=A0

This needs to be very clear about the fields to be included in this new = registry (e.g., "Registry entries must contain two fields: the name of= the 'rph' type and the specification in which the type is describe= d").

=C2=A0


7.=C2=A0 Security Considerations

=C2=A0=C2=A0 The security considerations discussed in [I-D.ietf-stir-rf= c4474bis]
=C2=A0=C2=A0 in Section 10 are applicable here.

7.1.=C2=A0 Avoidance of replay and cut and paste attacks

=C2=A0=C2=A0 The PASSporT extension with a "ppt" value of &qu= ot;rph" MUST only be sent
=C2=A0=C2=A0 with SIP INVITE when 'Resource-Priority' header is= used to convey the

=C2=A0

"...header field..."

=C2=A0

=C2=A0=C2=A0 pr= iority of the communication as defined in [RFC4412].=C2=A0 To avoid the

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 The authority that signs the token MUST have a secure metho= d for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authentication of the end user or the de= vice.

=C2=A0=C2=A0 o=C2=A0 The verification of the signature MUST include mea= ns of verifying
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that the signer is authoritative for the= signed content of the SIP

=C2=A0

It's not clear what authority is being claimed here. Is this suppose= d to mean something like "...verifying that the signer is authoritativ= e for the originating tn in the PASSporT..."? Or "...authoritativ= e for the resource priority namespace in the PASSporT?" Whatever the server is purportedly authoritative for needs to be clearly s= pelled out.

=C2=A0

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 'Resource-Priority' header.

=C2=A0

"...header field."

=C2=A0

/a


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir


--f403045eaca898160605642e9d7a-- From nobody Thu Feb 1 15:09:13 2018 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F2612F2A5; Thu, 1 Feb 2018 15:09:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151752654804.25549.11552530288034914231@ietfa.amsl.com> Date: Thu, 01 Feb 2018 15:09:08 -0800 Archived-At: Subject: [stir] I-D Action: draft-ietf-stir-rph-03.txt X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 23:09:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF. Title : PASSporT Extension for Resource-Priority Authorization Authors : Ray P. Singh Martin Dolly Subir Das An Nguyen Filename : draft-ietf-stir-rph-03.txt Pages : 9 Date : 2018-02-01 Abstract: This document extends the Secure Telephone Identity Revisited (STIR) Personal Assertion Token (PASSporT) specification defined in [I-D.ietf-stir-passport] to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-rph/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-stir-rph-03 https://datatracker.ietf.org/doc/html/draft-ietf-stir-rph-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-rph-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 4 07:27:46 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC2F12702E for ; Sun, 4 Feb 2018 07:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 A32Rl9uvKWcp for ; Sun, 4 Feb 2018 07:27:42 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33745127010 for ; Sun, 4 Feb 2018 07:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517758058; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SPZpP/eqylg250kHKip7Hx4jM0/NxBZtfW+JWHM0f4E=; b=LRMNYn3opNUNlda44p2YNYD7ft8e0LO6Sbpg0HZ41M2Sj0dLRooZHaNxL2FZiBrl m+OldzxW/h5gZUojPG4fXqTNxAUhw3hYKG4rfcYE3X1m41fQ/BGRK+2NSD+pSkSC A5KeZHfVES0zvx+iw2nyvRrcznF3yOr3ldagHAiM+XA=; X-AuditID: c1b4fb30-399ff70000004778-4b-5a77266ad243 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0D.74.18296.A66277A5; Sun, 4 Feb 2018 16:27:38 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Sun, 4 Feb 2018 16:27:37 +0100 From: Christer Holmberg To: "Peterson, Jon" , Julio Martinez-Minguito , Chris Wendt CC: "stir@ietf.org" Thread-Topic: [EXTERNAL] Re: [stir] PASSPorT: "orig" and "dest" mandatory in all PASSPorTs? Thread-Index: AQHTmhhNxwncwLCIhkCTLcv50WoH5KOUS3Ig Date: Sun, 4 Feb 2018 15:27:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C153603@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdXTdLrTzK4OZrGYvpn3YzW2x+tobJ YvnabUwOzB4T+taweixZ8pPJ4/WGOewBzFFcNimpOZllqUX6dglcGY2fN7EUfHOsOHqnmbWB sdG0i5GTQ0LARGLiwRNsXYxcHEIChxklTq78wA7hLGaUWD9lHmsXIwcHm4CFRPc/bZC4iMAc RonFbZvB4swCyhL/dtuDDBIWiJG42n2NBcQWEYiV2LzoDDuEbSQxuaWDCcRmEVCR+HG+jRmk lVfAV+LkX2WQsJCAmcS21TvBWjkFzCW2LD0E1sooICbx/dQasFZmAXGJW0/mM0HcLCCxZM95 ZghbVOLl43+sELaSxNrD21kg6vUkbkydwgZha0ssW/garJ5XQFDi5MwnLBMYRWchGTsLScss JC2zkLQsYGRZxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYOQe3/DbYwfjyueMhRgEORiUe 3jmC5VFCrIllxZW5hxglOJiVRHhnTCqLEuJNSaysSi3Kjy8qzUktPsQozcGiJM570pM3Skgg PbEkNTs1tSC1CCbLxMEp1cBYWNg8ecE+hwmunw/677W9MalFJTFvs6qlnsH/M8EvLa42BGWb +1g06JU9n/C84naCh0b7/LY4nsPlEg27XFIP9ffcmt/+zf7BU50Aqe+cXyc0L/JhlxBtuLao dN89YfMXcSK2b2PPfi/gSdoYf/2fzb9XszRsp/9gjtVsLP03bTfPFzaVoq1KLMUZiYZazEXF iQBMs8t3mAIAAA== Archived-At: Subject: Re: [stir] [EXTERNAL] Re: PASSPorT: "orig" and "dest" mandatory in all PASSPorTs? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 15:27:45 -0000 Hi, >I certainly hope that the semantics are basically the same, yes, that the = only real difference is in how nested "div" is carried in the signaling. >The main reason for embedding right now is forward compatibility with OOB,= correct. If we ever decided we wanted to be able to encrypt=20 >PASSporTs carried in-band, this would also be very handy. In general it se= ems like kind of a nuisance to hand a verification service a pile of=20 >Identity headers and say "you figure out what goes with what" - when I sta= rted pondering cases with spirals in signaling, for example, I got=20 >a little worried. Even if you hand the verification service a single Identity header fields, = which contains embedded claims from N Identity header fields, the verificat= ion service still have to figure out what goes with what, doesn't it? >The next revision to the document is going to talk a bit about an issue th= at has arisen in implementation (already) with the Diversion header and 3xx= responses. There >probably should be a means for a 3xx to carry a nested P= ASSporT in the response that could be tucked into an Identity header by any= entity sending new INVITEs based on >the Contacts in the 3xx >- but there are a few potential pitfalls there we need to avoid, or at lea= st carefully mark. Assume the following:=20 1 . The "original" (pre-3xx) INVITE traverses proxies P1 and P2. Each of th= ose proxies insert a claim.=20 2. The INVITE then reaches P3, which decides to send a 3xx response. It in= cludes a nested PASSporT, with the claims from P1 and P2 (and possibly P3) = in the responses. 3. The 3xx reaches the UA, which sends a "new" INVITE, which contains the = nested PASSporT provided in the 3xx. 4. The new INVITE reaches P3 and P4, and eventually a verifier. The Identi= ty header will contain the claims of P1 and P2. Is that the intention? Is t= he verifier supposed to verify those? What if the verification fails? Shoul= d the verifier reject the request, even if P1 and P2 are no longer associat= ed with the call? If this will be clarified in the next version, I can wait for the answer :) In addition, P3 and P4 may add their own claims, in separate Identity heade= r fields, so there would be one Identity header field with the nested claim= (received in the 3xx response), followed by the Identity header fields add= ed by P3 and P4. Perhaps that is not a problem, but I just hope we don't ma= ke assumptions regarding the number and combinations of Identity header fie= lds...=20 Regards, Christer On 1/26/18, 9:27 AM, "stir on behalf of Julio Martinez-Minguito" wrote: >Hi, > >I see in the nested divert that the new PASSporT has a claim "opt"=20 >which includes the PASSporT of the originating network, including the=20 >signature. >The PASSporT added by the diverting network includes a claim "orig",=20 >which is copied from the 'original' PASSporT. >In this case , for a PASSporT ppt:div, the diverting network mays not=20 >have authority over the claim "orig", but only over the claim 'div'. A=20 >verifier will have to check the embedded PASSporT, verify the signature=20 >and check that the orig in the different PASSporT matches. > >Though in another cases, if the originating number and the diverting=20 >are served by the same operator, the operator has authority over both=20 >orig and div claims. A nested PASSporT would not be needed in this case. > >The end result is quite similar as if we have multiple Identity headers. >In the end there are multiple PASSporT objects, the difference is how=20 >they are conveyed in the signaling. > >I assume the main reason for the embedding is because of the oob=20 >solution, or? > >Regards, Julio > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: den 24 januari 2018 15:06 >> To: Chris Wendt >> Cc: stir@ietf.org >> Subject: Re: [stir] PASSPorT: "orig" and "dest" mandatory in all=20 >>PASSPorTs? >>=20 >> Hi, >>=20 >> >I guess i=B9m not following what=B9s not clear, if you MUST only have=20 >> >one orig claim and one identity in that claim, that seems to be=20 >> >pretty clear to me that you cannot either not have an orig claim or=20 >> >have more than one. I guess maybe i=B9m missing something subtle in yo= ur point. >>=20 >> It is clear that you cannot have more than one claim, but I think it=20 >>could be made more clear that you always must have a claim to begin=20 >>with :) >>=20 >> >For extensions, and in general with any PASSporT, once the PASSporT=20 >> >is signed, that=B9s it, you cannot modify claims or "re-sign". If you= =20 >> >want new PASSporT claim information that you want to sign, you must=20 >> >have a new PASSporT or new identity header. >>=20 >> Correct, I should have made that clear. >>=20 >> So, if you have two (or more) Identity header fields, do they all=20 >>have to contain the same =B3orig=B2 value? Or, is one allowed to change= =20 >>it? >>=20 >> Does the same apply for =B3dest=B2? And, if you want to change the =B3de= st=B2=20 >>you need to use the divert extension? You can=B9t just add a new=20 >>passport with a new =B3dest=B2 value. Or? >>=20 >> >Currently for divert, the approach is to embed a PASSporT inside a=20 >> >new PASSporT, which is a valid technique also and result in a new=20 >> >identity header also (but you should remove the old identity header=20 >> >in this >>case). >>=20 >> My colleague Julio sent some questions and issues regarding the=20 >> =B3embedding=B2/=B3nesting=B2 approach. I would be happy if you look at = those=20 >> :) >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> > >> >-Chris >> > >> >> On Jan 23, 2018, at 2:19 PM, Christer Holmberg=20 >> >> wrote: >> >> >> >> Hi Chris, >> >> >> >>>> Question for clarification: >> >>>> >> >>>> Section 5.2.1 of draft-passport says: >> >>>> >> >>>> "There MUST be exactly one "orig" claim with exactly one=20 >> >>>>identity claim object in a PASSporT object." >> >>>> >> >>>> Q1: Does the text above mean that >> >>>> >> >>>> a) a passport must always contain one, one only one, "orig" >> >>>>claim; or >> >>>> b) that if a passport contains an "orig" claim, if can only=20 >> >>>>contains one? >> >>> >> >>> It can only contain one key value pair with the key =B3orig=B2 and=20 >> >>>the claim value can only be one identity. >> >>> >> >>> In other words you cannot claim to originate multiple identities=20 >> >>>with a single passport object. >> >> >> >> Correct. The question is whether "orig" is mandatory (alternative=20 >> >>a) or not (alternative b). But, based on your reply to Q2 below, I=20 >> >>assume the answer is alternative a). >> >> >> >> I think it would be good to make that more clear. >> >> >> >>>> Q2: If a), does it apply to passport extensions too? >> >>> >> >>> All extensions must include the base passport claims and follow=20 >> >>>all rules of the claims, so yes. >> >> >> >> I think it should be more clear whether a node can modify claims=20 >> >>or not when adding an extension, or whether an extension needs to=20 >> >>explicitly allow it. Currently the text only says (AFAIK) that=20 >> >>claims cannot be removed. >> >> >> >> For example, if I have a base passport, and add an RPH passport, I=20 >> >>assume I cannot change the value of the "dest" claim. I would need=20 >> >>to use a divert claim for that. >> >> >> >> Also, as the passports may be added and signed by different=20 >> >>authorities, and as each passport will contain the base claims, it=20 >> >>means that the base claims will be signed multiple times, and they=20 >> >>may be signed by different authorities. I assume that is ok. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> > >>=20 > >_______________________________________________ >stir mailing list >stir@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm >an_=20 >listinfo_stir&d=3DDwIFAw&c=3DMOptNlVtIETeDALC_lULrw&r=3DdQ51tLfoGuuFjanmfe= KC0 >weX=20 >HNMl9xZnnsIiwRd6IgY&m=3DCYEKQetxoYJFWkCYlTjULI4cuXYtswc-ksgANHWODz0&s=3Dn8= n >5Xn LoHH1N9qVTNdWCn5VNUcQIQMajN21qTivbnD8&e=3D From nobody Sun Feb 4 08:33:40 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CA4127275 for ; Sun, 4 Feb 2018 08:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 pgPP1UFJ7ygA for ; Sun, 4 Feb 2018 08:33:34 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3271271FD for ; Sun, 4 Feb 2018 08:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517762011; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3hEbdxITZivvP8mMJoSuHfMrOHyYoQXXDPuM0dI/CWg=; b=bdrs3yZhjfeN6kCQlMYagT/7e1yLkN4heB5SL8eGxWQRnXfQkIOjrtKhxdzd6y8M 4Z3vCRKrAuMjtwQ88ANCswM1iTW/ssDYWHvEBPBovhUCP3DTtQT1eHr4moyAsfwb FzR6JJ8y/sXVG9m5Ayqu9+WW/0FhaGH7S6mz9Enorsg=; X-AuditID: c1b4fb2d-4b1ff70000005540-2b-5a7735da2248 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 80.D1.21824.AD5377A5; Sun, 4 Feb 2018 17:33:31 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Sun, 4 Feb 2018 17:33:30 +0100 From: Christer Holmberg To: Subir Das CC: Adam Roach , STIR Chairs , "stir@ietf.org" , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AdOTv2oSY/dEf4YfRra4GseuGeXVLAH6TDcAAIWJiHA= Date: Sun, 4 Feb 2018 16:33:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C153849ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2K7ru5t0/Iog69z2C32/F3EbrH6+Dkm i2c71rNaLF+7jcliyoFl7A6sHjtn3WX3WLLkJ5PHrJ1PWDy+XP7MFsASxWWTkpqTWZZapG+X wJVxYkovY8Get+wVs7+lNDAeuczexcjJISFgIvH75TrWLkYuDiGBw4wS3x8dg3IWM0r8XfWE pYuRg4NNwEKi+582SIOIgIrEu0uLGUFqmAX2MkosubSIESQhLJAt8WzLbxaIohyJk7/+MkLY VhJPPvxgBrFZgJp3XLwPZvMK+Epc272GGWLZFEaJ5du6WUESnAKBEnMuHQOzGQXEJL6fWsME YjMLiEvcejKfCeJsAYkle84zQ9iiEi8f/2OFsJUk1h7ezgJRny9xu38tG8QyQYmTM5+wTGAU mYVk1CwkZbOQlM0C+plZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tLs5NNzLW Sy3KTC4uzs/Ty0st2cQIjMaDW37r7mBc/drxEKMAB6MSD+98tfIoIdbEsuLK3EOMEhzMSiK8 MyaVRQnxpiRWVqUW5ccXleakFh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgSTZeLglGpgZA04 fC/lAF+N+0Wlu2Fti5bN4HmlpCt0UOz6Pn21/C3ca0QjCx6fDf8bPe2thUyvl3NQfJifZNx5 jeUvbx2Y9Vit+unGLKMt3rfFnnkXFPUx9e74+kjjwD2J9XpBs3+d0JsXUbZ6Lv/krDm+vofi A9xKTBL2p2xjzj0Y4pe8YGWgkGHMv5JpSizFGYmGWsxFxYkAznSH7cICAAA= Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 16:33:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C153849ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSB0ZXh0IHNheXM6DQoNCiAgIOKAnFRoZSBjcmVkZW50aWFscyAoZS5nLiwgYXV0 aG9yaXR5IHJlc3BvbnNpYmxlIGZvciBhdXRob3JpemluZyBSZXNvdXJjZS0NCiAgIFByaW9yaXR5 KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlIG11c3QgaGF2ZSBhdXRob3JpdHkgb3ZlciB0 aGUNCiAgIG5hbWVzcGFjZSBvZiB0aGUgInJwaCIgY2xhaW0gYW5kIHRoZXJlIGlzIG9ubHkgb25l IGF1dGhvcml0eSBwZXINCiAgIGNsYWltLuKAnQ0KDQpJZiB0aGUgY3JlZGVudGlhbHMgZG9u4oCZ dCBuZWVkIHRvIGhhdmUgYXV0aG9yaXR5IG9mIHRoZSBvdGhlciBjbGFpbXMgKGUuZy4sIOKAnG9y aWfigJ0pIGluIHRoZSBSUEggUEFTU1BvclQgSSB0aGluayB5b3Ugc2hvdWxkIGV4cGxpY2l0bHkg c2F5IHNvLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IFN1YmlyIERhcyBbbWFp bHRvOnN1YmlyZGFzMjFAZ21haWwuY29tXQ0KU2VudDogMDIgRmVicnVhcnkgMjAxOCAwMTowNA0K VG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpD YzogQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT47IFNUSVIgQ2hhaXJzIDxzdGlyLWNoYWly c0BpZXRmLm9yZz47IHN0aXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc3Rpci1ycGguYWxsQHRvb2xz LmlldGYub3JnDQpTdWJqZWN0OiBSZTogW3N0aXJdIEFEIFJldmlldzogZHJhZnQtaWV0Zi1zdGly LXJwaC0wMiAtIGF1dGhvcml0eSB0byBhc3NlcnQgdGhlIGNhbGxlcnMgaWRlbnRpdHkgYXNzdW1l ZD8NCg0KSGVsbG8gQ2hyaXN0ZXIsDQpUaGUgc2lnbmluZyBlbnRpdHkgZG9lcyBub3QgaGF2ZSBh bHdheXMgdGhlIGF1dGhvcml0eSB0byBhc3NlcnQgdGhlIGNhbGxlciBpZGVudGl0eSBpbiBycGgu IFdlIGFyZSBzdWJtaXR0aW5nIHZlci0wMyBkcmFmdCAgYW5kIGl0IGlzIGNsYXJpZmllZCAgYXMg Zm9sbG93czoNCiJUaGUgY3JlZGVudGlhbHMgKGUuZy4sIGF1dGhvcml0eSByZXNwb25zaWJsZSBm b3IgYXV0aG9yaXppbmcgUmVzb3VyY2UtUHJpb3JpdHkpIHVzZWQgdG8gY3JlYXRlIHRoZSBzaWdu YXR1cmUgbXVzdCBoYXZlIGF1dGhvcml0eSBvdmVyIHRoZSBuYW1lc3BhY2Ugb2YgdGhl4oCccnBo IiBjbGFpbS4uIg0KDQotU3ViaXINCg0KT24gTW9uLCBKYW4gMjIsIDIwMTggYXQgMzoyNyBQTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KQW5vdGhlciBx dWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbi4NCg0KU2VjdGlvbiAzIGNvbnRhaW5zIHRoZSBmb2xs b3dpbmcgZXhhbXBsZToNCg0KICAgIHsgIm9yaWciOnsidG4iOiIxMjE1NTU1MTIxMjx0ZWw6KDIx NSklMjA1NTUtMTIxMj4ifQ0KICAgICAiZGVzdCI6e1sidG4iOiIxMjEyNTU1MTIxMzx0ZWw6KDIx MiklMjA1NTUtMTIxMz4iXX0sDQogICAgICJpYXQiOjE0NDMyMDgzNDUsDQogICAgICJycGgiOnsi YXV0aCI6WyJldHMuMCIsIndwcy4wIl19DQoNCuKApmFuZCB0aGUgZm9sbG93aW5nIHRleHQ6DQoN CiAgIOKAnFRoZSBjcmVkZW50aWFscyAoZS5nLiwgYXV0aG9yaXR5IHJlc3BvbnNpYmxlIGZvciBh dXRob3JpemluZyBSZXNvdXJjZS0NCiAgIFByaW9yaXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2ln bmF0dXJlIG11c3QgaGF2ZSBhdXRob3JpdHkgb3ZlciB0aGUNCiAgICJycGgiIGNsYWlt4oCm4oCd DQoNClNpbmNlIHRoZSBjbGFpbSBhbHNvIGNvbnRhaW5zIOKAnG9yaWfigJ0sIGlzIHRoZSBhc3N1 bXB0aW9uIHRoYXQgdGhlIHNpZ25pbmcgZW50aXR5IGFsd2F5cyBhbHNvIGhhcyBhdXRob3JpdHkg dG8gYXNzZXJ0IHRoZSBjYWxsZXJzIGlkZW50aXR5PyBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2Qg dG8gZXhwbGljaXRseSBtZW50aW9uIGl0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0K DQoNCg0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3Rp ci1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNClNlbnQ6IDIwIEph bnVhcnkgMjAxOCAwMDoxNQ0KVG86IFNUSVIgQ2hhaXJzIDxzdGlyLWNoYWlyc0BpZXRmLm9yZzxt YWlsdG86c3Rpci1jaGFpcnNAaWV0Zi5vcmc+Pjsgc3RpckBpZXRmLm9yZzxtYWlsdG86c3RpckBp ZXRmLm9yZz47IGRyYWZ0LWlldGYtc3Rpci1ycGguYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLXN0aXItcnBoLmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFtzdGlyXSBB RCBSZXZpZXc6IGRyYWZ0LWlldGYtc3Rpci1ycGgtMDINCg0KDQpJJ20gZG9pbmcgbXkgQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtc3Rpci1ycGgtMDIuIFRoYW5rcyB0byBldmVyeW9uZSB3aG8gaGFz IHdvcmtlZCBvbiB0aGlzIGRvY3VtZW50LCBhbmQgdGhlIGF1dGhvcnMgYW5kIGNoYWlycyBpbiBw YXJ0aWN1bGFyLg0KDQpUaGUgdGVjaG5pY2FsIGNvbnRlbnQgaGVyZSBsb29rcyBnZW5lcmFsbHkg Z29vZCB0byBtZS4gSSdkIGxpa2UgdG8gc2VlIGEgZmV3IGlzc3VlcyBhZGRyZXNzZWQgYmVmb3Jl IElFVEYgTEMuIEluIHNob3J0IHN1bWFyeToNCg0KICAqICAgVGhlIHZhbGlkYXRpb24gc2VjdGlv biBuZWVkcyB0byBhZGQgYSBkaXNjdXNzaW9uIG9mIGhvdyB0byB0cmVhdCBjYWxscyB3aGVuIHRo ZSBwcmlvcml0eSB2YWx1ZXMgaW4gInJwaCIgcGFzc3BvcnRzIGFuZCBTSVAgIlJlc291cmNlLVBy aW9yaXR5IiBoZWFkZXIgZmllbGRzIGFyZW4ndCAxMDAlIGlkZW50aWNhbC4NCiAgKiAgIFRoZSBl eGFtcGxlcyBuZWVkIHNvbWUgYWRqdXN0bWVudC4NCiAgKiAgIFRoZXJlIGlzIGEgbWlub3IgcG9p bnQgb2YgYW1iaWd1aXR5IGluIHRoZSBTZWN1cml0eSBTZWN0aW9uLCBidXQgdGhpcyBzaG91bGQg YmUgZWFzeSB0byBmaXgsIGFzIGxvbmcgYXMgdGhlIFdHIGtub3dzIHdoYXQgd2FzIGludGVuZGVk Lg0KICAqICAgVGhlIElBTkEgYWN0aW9ucyBuZWVkIGEgbGl0dGxlIGJpdCBvZiBhZGp1c3RtZW50 Lg0KICAqICAgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIG1pbm9yIGVkaXRvcmlhbCBpc3N1ZXMgdG8g YmUgY2xlYW5lZCB1cC4NCg0KRGV0YWlsZWQgY29tbWVudHMgb24gdGhlc2UgcG9pbnRzIGFyZSBp bmxpbmUgaW4gdGhlIGRvY3VtZW50IGJlbG93LiBJJ3ZlIHJlbW92ZWQgc29tZSBwb3J0aW9ucyBv ZiB0aGUgZG9jdW1lbnQgb24gd2hpY2ggSSBoYXZlIG5vIGNvbW1lbnRzLg0KDQoNCg0KQWJzdHJh Y3QNCg0KICAgVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBTVElSIFBBU1Nwb3JUIHNwZWNpZmlj YXRpb24gdG8gYWxsb3cgdGhlDQoNCg0KDQoiLi4udGhlIFNlY3VyZSBUZWxlcGhvbmUgSWRlbnRp dHkgUmV2aXNpdGVkIChTVElSKSBQZXJzb25hbCBBc3NlcnRpb24gVG9rZW4gKFBBU1Nwb3JUKSBz cGVjaWZpY2F0aW9uIGRlZmluZWQgaW4gUkZDIDgxMjIuLi4iDQoNCihTZWUgPGh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dD48aHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvbWF0ZXJpYWxzL2FiYnJldi5leHBhbnNpb24udHh0PiBmb3IgZ3Vp ZGFuY2Ugb24gYWJicmV2aWF0aW9ucykNCg0KDQogICBpbmNsdXNpb24gb2YgY3J5cHRvZ3JhcGhp Y2FsbHktc2lnbmVkIGFzc2VydGlvbnMgb2YgYXV0aG9yaXphdGlvbiBmb3INCiAgIHRoZSB2YWx1 ZXMgcG9wdWxhdGVkIGluIHRoZSBTSVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQs DQogICB3aGljaCBpcyB1c2VkIGZvciBjb21tdW5pY2F0aW9ucyByZXNvdXJjZSBwcmlvcml0aXph dGlvbi4NCg0KLi4uDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgUEFTU3BvclQgW0ktRC5pZXRm LXN0aXItcGFzc3BvcnRdIGlzIGEgdG9rZW4gZm9ybWF0IGJhc2VkIG9uIEpXVA0KICAgW1JGQzc1 MTldIGZvciBjb252ZXlpbmcgY3J5cHRvZ3JhcGhpY2FsbHktc2lnbmVkIGluZm9ybWF0aW9uIGFi b3V0DQogICB0aGUgaWRlbnRpdGllcyBpbnZvbHZlZCBpbiBwZXJzb25hbCBjb21tdW5pY2F0aW9u czsgaXQgaXMgdXNlZCB3aXRoDQogICBTVElSIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNdIHRv IGNvbnZleSBhIHNpZ25lZCBhc3NlcnRpb24gb2YgdGhlDQogICBpZGVudGl0eSBvZiB0aGUgcGFy dGljaXBhbnRzIGluIHJlYWwtdGltZSBjb21tdW5pY2F0aW9ucyBlc3RhYmxpc2hlZA0KICAgdmlh IGEgcHJvdG9jb2wgbGlrZSBTSVAuICBUaGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcyBQQVNTcG9y VCB0bw0KDQoNCg0KIi4uLmxpa2UgU0lQIFtSRkMzMjYxXS4uLiINCg0KKFdlIHdhbnQgdG8gY2l0 ZSBTSVAgdGhlIGZpcnN0IHRpbWUgaXQgaXMgbWVudGlvbmVkKQ0KDQoNCiAgIGFsbG93IGNyeXB0 b2dyYXBoaWMtc2lnbmluZyBvZiB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyDQog ICBmaWVsZCBkZWZpbmVkIGluIFtSRkM0NDEyXS4NCg0KICAgW1JGQzQ0MTJdIGRlZmluZXMgdGhl IFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBmb3INCiAgIGNvbW11bmljYXRp b25zIFJlc291cmNlIFByaW9yaXR5LiAgQXMgc3BlY2lmaWVkIGluIFtSRkM0NDEyXSwgdGhlDQog ICAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBtYXkgYmUgdXNlZCBieSBTSVAgdXNl ciBhZ2VudHMNCiAgIFtSRkMzMjYxXSwgaW5jbHVkaW5nLCBQdWJsaWMgU3dpdGNoZWQgVGVsZXBo b25lIE5ldHdvcmsgKFBTVE4pDQoNCg0KDQoiLi4uaW5jbHVkaW5nIFB1YmxpYyBTd2l0Y2hlZC4u LiINCg0KKHJlbW92ZSB0aGUgY29tbWEpDQoNCg0KICAgZ2F0ZXdheXMgYW5kIHRlcm1pbmFscywg YW5kIFNJUCBwcm94eSBzZXJ2ZXJzIHRvIGluZmx1ZW5jZQ0KDQoNCg0KIi4uLmFuZCBieSBTSVAg cHJveHkgc2VydmVycywgdG8gaW5mbHVlbmNlLi4uIg0KDQooYWRkICJieSIgYW5kIGNvbW1hKQ0K DQoNCiAgIHByaW9yaXRpemF0aW9uIGFmZm9yZGVkIHRvIGNvbW11bmljYXRpb24gc2Vzc2lvbnMs aW5jbHVkaW5nIFBTVE4NCg0KDQoiLi4uc2Vzc2lvbnMsIGluY2x1ZGluZy4uLiINCg0KKHNwYWNl IGFmdGVyIGNvbW1hKQ0KDQoNCiAgIGNhbGxzLiAgSG93ZXZlciwgdGhlIFNJUCAnUmVzb3VyY2Ut UHJpb3JpdHknIGhlYWRlciBmaWVsZCBjb3VsZCBiZQ0KICAgc3Bvb2ZlZCBhbmQgYWJ1c2VkIGJ5 IHVuYXV0aG9yaXplZCBlbnRpdGllcy4NCg0KICAgVGhlIFNUSVIgYXJjaGl0ZWN0dXJlIFtSRkM3 MzQwXWFzc3VtZXMgdGhhdCBhbiBhdXRob3JpdHkgb24gdGhlDQoNCg0KDQoiLi4uU1RJUiBhcmNo aXRlY3R1cmUgW1JGQzczNDBdIGFzc3VtZXMuLi4iDQoNCihzcGFjZSBiZWZvcmUgImFzc3VtZXMi KQ0KDQoNCiAgIG9yaWdpbmF0aW5nIHNpZGUgb2YgYSBjYWxsIHByb3ZpZGVzIGEgY3J5cHRvZ3Jh cGhpYyBhc3N1cmFuY2Ugb2YgdGhlDQogICB2YWxpZGl0eSBvZiB0aGUgY2FsbGluZyBwYXJ0eSBu dW1iZXIgaW4gb3JkZXIgdG8gcHJldmVudA0KICAgaW1wZXJzb25hdGlvbiBhdHRhY2tzLiAgVGhl IFNUSVIgYXJjaGl0ZWN0dXJlIGFsbG93cyBleHRlbnNpb24gdGhhdA0KDQoNCg0KIi4uLmFsbG93 cyBleHRlbnNpb25zLi4uIg0KDQoNCiAgIGNhbiBiZSB1dGlsaXplZCBieSBhdXRob3JpdGllcyBz dXBwb3J0aW5nIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uDQogICBzZXJ2aWNlcyB1c2luZyB0aGUg J1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQgdG8NCiAgIGNyeXB0b2dyYXBoaWNhbGx5 IHNpZ24gdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBhbmQNCiAgIGNv bnZleSBhc3NlcnRpb24gb2YgdGhlIGF1dGhvcml6YXRpb24gZm9yICdSZXNvdXJjZS1Qcmlvcml0 eScuICBGb3INCiAgIGV4YW1wbGUsIHRoZSBhdXRob3JpdHkgb24gdGhlIG9yaWdpbmF0aW5nIHNp ZGUgdmVyaWZ5aW5nIHRoZQ0KICAgYXV0aG9yaXphdGlvbiBvZiBhIHBhcnRpY3VsYXIgY29tbXVu aWNhdGlvbiBmb3IgUmVzb3VyY2UtUHJpb3JpdHkgY2FuDQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFy b3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQoNCiAgIHVzZSBhIFBBU1NQb3JUIGNsYWltIHRv IGNyeXB0b2dyYXBoaWNhbGx5LXNpZ24gdGhlIFNJUCAnUmVzb3VyY2UtDQoNCg0KDQoiLi4uY3J5 cHRvZ3JhcGhpY2FsbHkgc2lnbi4uLiINCg0KDQogICBQcmlvcml0eScgaGVhZGVyIGZpZWxkIGFu ZCBjb252ZXkgYW4gYXNzZXJ0aW9uIG9mIHRoZSBhdXRob3JpemF0aW9uDQogICBmb3IgJ1Jlc291 cmNlLVByaW9yaXR5Jy4gIFRoaXMgd2lsbCBhbGxvdyBhIHJlY2VpdmluZyBlbnRpdHkNCiAgIChp bmNsdWRpbmcgZW50aXRpZXMgbG9jYXRlZCBpbiBkaWZmZXJlbnQgbmV0d29yayBkb21haW5zL2Jv dW5kYXJpZXMpDQogICB0byB2ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIGFzc2VydGlvbnMgYXV0aG9y aXppbmcgUmVzb3VyY2UtUHJpb3JpdHkuDQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVz b3VyY2UtUHJpb3JpdHknLg0KDQoNCiAgIENyeXB0b2dyYXBoaWNhbGx5LXNpZ25lZCBTSVAgJ1Jl c291cmNlLVByaW9yaXR5JyBoZWFkZXJzIHdpbGwgYWxsb3cgYQ0KDQoNCg0KIi4uLmNyeXB0b2dy YXBoaWNhbGx5IHNpZ25lZCBTSVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGRzLi4u Ig0KDQoocmVtb3ZlIGh5cGhlbiwgYW5kIHJlcGxhY2UgImhlYWRlcnMiIHdpdGggImhlYWRlciBm aWVsZHMiKQ0KDQoNCiAgIHJlY2VpdmluZyBlbnRpdHkgdG8gdmVyaWZ5IGFuZCBhY3Qgb24gdGhl IGluZm9ybWF0aW9uIHdpdGggY29uZmlkZW5jZQ0KICAgdGhhdCB0aGUgaW5mb3JtYXRpb24gaGF2 ZSBub3QgYmVlbiBzcG9vZmVkIG9yIGNvbXByb21pc2VkLg0KDQoNCg0KIi4uLmhhcyBub3QgYmVl biBzcG9vZmVkIG9yIGNvbXByb21pc2VkLiINCg0KDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBk b2N1bWVudHMgYW4gb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFBBU1Nwb3JUIGFuZA0KICAgdGhlIGFz c29jaWF0ZWQgU1RJUiBtZWNoYW5pc21zIHRvIHByb3ZpZGUgYSBmdW5jdGlvbiB0byBzaWduIHRo ZSBTSVANCiAgICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkLiAgVGhpcyBQQVNTcG9y VCBvYmplY3QgaXMgdXNlZCB0bw0KICAgcHJvdmlkZSBhdHRlc3RhdGlvbiBvZiBhIGNhbGxpbmcg dXNlciBhdXRob3JpemF0aW9uIGZvciBwcmlvcml0eQ0KICAgY29tbXVuaWNhdGlvbnMuICBUaGlz IGlzIG5lY2Vzc2FyeSBpbiBhZGRpdGlvbiB0byB0aGUgUEFTU3BvclQgb2JqZWN0DQogICB0aGF0 IGlzIHVzZWQgZm9yIGNhbGxpbmcgdXNlciB0ZWxlcGhvbmUgbnVtYmVyIGF0dGVzdGF0aW9uLiAg SG93IHRoZQ0KICAgb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFBBU1Nwb3JUIGlzIHVzZWQgZm9yIHJl YWwtdGltZSBjb21tdW5pY2F0aW9ucw0KICAgc3VwcG9ydGVkIHVzaW5nIFNJUCAnUmVzb3VyY2Ut UHJpb3JpdHknIGhlYWRlciBmaWVsZCBpcyBkZWZpbmVkIGluDQogICBvdGhlciBkb2N1bWVudHMg YW5kIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQpJIGFzc3Vt ZSB0aGVzZSBvdGhlciBkb2N1bWVudHMgYXJlIHVuZGVyIGRldmVsb3BtZW50PyBJZiBzbywgdGhl eSBzaG91bGQgYmUgY2l0ZWQgaGVyZS4NCg0KDQoNCjIuICBUZXJtaW5vbG9neQ0KDQogICBUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwg YW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVk IGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uDQoNCg0KDQpUaGlzIGRvY3VtZW50 IGhhcyBzZXZlcmFsIG5vbi1ub3JtYXRpdmUgdXNlcyBvZiAibXVzdCIsICJzaG91bGQsIiBhbmQg Im1heSwiIGFuZCBzbyBpdCBuZWVkcyB0byB1c2UgdGhlIFJGQzgxNzQgYm9pbGVycGxhdGUgaW5z dGVhZCBvZiB0aGUgUkZDMjExOSBib2lsZXJwbGF0ZS4NCg0KDQoNCjMuICBQQVNTcG9yVCAncnBo JyBDbGFpbQ0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIG5ldyBKU09OIFdlYiBU b2tlbiBjbGFpbSBmb3IgInJwaCIsDQogICB3aGljaCBwcm92aWRlcyBhbiBhc3NlcnRpb24gZm9y IGluZm9ybWF0aW9uIGluIFNJUCAnUmVzb3VyY2UtDQogICBQcmlvcml0eSdoZWFkZXIuDQoNCg0K DQoiLi4uUHJpb3JpdHknIGhlYWRlciBmaWVsZC4iDQoNCihzcGFjZSBhZnRlciBjbG9zaW5nIHF1 b3RhdGlvbiBtYXJrLCAiaGVhZGVyIGZpZWxkIiBpbnN0ZWFkIG9mICJoZWFkZXIiKQ0KDQoNCg0K ICAgVGhlIGNyZWF0b3Igb2YgYSBQQVNTcG9yVCBvYmplY3QgYWRkcyBhICJwcHQiIHZhbHVlIG9m ICJycGgiIHRvIHRoZQ0KICAgaGVhZGVyIG9mIGEgUEFTU3BvclQgb2JqZWN0LCBpbiB3aGljaCBj YXNlIHRoZSBQQVNTcG9yVCBjbGFpbXMgTVVTVA0KICAgY29udGFpbiBhICJycGgiIGNsYWltLCBh bmQgYW55IGVudGl0aWVzIHZlcmlmeWluZyB0aGUgUEFTU3BvclQgb2JqZWN0DQogICB3aWxsIGJl IHJlcXVpcmVkIHRvIHVuZGVyc3RhbmQgdGhlICJwcHQiIGV4dGVuc2lvbiBpbiBvcmRlciB0bw0K ICAgcHJvY2VzcyB0aGUgUEFTU3BvclQgaW4gcXVlc3Rpb24uICBBIFBBU1NQb3JUIGhlYWRlciB3 aXRoIHRoZSAicHB0Ig0KICAgaW5jbHVkZWQgd2lsbCBsb29rIGFzIGZvbGxvd3M6DQoNCiAgIHsg ICJ0eXAiOiJwYXNzcG9ydCIsDQogICAgICJwcHQiOiJycGgiLA0KICAgICAiYWxnIjoiRVMyNTYi LA0KICAgICAieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXIiPGh0dHBzOi8v d3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyPn0NCg0KDQoNCklkZWFsbHksIHRoaXMgd291bGQgYmUg ZWl0aGVyIHByZXR0eS1wcmludGVkIG9yIGNhbm9uaWNhbGl6ZWQuIFNpbmNlIGl0J3MgdG9vIGxv bmcgdG8gZml0IG9uIGEgbGluZSBpbiBjYW5vbmljYWwgZm9ybSwgSSBwcm9wb3NlOg0KDQp7DQog ICJ0eXAiOiJwYXNzcG9ydCIsDQogICJwcHQiOiJycGgiLA0KICAiYWxnIjoiRVMyNTYiLA0KICAi eDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXIiPGh0dHBzOi8vd3d3LmV4YW1w bGUub3JnL2NlcnQuY2VyPg0KfQ0KDQoNCg0KICAgVGhlICJycGgiIGNsYWltIHdpbGwgcHJvdmlk ZSBhbiBhc3NlcnRpb24gb2YgYXV0aG9yaXphdGlvbiwiYXV0aCIsDQoNCg0KDQoiLi4uYXV0aG9y aXphdGlvbiwgImF1dGgiLCAuLi4iDQoNCihzcGFjZSBiZXR3ZWVuIGNvbW1hIGFuZCBvcGVuaW5n IHF1b3RhdGlvbiBtYXJrKQ0KDQoNCiAgIGZvciBpbmZvcm1hdGlvbiBpbiB0aGUgU0lQICJSZXNv dXJjZS1Qcmlvcml0eSIgaGVhZGVyIGZpZWxkIChpLmUuLA0KICAgUmVzb3VyY2UtUHJpb3JpdHk6 IG5hbWVzcGFjZSAiLiIgci1wcmlvcml0eSkgYmFzZWQgb24gW1JGQzQ0MTJdLg0KDQoNCg0KVGhl IHVzZSBvZiB0aGUgc3RyaW5nICduYW1lc3BhY2UgIi4iIHItcHJpb3JpdHknIGhlcmUgYW5kIGVs c2V3aGVyZSBpbiB0aGUgZG9jdW1lbnQgaGFzIGEgZGV0cmltZW50YWwgaW1wYWN0IG9uIHJlYWRh YmlsaXR5LiBJIHN0cm9uZ2x5IHN1Z2dlc3QgcmVwbGFjaW5nIGl0IHdpdGggInItdmFsdWUiICh0 aGUgbmFtZSBvZiB0aGlzIHByb2R1Y3Rpb24gaW4gUkZDNDQxMikgZXZlcnl3aGVyZS4NCg0KDQog ICBTcGVjaWZpY2FsbHksIHRoZSAicnBoIiBjbGFpbSBpbmNsdWRlcyBhc3NlcnRpb24gb2YgdGhl IHByaW9yaXR5LQ0KICAgbGV2ZWwgb2YgdGhlIHVzZXIgdG8gYmUgdXNlZCBmb3IgYSBnaXZlbiBj b21tdW5pY2F0aW9uIHNlc3Npb24uICBUaGUNCiAgIHZhbHVlIG9mIHRoZSAicnBoIiBjbGFpbSBp cyBhbiBhcnJheSBjb250YWluaW5nIG9uZSBvciBtb3JlIG9mIEpTT04NCiAgIG9iamVjdHMgZm9y IHRoZSBjb250ZW50IG9mIHRoZSBTSVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgdGhhdCBp cw0KICAgYmVpbmcgYXNzZXJ0ZWQgb2Ygd2hpY2ggb25lIG9mIHRoZSAicnBoIiBvYmplY3QsIGlz IG1hbmRhdG9yeS4NCg0KDQoNClRoaXMgbGFzdCBzZW50ZW5jZSBpcyB2ZXJ5IGhhcmQgdG8gcGFy c2U7IGFuZCAoYmFzZWQgb24gdGhlIGV4YW1wbGUpIHRoZSB2YWx1ZSBpcyBpbnRlbmRlZCB0byBi ZSBhIEpTT04gT2JqZWN0IChjdXJseSBicmFjZXMpIHJhdGhlciB0aGFuIGEgSlNPTiBBcnJheSAo c3F1YXJlIGJyYWNlcykuIEkgc3VnZ2VzdDogJ1RoZSB2YWx1ZSBvZiB0aGUgInJwaCIgY2xhaW0g aXMgYW4gT2JqZWN0IHdpdGggb25lIG9yIG1vcmUga2V5cy4gRWFjaCBrZXkgaXMgYXNzb2NpYXRl ZCB3aXRoIGEgSlNPTiBBcnJheS4gVGhlc2UgYXJyYXlzIGNvbnRhaW4gU3RyaW5ncyB0aGF0IGNv cnJlc3BvbmQgdG8gdGhlIHItdmFsdWVzIGluZGljYXRlZCBpbiB0aGUgU0lQICJSZXNvdXJjZS1Q cmlvcml0eSIgaGVhZGVyIGZpZWxkLicgKG5vdGU6ICJoZWFkZXIgZmllbGQiLCBub3QgImhlYWRl ciIpDQoNCg0KDQogICBUaGUgZm9sbG93aW5nIGlzIGFuIGV4YW1wbGUgInJwaCIgY2xhaW0gZm9y IGEgU0lQICJSZXNvdXJjZS1Qcmlvcml0eSINCiAgIGhlYWRlciBmaWVsZCB3aXRoIGEgIm5hbWVz cGFjZSAiLiIgci1wcmlvcml0eSIgdmFsdWUgb2YgImV0cy4wIiBhbmQNCiAgIHdpdGggYSAibmFt ZXNwYWNlICIuIiByLXByaW9yaXR5IiB2YWx1ZSBvZiAid3BzLjAiLg0KDQogICAgeyAib3JpZyI6 eyJ0biI6IjEyMTU1NTUxMjEyPHRlbDooMjE1KSUyMDU1NS0xMjEyPiJ9DQogICAgICJkZXN0Ijp7 WyJ0biI6IjEyMTI1NTUxMjEzPHRlbDooMjEyKSUyMDU1NS0xMjEzPiJdfSwNCiAgICAgImlhdCI6 MTQ0MzIwODM0NSwNCiAgICAgInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLjAiXX0NCg0KDQoN CkFzIGFib3ZlLCBJIHJlY29tbWVuZCBwcmV0dHktcHJpbnRpbmcgdGhpcy4gSXQncyBhbHNvIG1p c3NpbmcgYSBjb21tYSBhZnRlciB0aGUgIm9yaWciIHZhbHVlLCBhbmQgdGhlIHRvcC1sZXZlbCBz dHJ1Y3R1cmUgaXMgbWlzc2luZyBhIGNsb3NpbmcgYnJhY2UuIFRoZSB2YWx1ZSBmb3IgImlhdCIg bmVlZHMgdG8gYmUgZW5jbG9zZWQgaW4gcXVvdGVzLg0KDQpUaGUgTkFOUEEgaGFzIGFsbG9jYXRl ZCBOUEE1NTUwMXh4IGZvciBleGFtcGxlIHVzZSwgbm90IE5QQTU1NXh4eHgsIG11Y2ggb2Ygd2hp Y2ggcmVtYWlucyBhc3NpZ25hYmxlIChjZiA8aHR0cHM6Ly93d3cubmF0aW9uYWxuYW5wYS5jb20v cGRmL05SVUYvQVRJUy0wMzAwMTE1LnBkZj48aHR0cHM6Ly93d3cubmF0aW9uYWxuYW5wYS5jb20v cGRmL05SVUYvQVRJUy0wMzAwMTE1LnBkZj4pLg0KDQpQdXR0aW5nIGFsbCB0aGlzIHRvZ2V0aGVy LCBJIGJlbGlldmUgd2hhdCB5b3Ugd2FudCBpczoNCg0Kew0KICAib3JpZyI6eyJ0biI6IjEyMTU1 NTUwMTEyPHRlbDooMjE1KSUyMDU1NS0wMTEyPiJ9LA0KICAiZGVzdCI6e1sidG4iOiIxMjEyNTU1 MDExMzx0ZWw6KDIxMiklMjA1NTUtMDExMz4iXX0sDQogICJpYXQiOiIxNDQzMjA4MzQ1IiwNCiAg InJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLjAiXX0NCn0NCg0KDQoNCiAgIEFmdGVyIHRoZSBo ZWFkZXIgYW5kIGNsYWltcyBQQVNTcG9yVCBvYmplY3RzIGhhdmUgYmVlbiBjb25zdHJ1Y3RlZCwN CiAgIHRoZWlyIHNpZ25hdHVyZSBpcyBnZW5lcmF0ZWQgbm9ybWFsbHkgcGVyIHRoZSBndWlkYW5j ZSBpbg0KICAgW0ktRC5pZXRmLXN0aXItcGFzc3BvcnRdIHVzaW5nIHRoZSBmdWxsIGZvcm0gb2Yg UEFTU1BvclQuICBUaGUNCiAgIGNyZWRlbnRpYWxzIChlLmcuLCBhdXRob3JpdHkgcmVzcG9uc2li bGUgZm9yIGF1dGhvcml6aW5nIFJlc291cmNlLQ0KICAgUHJpb3JpdHkpIHVzZWQgdG8gY3JlYXRl IHRoZSBzaWduYXR1cmUgbXVzdCBoYXZlIGF1dGhvcml0eSBvdmVyIHRoZQ0KICAgInJwaCIgY2xh aW0gYW5kIHRoZXJlIGlzIG9ubHkgb25lIGF1dGhvcml0eSBwZXIgY2xhaW0uICBUaGUgYXV0aG9y aXR5DQogICBNVVNUIHVzZSBpdHMgY3JlZGVudGlhbHMgKGkuZS4sIENFUlQpIGFzc29jaWF0ZWQg d2l0aCB0aGUgc3BlY2lmaWMNCiAgIHNlcnZpY2Ugc3VwcG9ydGVkIGJ5IHRoZSBTSVAgbmFtZXNw YWNlIGluIHRoZSBjbGFpbS4NCg0KNC4gICdycGgnIGluIFNJUA0KDQogICBUaGlzIHNlY3Rpb24g c3BlY2lmaWVzIFNJUC1zcGVjaWZpYyB1c2FnZSBmb3IgdGhlICJycGgiIGNsYWltIGluDQogICBQ QVNTcG9yVC4NCg0KNC4xLiAgQXV0aGVudGljYXRpb24gU2VydmljZSBCZWhhdmlvcg0KDQogICBU aGUgQXV0aGVudGljYXRpb24gU2VydmljZSB3aWxsIGNyZWF0ZSB0aGUgInJwaCIgY2xhaW0gdXNp bmcgdGhlDQogICB2YWx1ZXMgZGlzY3Vzc2VkIGluIHNlY3Rpb24gMyBiYXNlZCBvbiBbUkZDNDQx Ml0uICBUaGUgY29uc3RydWN0aW9uDQogICBvZiAicnBoIiBjbGFpbSBmb2xsb3dzIHRoZSBzdGVw cyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0IG9mDQogICBbSS1ELmlldGYtc3Rpci1yZmM0NDc0Ymlz XS4NCg0KICAgVGhlIHJlc3VsdGluZyBJZGVudGl0eSBoZWFkZXIgZm9yICJycGgiIG1pZ2h0IGxv b2sgYXMgZm9sbG93czoNCg0KDQoNCiIuLi5oZWFkZXIgZmllbGQuLi4iDQoNCg0KDQogICAiZXlK aGJHY2lPaUpGVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SnBjM01pT2lKbGVVb3daVmhCYVU5 cFNuZA0KICAgWldFNTZZMGM1ZVdSRFNYTkVVVzlwWTBoQ01FbHFiMmxqYmtKdlNXbDNUa05wU21o aVIyTnBUMmxLUmxWNlNURk8NCiAgIGFVbHpSRkZ2YVdWRVZqRkphbkJ2WkVoU2QyTjZiM1pNTTJR elpIazFiR1ZIUm5SalIzaHNURzFPZG1KVE9XcGFXDQogICBFb3dURzFPYkdOdU1FNURaekJMSUh4 ODRvQ1pMdUtBbVh4OElHVjVRV2xpTTBwd1dubEpObVY1U2pCaWFVazJTVw0KICAgcEZlVTFVVlRG T1ZGVjRUV3BGZVVsdU1FNURhVXByV2xoT01FbHFjRGRYZVVvd1ltbEpOa2xxUlhsTlZFa3hUbFIN CiAgIFZlRTFxUlhwSmJERTVURUV3UzBsdGJHaGtRMGsyVFZSUk1FMTZTWGRQUkUwd1RsTjNUa05w U25salIyZHBUMjV6DQogICBhVmxZVmpCaFEwazJWM2xLYkdSSVRYVk5RMGx6U1c1a2QyTjVOSGRK YkRFNVJGRnZQU0o5LnMzN1M2VkM4SE02RA0KICAgbDZZekplUURzclpjd0owbGl6eGhVckE3Zl85 OG9XQkh2by1jbC1uOE1JaG9DcjE4dllZRnkzYmxYdnMzZnNsTV8NCiAgIG9vczJQMkR5dyI7IGlu Zm89ICJodHRwczovL3d3dy5leGFtcGxlLm9yZy9jZXJ0LmNlciI8aHR0cHM6Ly93d3cuZXhhbXBs ZS5vcmcvY2VydC5jZXI+O2FsZz1FUzI1NjsNCiAgIHBwdD0icnBoIg0KDQoNCg0KVGhpcyBleGFt cGxlIGhhcyBhIG51bWJlciBvZiBpc3N1ZXM6DQoNCiAgKiAgIEluIHRoZSBJZGVudGl0eSBoZWFk ZXIgZmllbGQsIHRoZSBzaWduZWQtaWRlbnRpdHktZGlnZXN0IHNob3VsZG4ndCBiZSBxdW90ZWQu DQogICogICBJbiB0aGUgSWRlbnRpdHkgaGVhZGVyIGZpZWxkLCBpbmZvIGlzIGVuY2xvc2VkIGlu IDw+IHJhdGhlciB0aGFuICIiLg0KICAqICAgSW4gdGhlIElkZW50aXR5IGhlYWRlciBmaWVsZCwg cHB0IGlzIGEgdG9rZW4gcmF0aGVyIHRoYW4gYSBxdW90ZWQgc3RyaW5nLg0KICAqICAgVGhlIHNp Z25lZC1pZGVudGl0eS1kaWdlc3QgaGVhZGVyIG5lZWRzIHRvIGluZGljYXRlIGEgInR5cCIgb2Yg InBhc3Nwb3J0IiByYXRoZXIgdGhhbiBKV1QsIGFuZCBpdCBuZWVkcyB0byBpbmNsdWRlIGJvdGgg YSAicHB0IiBhbmQgIng1dSIgZmllbGQuDQogICogICBUaGUgc2lnbmVkLWlkZW50aXR5LWRpZ2Vz dCBib2R5IHNob3VsZCBjb250YWluIG9ubHkgdGhlIHBhc3Nwb3J0IGNsYWltIHJhdGhlciB0aGFu IGEgSlNPTiBvYmplY3QgdGhhdCBpdHNlbGYgY29udGFpbnMgYSBiYXNlNjQtZW5jb2RlZCBKV1Mg aGVhZGVyIGNvbmNhdGVuYXRlZCB3aXRoIGEgY2xhaW0uDQogICogICBJIGJlbGlldmUgdGhhdCwg ZXZlbiB3aGVuIHRoZSBib2R5IGlzIGluY2x1ZGVkLCB2YWx1ZXMgaW4gdGhlIGhlYWRlciBhbmQg Ym9keSBuZWVkIHRvIGJlIGJlIGNhbm9uaWNhbGl6ZWQgKGkuZS4sIGFsbCBvbiBvbmUgbGluZSwg bm8gc3BhY2VzLCBpbiBhbHBoYWJldGljYWwgb3JkZXIsIGV0Yy4pDQoNCkkgd291bGQgYWxzbyBy ZWNvbW1lbmQgZm9sbG93aW5nIHRoZSBjb252ZW50aW9uIG9mIGluZGljYXRpbmcgdGhhdCBsaW5l LXdyYXBzIGFyZSBvbmx5IGZvciByZWFkYWJpbGl0eSwgYW5kIGluY2x1ZGluZyB0aGUgaGVhZGVy IGZpZWxkIG5hbWUgaW4gdGhlIGV4YW1wbGUuIFB1dHRpbmcgYWxsIHRoaXMgdG9nZXRoZXIsIEkg YmVsaWV2ZSB3aGF0IHlvdSB3YW50IGlzOg0KDQogICBGb3IgZXhhbXBsZSwgYSBJZGVudGl0eSBo ZWFkZXIgZmllbGQgZm9yICJycGgiIG1pZ2h0IGxvb2sNCiAgIGFzIGZvbGxvd3MgKGJhY2tzbGFz aGVzIHNob3duIGZvciBsaW5lIGZvbGRpbmcgb25seSk6DQoNCiAgIElkZW50aXR5OiBleUpoYkdj aU9pSkZVekkxTmlJc0luQndkQ0k2SW5Kd2FDSXNJblI1Y0NJNkluQmhjM053YjNKMEkgXA0KICAg aXdpZURWMUlqb2lhSFIwY0hNNkx5OTNkM2N1WlhoaGJYQnNaUzVqYjIwdlkyVnlkQzVqWlhJaWZR by5leUprWlhOMCBcDQogICBJanA3V3lKMGJpSTZJakV5TVRJMU5UVXdNVEV6SWwxOUxDSnBZWFFp T2lJeE5EUXpNakE0TXpRMUlpd2liM0pwWnlJIFwNCiAgIDZleUowYmlJNklqRXlNVFUxTlRVd01U RXlJbjBzSW5Kd2FDSTZleUpoZFhSb0lqcGJJbVYwY3k0d0lpd2lkM0J6TGogXA0KICAgQWlYWDE5 Q2cuczM3UzZWQzhITTZEbDZZekplUURzclpjd0owbGl6eGhVckE3Zl85OG9XQkh2by1jbC1uOE1J aG9DciBcDQogICAxOHZZWUZ5M2JsWHZzM2ZzbE1fb29zMlAyRHl3O2luZm89PGh0dHBzOi8vd3d3 LmV4YW1wbGUub3JnL2NlcnQuY2VyIFwNCiAgID47YWxnPUVTMjU2O3BwdD1ycGgNCg0KKE5vdGU6 IHRoaXMgZXhhbXBsZSBhc3N1bWVzIHRoZSBjYWxsaW5nIGFuZCBjYWxsZWQgcGFydHkgbnVtYmVy cyBpbiB0aGUgcHJldmlvdXMgZXhhbXBsZSBhcmUgY2hhbmdlZCB0byAxMjE1NTU1MDExMjx0ZWw6 KDIxNSklMjA1NTUtMDExMj4gYW5kIDEyMTU1NTUwMTEzPHRlbDooMjE1KSUyMDU1NS0wMTEzPiwg cmVzcGVjdGl2ZWx5KQ0KDQoNCg0KICAgQSBTSVAgYXV0aGVudGljYXRpb24gc2VydmljZSB0eXBp Y2FsbHkgd2lsbCBkZXJpdmUgdGhlIHZhbHVlIG9mICJycGgiDQogICBmcm9tIHRoZSAnUmVzb3Vy Y2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBiYXNlZCBvbiBwb2xpY3kgYXNzb2NpYXRlZA0KICAg d2l0aCBzZXJ2aWNlIHNwZWNpZmljIHVzZSBvZiB0aGUgIm5hbWVzcGFjZSAiLiIgci1wcmlvcml0 eSIgdmFsdWVzDQogICBiYXNlZCBvbiBbUkZDNDQxMl0uICBUaGUgYXV0aGVudGljYXRpb24gc2Vy dmljZSBkZXJpdmVzIHRoZSB2YWx1ZSBvZg0KICAgdGhlIFBBU1NQb3JUIGNsYWltIGJ5IHZlcmlm eWluZyB0aGUgYXV0aG9yaXphdGlvbiBmb3IgUmVzb3VyY2UtDQogICBQcmlvcml0eSAoaS5lLiwg dmVyaWZ5aW5nIGEgY2FsbGluZyB1c2VyIHByaXZpbGVnZSBmb3IgUmVzb3VyY2UtDQogICBQcmlv cml0eSBiYXNlZCBvbiBpdHMgaWRlbnRpdHkpIHdoaWNoIG1pZ2h0IGJlIGRlcml2ZWQgZnJvbSBj dXN0b21lcg0KICAgcHJvZmlsZSBkYXRhIG9yIGZyb20gYWNjZXNzIHRvIGV4dGVybmFsIHNlcnZp Y2VzLg0KDQogICBbUkZDNDQxMl0gYWxsb3dzIG11bHRpcGxlICJuYW1lc3BhY2UgIi4iIHItcHJp b3JpdHkiIHBhaXJzLCBlaXRoZXIgaW4NCiAgIGEgc2luZ2xlIFNJUCBSZXNvdXJjZS1Qcmlvcml0 eSBoZWFkZXIgb3IgYWNyb3NzIG11bHRpcGxlIFNJUA0KDQoNCg0KU2luZ2xlIHF1b3RlcyBhcm91 bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy4NCg0KIi4uLmhlYWRlciBmaWVsZC4uLiINCg0KDQogICBS ZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXJzLiAgSG93ZXZlciwgaXQgaXMgbm90IG5lY2Vzc2FyeSB0 byBzaWduIGFsbA0KDQoNCg0KU2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5 Jy4NCg0KIi4uLmhlYWRlciBmaWVsZHMuLi4iDQoNCg0KICAgY29udGVudCBvZiBhIFNJUCBSZXNv dXJjZS1Qcmlvcml0eSBoZWFkZXIgb3IgYWxsIFNJUCBSZXNvdXJjZS0NCg0KDQoNClNpbmdsZSBx dW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScuDQoNCiIuLi5oZWFkZXIgZmllbGQuLi4i DQoNCg0KICAgUHJpb3JpdHkgaGVhZGVycyBpbiBhIGdpdmVuIFNJUCBtZXNzYWdlLiAgQW4gYXV0 aG9yaXR5IGlzIG9ubHkNCg0KDQoNClNpbmdsZSBxdW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlv cml0eScuDQoNCiIuLi5oZWFkZXIgZmllbGRzLi4uIg0KDQoNCiAgIHJlc3BvbnNpYmxlIGZvciBz aWduaW5nIHRoZSBjb250ZW50IG9mIGEgU0lQIFJlc291cmNlLVByaW9yaXR5IGhlYWRlcg0KDQoN Cg0KU2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy4NCg0KIi4uLmhlYWRl ciBmaWVsZC4uLiINCg0KDQogICBmb3Igd2hpY2ggaXQgaGFzIGF1dGhvcml0eSAoZS5nLiwgYSBz cGVjaWZpYyAibmFtZXNwYWNlICIuIg0KICAgci1wcmlvcml0eSIpLg0KDQo0LjIuICBWZXJpZmlj YXRpb24gU2VydmljZSBCZWhhdmlvcg0KDQogICBbSS1ELmlldGYtc3Rpci1yZmM0NDc0YmlzXSBT ZWN0aW9uIDYuMiBTdGVwIDUgcmVxdWlyZXMgdGhhdA0KICAgc3BlY2lmaWNhdGlvbnMgZGVmaW5p bmcgInBwdCIgdmFsdWVzIGRlc2NyaWJlIGFueSBhZGRpdGlvbmFsIHZlcmlmaWVyDQogICBiZWhh dmlvci4gIFRoZSBiZWhhdmlvciBzcGVjaWZpZWQgZm9yIHRoZSAicHB0IiB2YWx1ZXMgb2YgInJw aCIgaXMgYXMNCiAgIGZvbGxvd3M6DQoNCiAgIFRoZSB2ZXJpZmljYXRpb24gc2VydmljZSBNVVNU IGV4dHJhY3QgdGhlIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAgICJhdXRoIiBrZXkgaW4g YSBmdWxsIGZvcm0gUEFTU1BvclQgd2l0aCBhICJwcHQiIHZhbHVlIG9mICJycGgiLiAgSWYNCiAg IHRoZSBzaWduYXR1cmUgdmFsaWRhdGVzLCB0aGVuIHRoZSB2ZXJpZmljYXRpb24gc2VydmljZSBj YW4gdXNlIHRoZQ0KICAgdmFsdWUgb2YgdGhlICJycGgiIGNsYWltIGFzIHZhbGlkYXRpb24gdGhh dCB0aGUgY2FsbGluZyBwYXJ0eSBpcw0KICAgYXV0aG9yaXplZCBmb3IgUmVzb3VyY2UtUHJpb3Jp dHksIHdoaWNoIHdvdWxkIGluIHR1cm4gYmUgdXNlZCBmb3INCg0KDQpTaW5nbGUgcXVvdGVzIGFy b3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQpUaGlzIHRleHQgaXMgYW1iaWd1b3VzIGFib3V0 IHdoZXRoZXIgdGhlIHZhbGlkYXRpb24gaW5kaWNhdGVzIHRoYXQgdGhlIGNhbGxpbmcgcGFydHkg aXMgYXV0aG9yaXplZCB0byB1c2UgdGhlIHByaW9yaXRpZXMgaW5kaWNhdGVkIGluIHRoZSBwYXNz cG9ydCBvYmplY3QsIG9yIHRoZSB2YWx1ZXMgaW4gdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHkn IGhlYWRlciBmaWVsZDsgYW5kICh0YWtlbiBvbiBpdHMgZmFjZSkgaW1wbGllcyB0aGUgbGF0dGVy LCB3aGVuIHRoZSBpbnRlbnRpb24gaGVyZSBzaG91bGQgY2xlYXJseSBiZSB0aGUgZm9ybWVyLg0K DQoiLi4uYXV0aG9yaXplZCBmb3IgJ1Jlc291cmNlLVByaW9yaXR5JyBpbmRpY2F0ZWQgaW4gdGhl IGNsYWltLiBUaGlzIHZhbHVlIHdvdWxkIGluIHR1cm4gYmUgdXNlZCBmb3IuLi4iDQoNClRoZSB0 ZXh0IGFsc28gbmVlZHMgdG8gc2F5IHNvbWV0aGluZyBhYm91dCBjb21wYXJpbmcgdmFsdWVzIGlu IHRoZSBjbGFpbSB0byB2YWx1ZXMgaW4gdGhlICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZp ZWxkLCBhbmQgd2hhdCBhIG1pc21hdGNoIG1pZ2h0IG1lYW4uIFRoZSBkb2N1bWVudCBzYXlzIGVs c2V3aGVyZSB0aGF0IHRoZSBzaWduYXR1cmUgbWlnaHQgb25seSBjb3ZlciBzb21lIG9mIHRoZSBy LXZhbHVlcywgd2hpY2ggbWFrZXMgaXQgZW50aXJlbHkgcG9zc2libGUgdGhhdCB0aGUgJ1Jlc291 cmNlLVByaW9yaXR5JyBmaWVsZCBtaWdodCBjb250YWluIG1vcmUgdmFsdWVzIHRoYW4gYXJlIHNp Z25lZC4gT24gdGhlIG90aGVyIGhhbmQsIGludGVybWVkaWFyaWVzIG1pZ2h0IHJlYXNvbmFibHkg cmVtb3ZlIHItdmFsdWVzIGFzIHRoZSBjYWxsIGlzIHByb2Nlc3NlZC4gVGhpcyBwcm9iYWJseSBt ZWFucyB0aGF0IHRob3NlIHJlbW92ZWQgcHJpb3JpdGllcyBzaG91bGQgbm90IGJlIHVzZWQsIGV2 ZW4gaWYgdGhleSBhcmUgcHJlc2VudCBpbiB0aGUgcGFzc3BvcnQuIEl0IHNlZW1zIHJlYXNvbmFi bGUgdG8gc2F5IHRoYXQgKnR5cGljYWwqIHByb2Nlc3NpbmcgYnkgYSByZWNlaXZpbmcgcGFydHkg d291bGQgYmUgdG8gdGFrZSB0aGUgKnVuaW9uKiBvZiBhbGwgUlBIIHBhc3Nwb3J0cyB0aGF0IHRo ZXkgdHJ1c3QsIGFuZCAqaW50ZXJzZWN0KiB0aGF0IHdpdGggdGhlIHByaW9yaXRpZXMgaW4gJ1Jl c291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGRzIHRvIGdldCB0aGUgYWN0dWFsIHByaW9yaXR5 IG9yIHByaW9yaXRpZXMgdG8gYmUgYXBwbGllZCB0byB0aGUgY2FsbCAoc3ViamVjdCB0byBsb2Nh bCBwb2xpY3kpLg0KDQoNCiAgIHByaW9yaXR5IHRyZWF0bWVudCBpbiBhY2NvcmRhbmNlIHdpdGgg bG9jYWwgcG9saWN5IGZvciB0aGUgYXNzb2NpYXRlZA0KICAgY29tbXVuaWNhdGlvbiBzZXJ2aWNl Lg0KDQogICBJbiBhZGRpdGlvbiwgW0ktRC5pZXRmLXN0aXItcmZjNDQ3NGJpc10gU2VjdGlvbiA2 LjIgU3RlcCA0IHJlcXVpcmVzDQogICAiaWF0IiB2YWx1ZSBpbiAicnBoIiBjbGFpbSB0byBiZSB2 ZXJpZmllZC4NCg0KICAgVGhlIGJlaGF2aW9yIG9mIGEgU0lQIFVBcyB1cG9uIHJlY2VpdmluZyBh biBJTlZJVEUgY29udGFpbmluZyBhDQoNCg0KDQoiLi4ub2YgYSBTSVAgVUEgdXBvbi4uLiINCg0K b3INCg0KIi4uLm9mIFNJUCBVQXMgdXBvbi4uLiINCg0KDQogICBQQVNTcG9yVCBvYmplY3Qgd2l0 aCBhICJycGgiIGNsYWltIHdpbGwgbGFyZ2VseSByZW1haW4gYSBtYXR0ZXIgb2YNCiAgIGltcGxl bWVudGF0aW9uIHBvbGljeSBmb3IgdGhlIHNwZWNpZmljIGNvbW11bmljYXRpb24gc2VydmljZS4g IEluDQogICBtb3N0IGNhc2VzLGltcGxlbWVudGF0aW9ucyB3b3VsZCBhY3QgYmFzZWQgb24gY29u ZmlkZW5jZSBpbiB0aGUNCg0KDQoNCiIuLi5jYXNlcywgaW1wbGVtZW50YXRpb25zLi4uIg0KDQoo c3BhY2UgYWZ0ZXIgY29tbWEpDQoNCg0KICAgdmVyYWNpdHkgb2YgdGhpcyBpbmZvcm1hdGlvbi4g IFRoZSB1c2Ugb2YgdGhlIGNvbXBhY3QgZm9ybSBvZg0KDQoNCg0KUGFyYWdyYXBoIGJyZWFrIGJl Zm9yZSAiVGhlIi4NCg0KDQogICBQQVNTcG9yVCBpcyBub3Qgc3BlY2lmaWVkIGluIHRoaXMgZG9j dW1lbnQuDQoNCjUuICBGdXJ0aGVyIEluZm9ybWF0aW9uIEFzc29jaWF0ZWQgd2l0aCBSZXNvdXJj ZS1Qcmlvcml0eQ0KDQoNCg0KU2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5 Jy4NCg0KDQoNCiAgIFRoZXJlIG1heSBiZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBjYWxsaW5nIHBhcnR5IG9yIHRoZQ0KICAgY2FsbCB0aGF0IGNvdWxkIGJlIHJlbGV2YW50IHRv IGF1dGhvcml6YXRpb24gZm9yIFJlc291cmNlLVByaW9yaXR5Lg0KDQoNCg0KU2luZ2xlIHF1b3Rl cyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy4NCg0KDQogICBUaGlzIG1heSBpbmNsdWRlIGlu Zm9ybWF0aW9uIHJlbGF0ZWQgdG8gdGhlIGRldmljZSBzdWJzY3JpcHRpb24gb2YNCiAgIHRoZSBj YWxsZXIsIG9yIHRvIGFueSBpbnN0aXR1dGlvbnMgdGhhdCB0aGUgY2FsbGVyIG9yIGRldmljZSBp cw0KICAgYXNzb2NpYXRlZCB3aXRoLCBvciBldmVuIGNhdGVnb3JpZXMgb2YgaW5zdGl0dXRpb25z LiAgQWxsIG9mIHRoZXNlDQogICBkYXRhIGVsZW1lbnRzIHdvdWxkIGJlbmVmaXQgZnJvbSB0aGUg c2VjdXJlIGF0dGVzdGF0aW9ucyBwcm92aWRlZCBieQ0KICAgdGhlIFNUSVIgYW5kIFBBU1Nwb3JU IGZyYW1ld29ya3MuICBUaGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgInJwaCINCiAgIGNsYWltIGNv dWxkIGVudGFpbCB0aGUgb3B0aW9uYWwgcHJlc2VuY2Ugb2Ygb25lIG9yIG1vcmUgc3VjaA0KICAg YWRkaXRpb25hbCBpbmZvcm1hdGlvbiBmaWVsZHMuDQoNCiAgIEEgbmV3IElBTkEgcmVnaXN0cnkg aGFzIGJlZW4gZGVmaW5lZCB0byBob2xkIHBvdGVudGlhbCB2YWx1ZXMgb2YgdGhlDQogICAicnBo IiBhcnJheTsgc2VlIFNlY3Rpb24gNi4yLiAgVGhlIGRlZmluaXRpb24gb2YgdGhlICJycGgiIGNs YWltIG1heQ0KICAgaGF2ZSBvbmUgb3IgbW9yZSBzdWNoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g ZmllbGQocykuICBEZXRhaWxzIG9mDQogICBzdWNoICJycGgiIGNsYWltIHRvIGVuY29tcGFzcyBv dGhlciBkYXRhIGVsZW1lbnRzIGFyZSBsZWZ0IGZvciBmdXR1cmUNCiAgIHZlcnNpb24gb2YgdGhp cyBzcGVjaWZpY2F0aW9uLg0KDQo2LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQo2LjEuICBKU09O IFdlYiBUb2tlbiBDbGFpbXMgUmVnaXN0cmF0aW9uDQoNCg0KDQpJIHRoaW5rIHRoZXJlJ3Mgc29t ZSBjb25mdXNpb24gaGVyZS4gWW91J3JlIHJlZ2lzdGVyaW5nIGEgUEFTU3BvclQgcHB0IHZhbHVl LCBub3QgYSBuZXcgSldUIGNsYWltLiBUaGF0IGlzIHRvIHNheSwgeW91J3JlIGFkZGluZyBhbiBl bnRyeSB0byB0aGlzIHRhYmxlOg0KDQpodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9w YXNzcG9ydC9wYXNzcG9ydC54aHRtbA0KDQpOb3QgdG8gdGhpcyB0YWJsZToNCg0KaHR0cHM6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvand0L2p3dC54aHRtbA0KDQpZb3Ugd291bGQgb25seSB1 c2UgdGhlIHNlY29uZCB0YWJsZSBpZiB5b3UgaGFkIGEgbmV3IGtleSB0byBhZGQgdG8gdGhlIFBB U1Nwb3JUIGhlYWRlciAtLSB0aGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgZG8gdGhhdC4NCg0K VGhpcyBzZWN0aW9uIGFsc28gbmVlZHMgc29tZSBpbnRyb2R1Y3RvcnkgdGV4dCB0byBsZXQgdGhl IElBTkEga25vdyBleGFjdGx5IHdoYXQgdG8gZG87IGUuZy4gIlRoaXMgZG9jdW1lbnQgcmVnaXN0 ZXJzIGEgbmV3IHZhbHVlIGZvciB0aGUgIlBlcnNvbmFsIEFzc2VydGlvbiBUb2tlbiAoUEFTU3Bv clQpIEV4dGVuc2lvbnMiIHRhYmxlLg0KDQogICBvICBwcHQgdmFsdWU6ICJycGgiDQoNCiAgIG8g IFNwZWNpZmljYXRpb24gRG9jdW1lbnQocyk6IFNlY3Rpb24gMyBvZiBbUkZDVGhpc10NCg0KNi4y LiAgUEFTU3BvclQgJ3JwaCcgVHlwZXMNCg0KICAgVGhpcyBkb2N1bWVudCByZXF1ZXN0cyB0aGF0 IHRoZSBJQU5BIGFkZCBhIG5ldyBlbnRyeSB0byB0aGUgUEFTU3BvclQNCiAgIFR5cGVzIHJlZ2lz dHJ5IGZvciB0aGUgdHlwZSAicnBoIiB3aGljaCBpcyBzcGVjaWZpZWQgaW4gW1JGQ1RoaXNdLg0K DQoNCg0KVGhlcmUgaXNuJ3QgYW4gSUFOQSB0YWJsZSBjYWxsZWQgIlBBU1Nwb3JUIFR5cGVzLiIg SSBwcmVzdW1lIHRoaXMgaXMgdGhlIHJlZ2lzdHJhdGlvbiB3ZSBqdXN0IGRpc2N1c3NlZCBpbiBz ZWN0aW9uIDYuMSwgYW5kIHNvIHRoZSBhYm92ZSB0d28gbGluZXMgY2FuIGJlIHJlbW92ZWQuDQoN Cg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGFsc28gcmVxdWVzdHMgdGhhdCB0aGUgSUFOQSBjcmVh dGUgYSBuZXcgcmVnaXN0cnkNCiAgIGZvciBQQVNTcG9yVCAicnBoIiB0eXBlcy4gIFJlZ2lzdHJh dGlvbiBvZiBuZXcgUEFTU3BvclQgInJwaCIgdHlwZXMNCiAgIHNoYWxsIGJlIHVuZGVyIHRoZSBz cGVjaWZpY2F0aW9uIHJlcXVpcmVkIHBvbGljeS4gIFRoaXMgcmVnaXN0cnkgaXMNCiAgIHRvIGJl IGluaXRpYWxseSBwb3B1bGF0ZWQgd2l0aCBhIHNpbmdsZSB2YWx1ZSBmb3IgImF1dGgiIHdoaWNo IGlzDQogICBzcGVjaWZpZWQgaW4gW1JGQ1RoaXNdLg0KDQoNCg0KVGhpcyBuZWVkcyB0byBiZSB2 ZXJ5IGNsZWFyIGFib3V0IHRoZSBmaWVsZHMgdG8gYmUgaW5jbHVkZWQgaW4gdGhpcyBuZXcgcmVn aXN0cnkgKGUuZy4sICJSZWdpc3RyeSBlbnRyaWVzIG11c3QgY29udGFpbiB0d28gZmllbGRzOiB0 aGUgbmFtZSBvZiB0aGUgJ3JwaCcgdHlwZSBhbmQgdGhlIHNwZWNpZmljYXRpb24gaW4gd2hpY2gg dGhlIHR5cGUgaXMgZGVzY3JpYmVkIikuDQoNCg0KDQo3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMNCg0KICAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRpc2N1c3NlZCBpbiBbSS1ELmll dGYtc3Rpci1yZmM0NDc0YmlzXQ0KICAgaW4gU2VjdGlvbiAxMCBhcmUgYXBwbGljYWJsZSBoZXJl Lg0KDQo3LjEuICBBdm9pZGFuY2Ugb2YgcmVwbGF5IGFuZCBjdXQgYW5kIHBhc3RlIGF0dGFja3MN Cg0KICAgVGhlIFBBU1Nwb3JUIGV4dGVuc2lvbiB3aXRoIGEgInBwdCIgdmFsdWUgb2YgInJwaCIg TVVTVCBvbmx5IGJlIHNlbnQNCiAgIHdpdGggU0lQIElOVklURSB3aGVuICdSZXNvdXJjZS1Qcmlv cml0eScgaGVhZGVyIGlzIHVzZWQgdG8gY29udmV5IHRoZQ0KDQoNCg0KIi4uLmhlYWRlciBmaWVs ZC4uLiINCg0KDQogICBwcmlvcml0eSBvZiB0aGUgY29tbXVuaWNhdGlvbiBhcyBkZWZpbmVkIGlu IFtSRkM0NDEyXS4gIFRvIGF2b2lkIHRoZQ0KICAgcmVwbGF5LCBhbmQgY3V0IGFuZCBwYXN0ZSBh dHRhY2tzLCB0aGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW4NCiAgIFNlY3Rpb24gMTAuMSBvZiBb SS1ELmlldGYtc3Rpci1yZmM0NDc0YmlzXSBNVVNUIGJlIGZvbGxvd2VkLg0KDQo3LjIuICBTb2x1 dGlvbiBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgdXNlIG9mIGV4dGVuc2lvbiB0byBQQVNTcG9y VCB0b2tlbnMgd2l0aCAicHB0IiB2YWx1ZSAicnBoIiBiYXNlZA0KICAgb24gdGhlIHZhbGlkYXRp b24gb2YgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlIGFuZCB0aGUgYXNzb2NpYXRlZA0KICAgY2VydGlm aWNhdGUgcmVxdWlyZXMgY29uc2lkZXJhdGlvbiBvZiB0aGUgYXV0aGVudGljYXRpb24gYW5kDQog ICBhdXRob3JpdHkgb3IgcmVwdXRhdGlvbiBvZiB0aGUgc2lnbmVyIHRvIGF0dGVzdCB0byB0aGUg aWRlbnRpdHkgYmVpbmcNCiAgIGFzc2VydGVkLiAgVGhlIGZvbGxvd2luZyBjb25zaWRlcmF0aW9u cyBzaG91bGQgYmUgcmVjb2duaXplZCB3aGVuDQogICB1c2luZyBQQVNTcG9yVCBleHRlbnNpb24g d2l0aCAicHB0IiB2YWx1ZSBvZiAicnBoIjoNCg0KICAgbyAgQW4gYXV0aG9yaXR5IChzaWduZXIp IGlzIG9ubHkgYWxsb3dlZCB0byBzaWduIHRoZSBjb250ZW50IG9mIGEgU0lQDQogICAgICAnUmVz b3VyY2UtUHJpb3JpdHknIGhlYWRlciBmb3Igd2hpY2ggaXQgaGFzIHRoZSByaWdodCBhdXRob3Jp dHkuDQoNCg0KDQoiLi4uaGVhZGVyIGZpZWxkLi4uIg0KDQoNCiAgICAgIFRoZSBhdXRob3JpdHkg dGhhdCBzaWducyB0aGUgdG9rZW4gTVVTVCBoYXZlIGEgc2VjdXJlIG1ldGhvZCBmb3INCiAgICAg IGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBlbmQgdXNlciBvciB0aGUgZGV2aWNlLg0KDQogICBvICBU aGUgdmVyaWZpY2F0aW9uIG9mIHRoZSBzaWduYXR1cmUgTVVTVCBpbmNsdWRlIG1lYW5zIG9mIHZl cmlmeWluZw0KICAgICAgdGhhdCB0aGUgc2lnbmVyIGlzIGF1dGhvcml0YXRpdmUgZm9yIHRoZSBz aWduZWQgY29udGVudCBvZiB0aGUgU0lQDQoNCg0KDQpJdCdzIG5vdCBjbGVhciB3aGF0IGF1dGhv cml0eSBpcyBiZWluZyBjbGFpbWVkIGhlcmUuIElzIHRoaXMgc3VwcG9zZWQgdG8gbWVhbiBzb21l dGhpbmcgbGlrZSAiLi4udmVyaWZ5aW5nIHRoYXQgdGhlIHNpZ25lciBpcyBhdXRob3JpdGF0aXZl IGZvciB0aGUgb3JpZ2luYXRpbmcgdG4gaW4gdGhlIFBBU1Nwb3JULi4uIj8gT3IgIi4uLmF1dGhv cml0YXRpdmUgZm9yIHRoZSByZXNvdXJjZSBwcmlvcml0eSBuYW1lc3BhY2UgaW4gdGhlIFBBU1Nw b3JUPyIgV2hhdGV2ZXIgdGhlIHNlcnZlciBpcyBwdXJwb3J0ZWRseSBhdXRob3JpdGF0aXZlIGZv ciBuZWVkcyB0byBiZSBjbGVhcmx5IHNwZWxsZWQgb3V0Lg0KDQoNCiAgICAgICdSZXNvdXJjZS1Q cmlvcml0eScgaGVhZGVyLg0KDQoNCg0KIi4uLmhlYWRlciBmaWVsZC4iDQoNCg0KL2ENCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnN0aXIgbWFpbGlu ZyBsaXN0DQpzdGlyQGlldGYub3JnPG1haWx0bzpzdGlyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B6C153849ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnR0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5NjA1NzM1MDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi01OTUzMDU1MjA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxDQoJe21zby1saXN0LWlkOjEwMzI3MzEyNDY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x MTA2MzI3Nzg4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0K CXttc28tbGlzdC1pZDoxOTQ5OTYzMzE3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODU5MTE4 NTQ2O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMw0KCXttc28t bGlzdC1pZDoyMDIyNTgyMzMwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzE0MDAzNDA7fQ0K QGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNt O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5UaGUgdGV4dCBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IOKAnFRoZSBjcmVkZW50aWFscyAoZS5nLiwgYXV0aG9y aXR5IHJlc3BvbnNpYmxlIGZvciBhdXRob3JpemluZyBSZXNvdXJjZS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IFByaW9yaXR5KSB1c2Vk IHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlIG11c3QgaGF2ZSBhdXRob3JpdHkgb3ZlciB0aGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IG5h bWVzcGFjZSBvZiB0aGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIGFuZCB0aGVyZSBpcyBvbmx5IG9u ZSBhdXRob3JpdHkgcGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPiZuYnNwOyZuYnNwOyBjbGFpbS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPklmIHRoZSBjcmVkZW50aWFscyBkb27igJl0IG5lZWQgdG8gaGF2ZSBhdXRob3Jp dHkgb2YgdGhlIG90aGVyIGNsYWltcyAoZS5nLiwg4oCcb3JpZ+KAnSkgaW4gdGhlIFJQSCBQQVNT UG9yVCBJIHRoaW5rIHlvdSBzaG91bGQgZXhwbGljaXRseQ0KIHNheSBzby48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBTdWJpciBEYXMgW21haWx0bzpzdWJpcmRhczIx QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwMiBGZWJydWFyeSAyMDE4IDAxOjA0PGJy Pg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQWRhbSBSb2FjaCAmbHQ7YWRhbUBub3N0cnVt LmNvbSZndDs7IFNUSVIgQ2hhaXJzICZsdDtzdGlyLWNoYWlyc0BpZXRmLm9yZyZndDs7IHN0aXJA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtc3Rpci1ycGguYWxsQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc3Rpcl0gQUQgUmV2aWV3OiBkcmFmdC1pZXRmLXN0aXItcnBoLTAy IC0gYXV0aG9yaXR5IHRvIGFzc2VydCB0aGUgY2FsbGVycyBpZGVudGl0eSBhc3N1bWVkPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBDaHJpc3Rlciw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBz aWduaW5nIGVudGl0eSBkb2VzIG5vdCBoYXZlIGFsd2F5cyB0aGUgYXV0aG9yaXR5IHRvIGFzc2Vy dCB0aGUgY2FsbGVyIGlkZW50aXR5IGluIHJwaC4gV2UgYXJlIHN1Ym1pdHRpbmcgdmVyLTAzIGRy YWZ0Jm5ic3A7IGFuZCBpdCBpcyBjbGFyaWZpZWQmbmJzcDsgYXMgZm9sbG93czo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mcXVvdDtUaGUgY3JlZGVudGlhbHMgKGUuZy4sIGF1dGhvcml0eSBy ZXNwb25zaWJsZSBmb3IgYXV0aG9yaXppbmcgUmVzb3VyY2UtUHJpb3JpdHkpIHVzZWQgdG8gY3Jl YXRlIHRoZSBzaWduYXR1cmUgbXVzdCBoYXZlIGF1dGhvcml0eSBvdmVyIHRoZSBuYW1lc3BhY2Ug b2YgdGhl4oCccnBoJnF1b3Q7DQogY2xhaW0uLiZxdW90OyA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4tU3ViaXINCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gMjIsIDIwMTggYXQgMzoyNyBQ TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Bbm90aGVyIHF1ZXN0aW9uIGZvciBj bGFyaWZpY2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlNlY3Rpb24gMyBjb250YWlucyB0aGUgZm9sbG93aW5nIGV4YW1wbGU6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsg JnF1b3Q7b3JpZyZxdW90Ozp7JnF1b3Q7dG4mcXVvdDs6JnF1b3Q7PC9zcGFuPjxhIGhyZWY9InRl bDooMjE1KSUyMDU1NS0xMjEyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xMjE1 NTU1MTIxMjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZxdW90O308 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZGVzdCZx dW90Ozp7WyZxdW90O3RuJnF1b3Q7OiZxdW90Ozwvc3Bhbj48YSBocmVmPSJ0ZWw6KDIxMiklMjA1 NTUtMTIxMyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MTIxMjU1NTEyMTM8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mcXVvdDtdfSw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7OjE0NDMy MDgzNDUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90 O3JwaCZxdW90Ozp7JnF1b3Q7YXV0aCZxdW90OzpbJnF1b3Q7ZXRzLjAmcXVvdDssJnF1b3Q7d3Bz LjAmcXVvdDtdfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PuKApmFuZCB0aGUgZm9sbG93aW5nIHRleHQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IOKAnFRoZSBjcmVkZW50aWFscyAoZS5nLiwg YXV0aG9yaXR5IHJlc3BvbnNpYmxlIGZvciBhdXRob3JpemluZyBSZXNvdXJjZS08L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgUHJpb3JpdHkpIHVzZWQgdG8gY3JlYXRlIHRoZSBzaWdu YXR1cmUgbXVzdCBoYXZlIGF1dGhvcml0eSBvdmVyIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyAmcXVvdDtycGgmcXVvdDsgY2xhaW3igKbigJ0NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tMjkzODc0NzkwNjEyMzIw MzQ5NF9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2luY2UgdGhlIGNsYWltIGFsc28gY29udGFpbnMg 4oCcb3JpZ+KAnSwgaXMgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgc2lnbmluZyBlbnRpdHkgYWx3 YXlzIGFsc28gaGFzIGF1dGhvcml0eQ0KIHRvIGFzc2VydCB0aGUgY2FsbGVycyBpZGVudGl0eT8g SSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGV4cGxpY2l0bHkgbWVudGlvbiBpdC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzdGlyDQogW21haWx0bzo8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnN0aXItYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BZGFtIFJv YWNoPGJyPg0KPGI+U2VudDo8L2I+IDIwIEphbnVhcnkgMjAxOCAwMDoxNTxicj4NCjxiPlRvOjwv Yj4gU1RJUiBDaGFpcnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c3Rpci1jaGFpcnNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5zdGly LWNoYWlyc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86c3RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnN0aXJAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1zdGlyLXJwaC5hbGxAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5kcmFmdC1pZXRmLXN0aXItcnBoLmFsbEB0b29s cy5pZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFtzdGlyXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtc3Rpci1ycGgtMDI8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkknbSBkb2luZyBteSBBRCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1zdGlyLXJwaC0wMi4gVGhhbmtzIHRvIGV2ZXJ5b25lIHdobyBoYXMgd29ya2Vk IG9uIHRoaXMgZG9jdW1lbnQsIGFuZCB0aGUgYXV0aG9ycyBhbmQgY2hhaXJzIGluIHBhcnRpY3Vs YXIuPG86cD48L286cD48L3A+DQo8cD5UaGUgdGVjaG5pY2FsIGNvbnRlbnQgaGVyZSBsb29rcyBn ZW5lcmFsbHkgZ29vZCB0byBtZS4gSSdkIGxpa2UgdG8gc2VlIGEgZmV3IGlzc3VlcyBhZGRyZXNz ZWQgYmVmb3JlIElFVEYgTEMuIEluIHNob3J0IHN1bWFyeTo8bzpwPjwvbzpwPjwvcD4NCjx1bCB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzMiPg0KVGhlIHZhbGlkYXRpb24gc2VjdGlvbiBuZWVkcyB0byBhZGQgYSBkaXNjdXNzaW9uIG9m IGhvdyB0byB0cmVhdCBjYWxscyB3aGVuIHRoZSBwcmlvcml0eSB2YWx1ZXMgaW4gJnF1b3Q7cnBo JnF1b3Q7IHBhc3Nwb3J0cyBhbmQgU0lQICZxdW90O1Jlc291cmNlLVByaW9yaXR5JnF1b3Q7IGhl YWRlciBmaWVsZHMgYXJlbid0IDEwMCUgaWRlbnRpY2FsLjxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NClRoZSBleGFtcGxlcyBu ZWVkIHNvbWUgYWRqdXN0bWVudC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpUaGVyZSBpcyBhIG1pbm9yIHBvaW50IG9mIGFt YmlndWl0eSBpbiB0aGUgU2VjdXJpdHkgU2VjdGlvbiwgYnV0IHRoaXMgc2hvdWxkIGJlIGVhc3kg dG8gZml4LCBhcyBsb25nIGFzIHRoZSBXRyBrbm93cyB3aGF0IHdhcyBpbnRlbmRlZC48bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+ DQpUaGUgSUFOQSBhY3Rpb25zIG5lZWQgYSBsaXR0bGUgYml0IG9mIGFkanVzdG1lbnQuPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMi Pg0KVGhlcmUgYXJlIGEgbnVtYmVyIG9mIG1pbm9yIGVkaXRvcmlhbCBpc3N1ZXMgdG8gYmUgY2xl YW5lZCB1cC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPkRldGFpbGVkIGNvbW1lbnRzIG9uIHRo ZXNlIHBvaW50cyBhcmUgaW5saW5lIGluIHRoZSBkb2N1bWVudCBiZWxvdy4gSSd2ZSByZW1vdmVk IHNvbWUgcG9ydGlvbnMgb2YgdGhlIGRvY3VtZW50IG9uIHdoaWNoIEkgaGF2ZSBubyBjb21tZW50 cy48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+QWJzdHJhY3Q8L3R0Pjxicj4NCjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBTVElSIFBBU1Nwb3JU IHNwZWNpZmljYXRpb24gdG8gYWxsb3cgdGhlPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLnRoZSBT ZWN1cmUgVGVsZXBob25lIElkZW50aXR5IFJldmlzaXRlZCAoU1RJUikgUGVyc29uYWwgQXNzZXJ0 aW9uIFRva2VuIChQQVNTcG9yVCkgc3BlY2lmaWNhdGlvbiBkZWZpbmVkIGluIFJGQyA4MTIyLi4u JnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4oU2VlIDxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dCIgdGFyZ2V0PSJfYmxhbmsi Pg0KJmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5z aW9uLnR4dCZndDs8L2E+IGZvciBndWlkYW5jZSBvbiBhYmJyZXZpYXRpb25zKTxvOnA+PC9vOnA+ PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgaW5jbHVzaW9u IG9mIGNyeXB0b2dyYXBoaWNhbGx5LXNpZ25lZCBhc3NlcnRpb25zIG9mIGF1dGhvcml6YXRpb24g Zm9yPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgdGhlIHZhbHVl cyBwb3B1bGF0ZWQgaW4gdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCw8 L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgd2hpY2ggaXMgdXNlZCBmb3IgY29tbXVuaWNhdGlv bnMgcmVzb3VyY2UgcHJpb3JpdGl6YXRpb24uPC90dD48YnI+DQo8YnI+DQo8dHQ+Li4uPC90dD48 YnI+DQo8YnI+DQo8dHQ+MS4mbmJzcDsgSW50cm9kdWN0aW9uPC90dD48YnI+DQo8YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IFBBU1Nwb3JUIFtJLUQuaWV0Zi1zdGlyLXBhc3Nwb3J0XSBpcyBhIHRva2Vu IGZvcm1hdCBiYXNlZCBvbiBKV1Q8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgW1JGQzc1MTld IGZvciBjb252ZXlpbmcgY3J5cHRvZ3JhcGhpY2FsbHktc2lnbmVkIGluZm9ybWF0aW9uIGFib3V0 PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoZSBpZGVudGl0aWVzIGludm9sdmVkIGluIHBl cnNvbmFsIGNvbW11bmljYXRpb25zOyBpdCBpcyB1c2VkIHdpdGg8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgU1RJUiBbSS1ELmlldGYtc3Rpci1yZmM0NDc0YmlzXSB0byBjb252ZXkgYSBzaWdu ZWQgYXNzZXJ0aW9uIG9mIHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpZGVudGl0eSBv ZiB0aGUgcGFydGljaXBhbnRzIGluIHJlYWwtdGltZSBjb21tdW5pY2F0aW9ucyBlc3RhYmxpc2hl ZDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB2aWEgYSBwcm90b2NvbCBsaWtlIFNJUC4mbmJz cDsgVGhpcyBzcGVjaWZpY2F0aW9uIGV4dGVuZHMgUEFTU3BvclQgdG88L3R0Pjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+ JnF1b3Q7Li4ubGlrZSBTSVAgW1JGQzMyNjFdLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4o V2Ugd2FudCB0byBjaXRlIFNJUCB0aGUgZmlyc3QgdGltZSBpdCBpcyBtZW50aW9uZWQpPG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBhbGxv dyBjcnlwdG9ncmFwaGljLXNpZ25pbmcgb2YgdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhl YWRlcjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGZpZWxkIGRl ZmluZWQgaW4gW1JGQzQ0MTJdLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBbUkZD NDQxMl0gZGVmaW5lcyB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGZv cjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9ucyBSZXNvdXJjZSBQcmlv cml0eS4mbmJzcDsgQXMgc3BlY2lmaWVkIGluIFtSRkM0NDEyXSwgdGhlPC90dD48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7ICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIG1heSBiZSB1c2Vk IGJ5IFNJUCB1c2VyIGFnZW50czwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBbUkZDMzI2MV0s IGluY2x1ZGluZywgUHVibGljIFN3aXRjaGVkIFRlbGVwaG9uZSBOZXR3b3JrIChQU1ROKTwvdHQ+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cD4mcXVvdDsuLi5pbmNsdWRpbmcgUHVibGljIFN3aXRjaGVkLi4uJnF1b3Q7PG86 cD48L286cD48L3A+DQo8cD4ocmVtb3ZlIHRoZSBjb21tYSk8bzpwPjwvbzpwPjwvcD4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGdhdGV3YXlzIGFuZCB0ZXJtaW5h bHMsIGFuZCBTSVAgcHJveHkgc2VydmVycyB0byBpbmZsdWVuY2U8L3NwYW4+PC90dD48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1 b3Q7Li4uYW5kIGJ5IFNJUCBwcm94eSBzZXJ2ZXJzLCB0byBpbmZsdWVuY2UuLi4mcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjxwPihhZGQgJnF1b3Q7YnkmcXVvdDsgYW5kIGNvbW1hKTxvOnA+PC9vOnA+ PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgcHJpb3JpdGl6 YXRpb24gYWZmb3JkZWQgdG8gY29tbXVuaWNhdGlvbiBzZXNzaW9ucyxpbmNsdWRpbmcgUFNUTjwv c3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLnNlc3Npb25zLCBpbmNs dWRpbmcuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPihzcGFjZSBhZnRlciBjb21tYSk8bzpw PjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGNh bGxzLiZuYnNwOyBIb3dldmVyLCB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZp ZWxkIGNvdWxkIGJlPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsg c3Bvb2ZlZCBhbmQgYWJ1c2VkIGJ5IHVuYXV0aG9yaXplZCBlbnRpdGllcy48L3R0Pjxicj4NCjxi cj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIFNUSVIgYXJjaGl0ZWN0dXJlIFtSRkM3MzQwXWFzc3Vt ZXMgdGhhdCBhbiBhdXRob3JpdHkgb24gdGhlPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLlNUSVIg YXJjaGl0ZWN0dXJlIFtSRkM3MzQwXSBhc3N1bWVzLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8 cD4oc3BhY2UgYmVmb3JlICZxdW90O2Fzc3VtZXMmcXVvdDspPG86cD48L286cD48L3A+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBvcmlnaW5hdGluZyBzaWRlIG9m IGEgY2FsbCBwcm92aWRlcyBhIGNyeXB0b2dyYXBoaWMgYXNzdXJhbmNlIG9mIHRoZTwvc3Bhbj48 L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHZhbGlkaXR5IG9mIHRoZSBjYWxs aW5nIHBhcnR5IG51bWJlciBpbiBvcmRlciB0byBwcmV2ZW50PC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IGltcGVyc29uYXRpb24gYXR0YWNrcy4mbmJzcDsgVGhlIFNUSVIgYXJjaGl0ZWN0dXJl IGFsbG93cyBleHRlbnNpb24gdGhhdDwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5hbGxvd3MgZXh0 ZW5zaW9ucy4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mbmJzcDsmbmJzcDsgY2FuIGJlIHV0aWxpemVkIGJ5IGF1dGhvcml0aWVzIHN1cHBvcnRp bmcgcmVhbC10aW1lIGNvbW11bmljYXRpb248L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBzZXJ2aWNlcyB1c2luZyB0aGUgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFk ZXIgZmllbGQgdG88L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgY3J5cHRvZ3JhcGhpY2FsbHkg c2lnbiB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGFuZDwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyBjb252ZXkgYXNzZXJ0aW9uIG9mIHRoZSBhdXRob3JpemF0aW9u IGZvciAnUmVzb3VyY2UtUHJpb3JpdHknLiZuYnNwOyBGb3I8L3R0Pjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgZXhhbXBsZSwgdGhlIGF1dGhvcml0eSBvbiB0aGUgb3JpZ2luYXRpbmcgc2lkZSB2ZXJp ZnlpbmcgdGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGF1dGhvcml6YXRpb24gb2YgYSBw YXJ0aWN1bGFyIGNvbW11bmljYXRpb24gZm9yIFJlc291cmNlLVByaW9yaXR5IGNhbjwvdHQ+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cD5TaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLjxvOnA+PC9v OnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgdXNlIGEg UEFTU1BvclQgY2xhaW0gdG8gY3J5cHRvZ3JhcGhpY2FsbHktc2lnbiB0aGUgU0lQICdSZXNvdXJj ZS08L3NwYW4+PC90dD48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uY3J5cHRvZ3JhcGhpY2FsbHkgc2lnbi4uLiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJz cDsgUHJpb3JpdHknIGhlYWRlciBmaWVsZCBhbmQgY29udmV5IGFuIGFzc2VydGlvbiBvZiB0aGUg YXV0aG9yaXphdGlvbjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IGZvciAnUmVzb3VyY2UtUHJpb3JpdHknLiZuYnNwOyBUaGlzIHdpbGwgYWxsb3cgYSByZWNlaXZp bmcgZW50aXR5PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IChpbmNsdWRpbmcgZW50aXRpZXMg bG9jYXRlZCBpbiBkaWZmZXJlbnQgbmV0d29yayBkb21haW5zL2JvdW5kYXJpZXMpPC90dD48YnI+ DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRvIHZlcmlmeSB0aGUgdmFsaWRpdHkgb2YgYXNzZXJ0aW9ucyBh dXRob3JpemluZyBSZXNvdXJjZS1Qcmlvcml0eS48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+U2luZ2xlIHF1b3Rl cyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IENyeXB0b2dyYXBoaWNhbGx5LXNpZ25lZCBT SVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXJzIHdpbGwgYWxsb3cgYTwvc3Bhbj48L3R0Pjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cD4mcXVvdDsuLi5jcnlwdG9ncmFwaGljYWxseSBzaWduZWQgU0lQICdSZXNvdXJjZS1Qcmlvcml0 eScgaGVhZGVyIGZpZWxkcy4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+KHJlbW92ZSBoeXBo ZW4sIGFuZCByZXBsYWNlICZxdW90O2hlYWRlcnMmcXVvdDsgd2l0aCAmcXVvdDtoZWFkZXIgZmll bGRzJnF1b3Q7KTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m bmJzcDsmbmJzcDsgcmVjZWl2aW5nIGVudGl0eSB0byB2ZXJpZnkgYW5kIGFjdCBvbiB0aGUgaW5m b3JtYXRpb24gd2l0aCBjb25maWRlbmNlPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4m bmJzcDsmbmJzcDsgdGhhdCB0aGUgaW5mb3JtYXRpb24gaGF2ZSBub3QgYmVlbiBzcG9vZmVkIG9y IGNvbXByb21pc2VkLjwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5oYXMgbm90IGJlZW4gc3Bvb2Zl ZCBvciBjb21wcm9taXNlZC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5i c3A7Jm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBkb2N1bWVudHMgYW4gb3B0aW9uYWwgZXh0ZW5z aW9uIHRvIFBBU1Nwb3JUIGFuZDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB0aGUgYXNzb2Np YXRlZCBTVElSIG1lY2hhbmlzbXMgdG8gcHJvdmlkZSBhIGZ1bmN0aW9uIHRvIHNpZ24gdGhlIFNJ UDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBm aWVsZC4mbmJzcDsgVGhpcyBQQVNTcG9yVCBvYmplY3QgaXMgdXNlZCB0bzwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBwcm92aWRlIGF0dGVzdGF0aW9uIG9mIGEgY2FsbGluZyB1c2VyIGF1dGhv cml6YXRpb24gZm9yIHByaW9yaXR5PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNvbW11bmlj YXRpb25zLiZuYnNwOyBUaGlzIGlzIG5lY2Vzc2FyeSBpbiBhZGRpdGlvbiB0byB0aGUgUEFTU3Bv clQgb2JqZWN0PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoYXQgaXMgdXNlZCBmb3IgY2Fs bGluZyB1c2VyIHRlbGVwaG9uZSBudW1iZXIgYXR0ZXN0YXRpb24uJm5ic3A7IEhvdyB0aGU8L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFBBU1Nwb3JUIGlz IHVzZWQgZm9yIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uczwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBzdXBwb3J0ZWQgdXNpbmcgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxk IGlzIGRlZmluZWQgaW48L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgb3RoZXIgZG9jdW1lbnRz IGFuZCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LjwvdHQ+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cD5JIGFzc3VtZSB0aGVzZSBvdGhlciBkb2N1bWVudHMgYXJlIHVuZGVyIGRldmVsb3BtZW50PyBJ ZiBzbywgdGhleSBzaG91bGQgYmUgY2l0ZWQgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+ DQo8dHQ+Mi4mbmJzcDsgVGVybWlub2xvZ3k8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJz cDsgVGhlIGtleSB3b3JkcyAmcXVvdDtNVVNUJnF1b3Q7LCAmcXVvdDtNVVNUIE5PVCZxdW90Oywg JnF1b3Q7UkVRVUlSRUQmcXVvdDssICZxdW90O1NIQUxMJnF1b3Q7LCAmcXVvdDtTSEFMTCBOT1Qm cXVvdDssPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7ICZxdW90O1NIT1VMRCZxdW90OywgJnF1 b3Q7U0hPVUxEIE5PVCZxdW90OywgJnF1b3Q7UkVDT01NRU5ERUQmcXVvdDssICZxdW90O01BWSZx dW90OywgYW5kICZxdW90O09QVElPTkFMJnF1b3Q7IGluIHRoaXM8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBS RkMgMjExOSBbUkZDMjExOV0uPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgZG9jdW1lbnQgaGFzIHNldmVy YWwgbm9uLW5vcm1hdGl2ZSB1c2VzIG9mICZxdW90O211c3QmcXVvdDssICZxdW90O3Nob3VsZCwm cXVvdDsgYW5kICZxdW90O21heSwmcXVvdDsgYW5kIHNvIGl0IG5lZWRzIHRvIHVzZSB0aGUgUkZD ODE3NCBib2lsZXJwbGF0ZSBpbnN0ZWFkIG9mIHRoZSBSRkMyMTE5IGJvaWxlcnBsYXRlLjxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4zLiZuYnNwOyBQQVNTcG9yVCAncnBoJyBDbGFpbTwv dHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5l cyBhIG5ldyBKU09OIFdlYiBUb2tlbiBjbGFpbSBmb3IgJnF1b3Q7cnBoJnF1b3Q7LDwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyB3aGljaCBwcm92aWRlcyBhbiBhc3NlcnRpb24gZm9yIGluZm9y bWF0aW9uIGluIFNJUCAnUmVzb3VyY2UtPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFByaW9y aXR5J2hlYWRlci48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uUHJpb3JpdHknIGhlYWRlciBmaWVs ZC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPihzcGFjZSBhZnRlciBjbG9zaW5nIHF1b3RhdGlv biBtYXJrLCAmcXVvdDtoZWFkZXIgZmllbGQmcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDtoZWFkZXIm cXVvdDspPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGUgY3Jl YXRvciBvZiBhIFBBU1Nwb3JUIG9iamVjdCBhZGRzIGEgJnF1b3Q7cHB0JnF1b3Q7IHZhbHVlIG9m ICZxdW90O3JwaCZxdW90OyB0byB0aGU8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgaGVhZGVy IG9mIGEgUEFTU3BvclQgb2JqZWN0LCBpbiB3aGljaCBjYXNlIHRoZSBQQVNTcG9yVCBjbGFpbXMg TVVTVDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBjb250YWluIGEgJnF1b3Q7cnBoJnF1b3Q7 IGNsYWltLCBhbmQgYW55IGVudGl0aWVzIHZlcmlmeWluZyB0aGUgUEFTU3BvclQgb2JqZWN0PC90 dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHdpbGwgYmUgcmVxdWlyZWQgdG8gdW5kZXJzdGFuZCB0 aGUgJnF1b3Q7cHB0JnF1b3Q7IGV4dGVuc2lvbiBpbiBvcmRlciB0bzwvdHQ+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyBwcm9jZXNzIHRoZSBQQVNTcG9yVCBpbiBxdWVzdGlvbi4mbmJzcDsgQSBQQVNT UG9yVCBoZWFkZXIgd2l0aCB0aGUgJnF1b3Q7cHB0JnF1b3Q7PC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IGluY2x1ZGVkIHdpbGwgbG9vayBhcyBmb2xsb3dzOjwvdHQ+PGJyPg0KPGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyB7Jm5ic3A7ICZxdW90O3R5cCZxdW90OzomcXVvdDtwYXNzcG9ydCZxdW90 Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7cHB0JnF1b3Q7 OiZxdW90O3JwaCZxdW90Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7YWxnJnF1b3Q7OiZxdW90O0VTMjU2JnF1b3Q7LDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmcXVvdDt4NXUmcXVvdDs6PC90dD48L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ JnF1b3Q7aHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXImcXVvdDs8L3NwYW4+PC9hPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+fTwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5JZGVhbGx5 LCB0aGlzIHdvdWxkIGJlIGVpdGhlciBwcmV0dHktcHJpbnRlZCBvciBjYW5vbmljYWxpemVkLiBT aW5jZSBpdCdzIHRvbyBsb25nIHRvIGZpdCBvbiBhIGxpbmUgaW4gY2Fub25pY2FsIGZvcm0sIEkg cHJvcG9zZTo8bzpwPjwvbzpwPjwvcD4NCjxwPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+ezwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7ICZxdW90O3R5cCZx dW90OzomcXVvdDtwYXNzcG9ydCZxdW90Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsgJnF1b3Q7cHB0 JnF1b3Q7OiZxdW90O3JwaCZxdW90Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsgJnF1b3Q7YWxnJnF1 b3Q7OiZxdW90O0VTMjU2JnF1b3Q7LDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyAmcXVvdDt4NXUmcXVv dDs6PC90dD48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXIi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7aHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcv Y2VydC5jZXImcXVvdDs8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+fTwvdHQ+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlICZxdW90O3Jw aCZxdW90OyBjbGFpbSB3aWxsIHByb3ZpZGUgYW4gYXNzZXJ0aW9uIG9mIGF1dGhvcml6YXRpb24s JnF1b3Q7YXV0aCZxdW90Oyw8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uYXV0aG9yaXphdGlvbiwg JnF1b3Q7YXV0aCZxdW90OywgLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4oc3BhY2UgYmV0 d2VlbiBjb21tYSBhbmQgb3BlbmluZyBxdW90YXRpb24gbWFyayk8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGZvciBpbmZvcm1hdGlvbiBp biB0aGUgU0lQICZxdW90O1Jlc291cmNlLVByaW9yaXR5JnF1b3Q7IGhlYWRlciBmaWVsZCAoaS5l Liw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBSZXNvdXJjZS1Q cmlvcml0eTogbmFtZXNwYWNlICZxdW90Oy4mcXVvdDsgci1wcmlvcml0eSkgYmFzZWQgb24gW1JG QzQ0MTJdLjwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD5UaGUgdXNlIG9mIHRoZSBzdHJpbmcgJ25hbWVzcGFjZSAm cXVvdDsuJnF1b3Q7IHItcHJpb3JpdHknIGhlcmUgYW5kIGVsc2V3aGVyZSBpbiB0aGUgZG9jdW1l bnQgaGFzIGEgZGV0cmltZW50YWwgaW1wYWN0IG9uIHJlYWRhYmlsaXR5LiBJIHN0cm9uZ2x5IHN1 Z2dlc3QgcmVwbGFjaW5nIGl0IHdpdGggJnF1b3Q7ci12YWx1ZSZxdW90OyAodGhlIG5hbWUgb2Yg dGhpcyBwcm9kdWN0aW9uIGluIFJGQzQ0MTIpIGV2ZXJ5d2hlcmUuPG86cD48L286cD48L3A+DQo8 cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBTcGVjaWZpY2FsbHksIHRo ZSAmcXVvdDtycGgmcXVvdDsgY2xhaW0gaW5jbHVkZXMgYXNzZXJ0aW9uIG9mIHRoZSBwcmlvcml0 eS08L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBsZXZlbCBvZiB0 aGUgdXNlciB0byBiZSB1c2VkIGZvciBhIGdpdmVuIGNvbW11bmljYXRpb24gc2Vzc2lvbi4mbmJz cDsgVGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHZhbHVlIG9mIHRoZSAmcXVvdDtycGgm cXVvdDsgY2xhaW0gaXMgYW4gYXJyYXkgY29udGFpbmluZyBvbmUgb3IgbW9yZSBvZiBKU09OPC90 dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IG9iamVjdHMgZm9yIHRoZSBjb250ZW50IG9mIHRoZSBT SVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgdGhhdCBpczwvdHQ+PGJyPg0KPHR0PiZuYnNw OyZuYnNwOyBiZWluZyBhc3NlcnRlZCBvZiB3aGljaCBvbmUgb2YgdGhlICZxdW90O3JwaCZxdW90 OyBvYmplY3QsIGlzIG1hbmRhdG9yeS48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBsYXN0IHNlbnRlbmNl IGlzIHZlcnkgaGFyZCB0byBwYXJzZTsgYW5kIChiYXNlZCBvbiB0aGUgZXhhbXBsZSkgdGhlIHZh bHVlIGlzIGludGVuZGVkIHRvIGJlIGEgSlNPTiBPYmplY3QgKGN1cmx5IGJyYWNlcykgcmF0aGVy IHRoYW4gYSBKU09OIEFycmF5IChzcXVhcmUgYnJhY2VzKS4gSSBzdWdnZXN0OiAnVGhlIHZhbHVl IG9mIHRoZSAmcXVvdDtycGgmcXVvdDsgY2xhaW0gaXMgYW4gT2JqZWN0IHdpdGggb25lIG9yIG1v cmUga2V5cy4gRWFjaCBrZXkNCiBpcyBhc3NvY2lhdGVkIHdpdGggYSBKU09OIEFycmF5LiBUaGVz ZSBhcnJheXMgY29udGFpbiBTdHJpbmdzIHRoYXQgY29ycmVzcG9uZCB0byB0aGUgci12YWx1ZXMg aW5kaWNhdGVkIGluIHRoZSBTSVAgJnF1b3Q7UmVzb3VyY2UtUHJpb3JpdHkmcXVvdDsgaGVhZGVy IGZpZWxkLicgKG5vdGU6ICZxdW90O2hlYWRlciBmaWVsZCZxdW90Oywgbm90ICZxdW90O2hlYWRl ciZxdW90Oyk8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSBm b2xsb3dpbmcgaXMgYW4gZXhhbXBsZSAmcXVvdDtycGgmcXVvdDsgY2xhaW0gZm9yIGEgU0lQICZx dW90O1Jlc291cmNlLVByaW9yaXR5JnF1b3Q7PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGhl YWRlciBmaWVsZCB3aXRoIGEgJnF1b3Q7bmFtZXNwYWNlICZxdW90Oy4mcXVvdDsgci1wcmlvcml0 eSZxdW90OyB2YWx1ZSBvZiAmcXVvdDtldHMuMCZxdW90OyBhbmQ8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgd2l0aCBhICZxdW90O25hbWVzcGFjZSAmcXVvdDsuJnF1b3Q7IHItcHJpb3JpdHkm cXVvdDsgdmFsdWUgb2YgJnF1b3Q7d3BzLjAmcXVvdDsuPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5i c3A7Jm5ic3A7Jm5ic3A7IHsgJnF1b3Q7b3JpZyZxdW90Ozp7JnF1b3Q7dG4mcXVvdDs6JnF1b3Q7 PC90dD48L3NwYW4+PGEgaHJlZj0idGVsOigyMTUpJTIwNTU1LTEyMTIiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+MTIxNTU1NTEyMTI8L3NwYW4+PC9hPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+JnF1b3Q7fTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Rlc3QmcXVvdDs6e1smcXVvdDt0biZxdW90OzomcXVv dDs8L3R0Pjwvc3Bhbj48YSBocmVmPSJ0ZWw6KDIxMiklMjA1NTUtMTIxMyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4xMjEyNTU1MTIxMzwvc3Bhbj48L2E+PHR0PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mcXVvdDtdfSw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtpYXQmcXVvdDs6MTQ0MzIwODM0NSw8L3R0Pjxi cj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7cnBoJnF1b3Q7OnsmcXVvdDth dXRoJnF1b3Q7OlsmcXVvdDtldHMuMCZxdW90OywmcXVvdDt3cHMuMCZxdW90O119PC90dD48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwPkFzIGFib3ZlLCBJIHJlY29tbWVuZCBwcmV0dHktcHJpbnRpbmcgdGhpcy4gSXQncyBh bHNvIG1pc3NpbmcgYSBjb21tYSBhZnRlciB0aGUgJnF1b3Q7b3JpZyZxdW90OyB2YWx1ZSwgYW5k IHRoZSB0b3AtbGV2ZWwgc3RydWN0dXJlIGlzIG1pc3NpbmcgYSBjbG9zaW5nIGJyYWNlLiBUaGUg dmFsdWUgZm9yICZxdW90O2lhdCZxdW90OyBuZWVkcyB0byBiZSBlbmNsb3NlZCBpbiBxdW90ZXMu PG86cD48L286cD48L3A+DQo8cD5UaGUgTkFOUEEgaGFzIGFsbG9jYXRlZCBOUEE1NTUwMXh4IGZv ciBleGFtcGxlIHVzZSwgbm90IE5QQTU1NXh4eHgsIG11Y2ggb2Ygd2hpY2ggcmVtYWlucyBhc3Np Z25hYmxlIChjZg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cubmF0aW9uYWxuYW5wYS5jb20vcGRmL05S VUYvQVRJUy0wMzAwMTE1LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KJmx0O2h0dHBzOi8vd3d3Lm5h dGlvbmFsbmFucGEuY29tL3BkZi9OUlVGL0FUSVMtMDMwMDExNS5wZGYmZ3Q7PC9hPikuPG86cD48 L286cD48L3A+DQo8cD5QdXR0aW5nIGFsbCB0aGlzIHRvZ2V0aGVyLCBJIGJlbGlldmUgd2hhdCB5 b3Ugd2FudCBpczo8bzpwPjwvbzpwPjwvcD4NCjxwPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+ezwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7ICZxdW90O29y aWcmcXVvdDs6eyZxdW90O3RuJnF1b3Q7OiZxdW90OzwvdHQ+PC9zcGFuPjxhIGhyZWY9InRlbDoo MjE1KSUyMDU1NS0wMTEyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEyMTU1NTUwMTEyPC9z cGFuPjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90O30sPC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsgJnF1b3Q7ZGVzdCZxdW90Ozp7WyZxdW90 O3RuJnF1b3Q7OiZxdW90OzwvdHQ+PC9zcGFuPjxhIGhyZWY9InRlbDooMjEyKSUyMDU1NS0wMTEz IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEyMTI1NTUwMTEzPC9zcGFuPjwvYT48dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90O119LDwvc3Bhbj48L3R0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQo8dHQ+Jm5ic3A7ICZxdW90O2lhdCZxdW90OzomcXVvdDsxNDQzMjA4MzQ1JnF1b3Q7 LDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyAmcXVvdDtycGgmcXVvdDs6eyZxdW90O2F1dGgmcXVvdDs6 WyZxdW90O2V0cy4wJnF1b3Q7LCZxdW90O3dwcy4wJnF1b3Q7XX08L3R0Pjxicj4NCjx0dD59PC90 dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBBZnRl ciB0aGUgaGVhZGVyIGFuZCBjbGFpbXMgUEFTU3BvclQgb2JqZWN0cyBoYXZlIGJlZW4gY29uc3Ry dWN0ZWQsPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoZWlyIHNpZ25hdHVyZSBpcyBnZW5l cmF0ZWQgbm9ybWFsbHkgcGVyIHRoZSBndWlkYW5jZSBpbjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBbSS1ELmlldGYtc3Rpci1wYXNzcG9ydF0gdXNpbmcgdGhlIGZ1bGwgZm9ybSBvZiBQQVNT UG9yVC4mbmJzcDsgVGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNyZWRlbnRpYWxzIChl LmcuLCBhdXRob3JpdHkgcmVzcG9uc2libGUgZm9yIGF1dGhvcml6aW5nIFJlc291cmNlLTwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBQcmlvcml0eSkgdXNlZCB0byBjcmVhdGUgdGhlIHNpZ25h dHVyZSBtdXN0IGhhdmUgYXV0aG9yaXR5IG92ZXIgdGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7ICZxdW90O3JwaCZxdW90OyBjbGFpbSBhbmQgdGhlcmUgaXMgb25seSBvbmUgYXV0aG9yaXR5 IHBlciBjbGFpbS4mbmJzcDsgVGhlIGF1dGhvcml0eTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyBNVVNUIHVzZSBpdHMgY3JlZGVudGlhbHMgKGkuZS4sIENFUlQpIGFzc29jaWF0ZWQgd2l0aCB0 aGUgc3BlY2lmaWM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgc2VydmljZSBzdXBwb3J0ZWQg YnkgdGhlIFNJUCBuYW1lc3BhY2UgaW4gdGhlIGNsYWltLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PjQu Jm5ic3A7ICdycGgnIGluIFNJUDwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGlz IHNlY3Rpb24gc3BlY2lmaWVzIFNJUC1zcGVjaWZpYyB1c2FnZSBmb3IgdGhlICZxdW90O3JwaCZx dW90OyBjbGFpbSBpbjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBQQVNTcG9yVC48L3R0Pjxi cj4NCjxicj4NCjx0dD40LjEuJm5ic3A7IEF1dGhlbnRpY2F0aW9uIFNlcnZpY2UgQmVoYXZpb3I8 L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIEF1dGhlbnRpY2F0aW9uIFNlcnZp Y2Ugd2lsbCBjcmVhdGUgdGhlICZxdW90O3JwaCZxdW90OyBjbGFpbSB1c2luZyB0aGU8L3R0Pjxi cj4NCjx0dD4mbmJzcDsmbmJzcDsgdmFsdWVzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDMgYmFzZWQg b24gW1JGQzQ0MTJdLiZuYnNwOyBUaGUgY29uc3RydWN0aW9uPC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IG9mICZxdW90O3JwaCZxdW90OyBjbGFpbSBmb2xsb3dzIHRoZSBzdGVwcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiA0IG9mPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFtJLUQuaWV0Zi1z dGlyLXJmYzQ0NzRiaXNdLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGUgcmVz dWx0aW5nIElkZW50aXR5IGhlYWRlciBmb3IgJnF1b3Q7cnBoJnF1b3Q7IG1pZ2h0IGxvb2sgYXMg Zm9sbG93czo8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uaGVhZGVyIGZpZWxkLi4uJnF1b3Q7PG86 cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyAmcXVvdDtleUpoYkdjaU9p SkZVekkxTmlJc0luUjVjQ0k2SWtwWFZDSjkuZXlKcGMzTWlPaUpsZVVvd1pWaEJhVTlwU25kPC90 dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFpXRTU2WTBjNWVXUkRTWE5FVVc5cFkwaENNRWxxYjJs amJrSnZTV2wzVGtOcFNtaGlSMk5wVDJsS1JsVjZTVEZPPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IGFVbHpSRkZ2YVdWRVZqRkphbkJ2WkVoU2QyTjZiM1pNTTJRelpIazFiR1ZIUm5SalIzaHNU RzFPZG1KVE9XcGFXPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IEVvd1RHMU9iR051TUU1RFp6 QkxJSHg4NG9DWkx1S0FtWHg4SUdWNVFXbGlNMHB3V25sSk5tVjVTakJpYVVrMlNXPC90dD48YnI+ DQo8dHQ+Jm5ic3A7Jm5ic3A7IHBGZVUxVVZURk9WRlY0VFdwRmVVbHVNRTVEYVVwcldsaE9NRWxx Y0RkWGVVb3dZbWxKTmtscVJYbE5WRWt4VGxSPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFZl RTFxUlhwSmJERTVURUV3UzBsdGJHaGtRMGsyVFZSUk1FMTZTWGRQUkUwd1RsTjNUa05wU25salIy ZHBUMjV6PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGFWbFlWakJoUTBrMlYzbEtiR1JJVFhW TlEwbHpTVzVrZDJONU5IZEpiREU1UkZGdlBTSjkuczM3UzZWQzhITTZEPC90dD48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IGw2WXpKZVFEc3JaY3dKMGxpenhoVXJBN2ZfOThvV0JIdm8tY2wtbjhNSWhv Q3IxOHZZWUZ5M2JsWHZzM2ZzbE1fPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IG9vczJQMkR5 dyZxdW90OzsgaW5mbz0gPC90dD48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuZXhhbXBsZS5v cmcvY2VydC5jZXIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JnF1b3Q7aHR0cHM6Ly93d3cu ZXhhbXBsZS5vcmcvY2VydC5jZXImcXVvdDs8L3NwYW4+PC9hPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+O2FsZz1FUzI1Njs8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBwcHQ9JnF1b3Q7cnBoJnF1b3Q7PC90dD48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgZXhh bXBsZSBoYXMgYSBudW1iZXIgb2YgaXNzdWVzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+DQpJ biB0aGUgSWRlbnRpdHkgaGVhZGVyIGZpZWxkLCB0aGUgc2lnbmVkLWlkZW50aXR5LWRpZ2VzdCBz aG91bGRuJ3QgYmUgcXVvdGVkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwzIGxldmVsMSBsZm82Ij4NCkluIHRoZSBJZGVudGl0eSBoZWFkZXIgZmllbGQs IGluZm8gaXMgZW5jbG9zZWQgaW4gJmx0OyZndDsgcmF0aGVyIHRoYW4gJnF1b3Q7JnF1b3Q7Ljxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBs Zm82Ij4NCkluIHRoZSBJZGVudGl0eSBoZWFkZXIgZmllbGQsIHBwdCBpcyBhIHRva2VuIHJhdGhl ciB0aGFuIGEgcXVvdGVkIHN0cmluZy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+DQpUaGUgc2lnbmVkLWlkZW50aXR5LWRpZ2Vz dCBoZWFkZXIgbmVlZHMgdG8gaW5kaWNhdGUgYSAmcXVvdDt0eXAmcXVvdDsgb2YgJnF1b3Q7cGFz c3BvcnQmcXVvdDsgcmF0aGVyIHRoYW4gSldULCBhbmQgaXQgbmVlZHMgdG8gaW5jbHVkZSBib3Ro IGEgJnF1b3Q7cHB0JnF1b3Q7IGFuZCAmcXVvdDt4NXUmcXVvdDsgZmllbGQuPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPg0KVGhl IHNpZ25lZC1pZGVudGl0eS1kaWdlc3QgYm9keSBzaG91bGQgY29udGFpbiBvbmx5IHRoZSBwYXNz cG9ydCBjbGFpbSByYXRoZXIgdGhhbiBhIEpTT04gb2JqZWN0IHRoYXQgaXRzZWxmIGNvbnRhaW5z IGEgYmFzZTY0LWVuY29kZWQgSldTIGhlYWRlciBjb25jYXRlbmF0ZWQgd2l0aCBhIGNsYWltLjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBs Zm82Ij4NCkkgYmVsaWV2ZSB0aGF0LCBldmVuIHdoZW4gdGhlIGJvZHkgaXMgaW5jbHVkZWQsIHZh bHVlcyBpbiB0aGUgaGVhZGVyIGFuZCBib2R5IG5lZWQgdG8gYmUgYmUgY2Fub25pY2FsaXplZCAo aS5lLiwgYWxsIG9uIG9uZSBsaW5lLCBubyBzcGFjZXMsIGluIGFscGhhYmV0aWNhbCBvcmRlciwg ZXRjLik8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPkkgd291bGQgYWxzbyByZWNvbW1lbmQgZm9s bG93aW5nIHRoZSBjb252ZW50aW9uIG9mIGluZGljYXRpbmcgdGhhdCBsaW5lLXdyYXBzIGFyZSBv bmx5IGZvciByZWFkYWJpbGl0eSwgYW5kIGluY2x1ZGluZyB0aGUgaGVhZGVyIGZpZWxkIG5hbWUg aW4gdGhlIGV4YW1wbGUuIFB1dHRpbmcgYWxsIHRoaXMgdG9nZXRoZXIsIEkgYmVsaWV2ZSB3aGF0 IHlvdSB3YW50IGlzOjxvOnA+PC9vOnA+PC9wPg0KPHA+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgRm9yIGV4YW1wbGUsIGEgSWRlbnRpdHkgaGVhZGVyIGZp ZWxkIGZvciAmcXVvdDtycGgmcXVvdDsgbWlnaHQgbG9vazwvc3Bhbj48L3R0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGFzIGZvbGxvd3MgKGJhY2tzbGFzaGVzIHNob3duIGZvciBs aW5lIGZvbGRpbmcgb25seSk6PC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBJZGVudGl0eTogZXlKaGJH Y2lPaUpGVXpJMU5pSXNJbkJ3ZENJNkluSndhQ0lzSW5SNWNDSTZJbkJoYzNOd2IzSjBJIFw8L3Nw YW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpd2llRFYxSWpvaWFIUjBj SE02THk5M2QzY3VaWGhoYlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlFvLmV5SmtaWE4wIFw8L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgSWpwN1d5SjBiaUk2SWpFeU1USTFOVFV3TVRFeklsMTlM Q0pwWVhRaU9pSXhORFF6TWpBNE16UTFJaXdpYjNKcFp5SSBcPC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IDZleUowYmlJNklqRXlNVFUxTlRVd01URXlJbjBzSW5Kd2FDSTZleUpoZFhSb0lqcGJJ bVYwY3k0d0lpd2lkM0J6TGogXDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBBaVhYMTlDZy5z MzdTNlZDOEhNNkRsNll6SmVRRHNyWmN3SjBsaXp4aFVyQTdmXzk4b1dCSHZvLWNsLW44TUlob0Ny IFw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgMTh2WVlGeTNibFh2czNmc2xNX29vczJQMkR5 dztpbmZvPSZsdDs8L3R0Pjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5leGFtcGxlLm9yZy9j ZXJ0LmNlciIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5odHRwczovL3d3dy5leGFtcGxlLm9y Zy9jZXJ0LmNlcjwvc3Bhbj48L2E+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4g XDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7ICZndDs7YWxnPUVT MjU2O3BwdD1ycGg8L3R0Pjxicj4NCjwvc3Bhbj48YnI+DQooTm90ZTogdGhpcyBleGFtcGxlIGFz c3VtZXMgdGhlIGNhbGxpbmcgYW5kIGNhbGxlZCBwYXJ0eSBudW1iZXJzIGluIHRoZSBwcmV2aW91 cyBleGFtcGxlIGFyZSBjaGFuZ2VkIHRvDQo8YSBocmVmPSJ0ZWw6KDIxNSklMjA1NTUtMDExMiIg dGFyZ2V0PSJfYmxhbmsiPjEyMTU1NTUwMTEyPC9hPiBhbmQgPGEgaHJlZj0idGVsOigyMTUpJTIw NTU1LTAxMTMiIHRhcmdldD0iX2JsYW5rIj4NCjEyMTU1NTUwMTEzPC9hPiwgcmVzcGVjdGl2ZWx5 KTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgQSBTSVAgYXV0aGVu dGljYXRpb24gc2VydmljZSB0eXBpY2FsbHkgd2lsbCBkZXJpdmUgdGhlIHZhbHVlIG9mICZxdW90 O3JwaCZxdW90OzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBmcm9tIHRoZSAnUmVzb3VyY2Ut UHJpb3JpdHknIGhlYWRlciBmaWVsZCBiYXNlZCBvbiBwb2xpY3kgYXNzb2NpYXRlZDwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyB3aXRoIHNlcnZpY2Ugc3BlY2lmaWMgdXNlIG9mIHRoZSAmcXVv dDtuYW1lc3BhY2UgJnF1b3Q7LiZxdW90OyByLXByaW9yaXR5JnF1b3Q7IHZhbHVlczwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyBiYXNlZCBvbiBbUkZDNDQxMl0uJm5ic3A7IFRoZSBhdXRoZW50 aWNhdGlvbiBzZXJ2aWNlIGRlcml2ZXMgdGhlIHZhbHVlIG9mPC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IHRoZSBQQVNTUG9yVCBjbGFpbSBieSB2ZXJpZnlpbmcgdGhlIGF1dGhvcml6YXRpb24g Zm9yIFJlc291cmNlLTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBQcmlvcml0eSAoaS5lLiwg dmVyaWZ5aW5nIGEgY2FsbGluZyB1c2VyIHByaXZpbGVnZSBmb3IgUmVzb3VyY2UtPC90dD48YnI+ DQo8dHQ+Jm5ic3A7Jm5ic3A7IFByaW9yaXR5IGJhc2VkIG9uIGl0cyBpZGVudGl0eSkgd2hpY2gg bWlnaHQgYmUgZGVyaXZlZCBmcm9tIGN1c3RvbWVyPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IHByb2ZpbGUgZGF0YSBvciBmcm9tIGFjY2VzcyB0byBleHRlcm5hbCBzZXJ2aWNlcy48L3R0Pjxi cj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgW1JGQzQ0MTJdIGFsbG93cyBtdWx0aXBsZSAmcXVv dDtuYW1lc3BhY2UgJnF1b3Q7LiZxdW90OyByLXByaW9yaXR5JnF1b3Q7IHBhaXJzLCBlaXRoZXIg aW48L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYSBzaW5nbGUgU0lQIFJlc291cmNlLVByaW9y aXR5IGhlYWRlciBvciBhY3Jvc3MgbXVsdGlwbGUgU0lQPC90dD48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmdsZSBx dW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScuPG86cD48L286cD48L3A+DQo8cD4mcXVv dDsuLi5oZWFkZXIgZmllbGQuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFJlc291cmNlLVByaW9yaXR5IGhlYWRlcnMuJm5i c3A7IEhvd2V2ZXIsIGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gc2lnbiBhbGw8L3NwYW4+PC90dD48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHA+U2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpwPjwv cD4NCjxwPiZxdW90Oy4uLmhlYWRlciBmaWVsZHMuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGNvbnRlbnQgb2YgYSBTSVAg UmVzb3VyY2UtUHJpb3JpdHkgaGVhZGVyIG9yIGFsbCBTSVAgUmVzb3VyY2UtPC9zcGFuPjwvdHQ+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPlNpbmdsZSBxdW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScuPG86cD48L286cD48 L3A+DQo8cD4mcXVvdDsuLi5oZWFkZXIgZmllbGQuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFByaW9yaXR5IGhlYWRlcnMg aW4gYSBnaXZlbiBTSVAgbWVzc2FnZS4mbmJzcDsgQW4gYXV0aG9yaXR5IGlzIG9ubHk8L3NwYW4+ PC90dD48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+U2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwv bzpwPjwvcD4NCjxwPiZxdW90Oy4uLmhlYWRlciBmaWVsZHMuLi4mcXVvdDs8bzpwPjwvbzpwPjwv cD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IHJlc3BvbnNpYmxl IGZvciBzaWduaW5nIHRoZSBjb250ZW50IG9mIGEgU0lQIFJlc291cmNlLVByaW9yaXR5IGhlYWRl cjwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cD5TaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHkn LjxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uaGVhZGVyIGZpZWxkLi4uJnF1b3Q7PG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBmb3Ig d2hpY2ggaXQgaGFzIGF1dGhvcml0eSAoZS5nLiwgYSBzcGVjaWZpYyAmcXVvdDtuYW1lc3BhY2Ug JnF1b3Q7LiZxdW90Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IHItcHJpb3JpdHkmcXVvdDspLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PjQuMi4mbmJzcDsgVmVyaWZp Y2F0aW9uIFNlcnZpY2UgQmVoYXZpb3I8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsg W0ktRC5pZXRmLXN0aXItcmZjNDQ3NGJpc10gU2VjdGlvbiA2LjIgU3RlcCA1IHJlcXVpcmVzIHRo YXQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbnMgZGVmaW5pbmcgJnF1 b3Q7cHB0JnF1b3Q7IHZhbHVlcyBkZXNjcmliZSBhbnkgYWRkaXRpb25hbCB2ZXJpZmllcjwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBiZWhhdmlvci4mbmJzcDsgVGhlIGJlaGF2aW9yIHNwZWNp ZmllZCBmb3IgdGhlICZxdW90O3BwdCZxdW90OyB2YWx1ZXMgb2YgJnF1b3Q7cnBoJnF1b3Q7IGlz IGFzPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGZvbGxvd3M6PC90dD48YnI+DQo8YnI+DQo8 dHQ+Jm5ic3A7Jm5ic3A7IFRoZSB2ZXJpZmljYXRpb24gc2VydmljZSBNVVNUIGV4dHJhY3QgdGhl IHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGU8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgJnF1 b3Q7YXV0aCZxdW90OyBrZXkgaW4gYSBmdWxsIGZvcm0gUEFTU1BvclQgd2l0aCBhICZxdW90O3Bw dCZxdW90OyB2YWx1ZSBvZiAmcXVvdDtycGgmcXVvdDsuJm5ic3A7IElmPC90dD48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IHRoZSBzaWduYXR1cmUgdmFsaWRhdGVzLCB0aGVuIHRoZSB2ZXJpZmljYXRp b24gc2VydmljZSBjYW4gdXNlIHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB2YWx1ZSBv ZiB0aGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIGFzIHZhbGlkYXRpb24gdGhhdCB0aGUgY2FsbGlu ZyBwYXJ0eSBpczwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBhdXRob3JpemVkIGZvciBSZXNv dXJjZS1Qcmlvcml0eSwgd2hpY2ggd291bGQgaW4gdHVybiBiZSB1c2VkIGZvcjwvdHQ+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmdsZSBxdW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Q cmlvcml0eScuPG86cD48L286cD48L3A+DQo8cD5UaGlzIHRleHQgaXMgYW1iaWd1b3VzIGFib3V0 IHdoZXRoZXIgdGhlIHZhbGlkYXRpb24gaW5kaWNhdGVzIHRoYXQgdGhlIGNhbGxpbmcgcGFydHkg aXMgYXV0aG9yaXplZCB0byB1c2UgdGhlIHByaW9yaXRpZXMgaW5kaWNhdGVkIGluIHRoZSBwYXNz cG9ydCBvYmplY3QsIG9yIHRoZSB2YWx1ZXMgaW4gdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHkn IGhlYWRlciBmaWVsZDsgYW5kICh0YWtlbiBvbiBpdHMgZmFjZSkgaW1wbGllcyB0aGUgbGF0dGVy LA0KIHdoZW4gdGhlIGludGVudGlvbiBoZXJlIHNob3VsZCBjbGVhcmx5IGJlIHRoZSBmb3JtZXIu PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5hdXRob3JpemVkIGZvciAnUmVzb3VyY2UtUHJp b3JpdHknIGluZGljYXRlZCBpbiB0aGUgY2xhaW0uIFRoaXMgdmFsdWUgd291bGQgaW4gdHVybiBi ZSB1c2VkIGZvci4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIHRleHQgYWxzbyBuZWVk cyB0byBzYXkgc29tZXRoaW5nIGFib3V0IGNvbXBhcmluZyB2YWx1ZXMgaW4gdGhlIGNsYWltIHRv IHZhbHVlcyBpbiB0aGUgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQsIGFuZCB3aGF0 IGEgbWlzbWF0Y2ggbWlnaHQgbWVhbi4gVGhlIGRvY3VtZW50IHNheXMgZWxzZXdoZXJlIHRoYXQg dGhlIHNpZ25hdHVyZSBtaWdodCBvbmx5IGNvdmVyIHNvbWUgb2YgdGhlIHItdmFsdWVzLCB3aGlj aCBtYWtlcw0KIGl0IGVudGlyZWx5IHBvc3NpYmxlIHRoYXQgdGhlICdSZXNvdXJjZS1Qcmlvcml0 eScgZmllbGQgbWlnaHQgY29udGFpbiBtb3JlIHZhbHVlcyB0aGFuIGFyZSBzaWduZWQuIE9uIHRo ZSBvdGhlciBoYW5kLCBpbnRlcm1lZGlhcmllcyBtaWdodCByZWFzb25hYmx5IHJlbW92ZSByLXZh bHVlcyBhcyB0aGUgY2FsbCBpcyBwcm9jZXNzZWQuIFRoaXMgcHJvYmFibHkgbWVhbnMgdGhhdCB0 aG9zZSByZW1vdmVkIHByaW9yaXRpZXMgc2hvdWxkIG5vdCBiZQ0KIHVzZWQsIGV2ZW4gaWYgdGhl eSBhcmUgcHJlc2VudCBpbiB0aGUgcGFzc3BvcnQuIEl0IHNlZW1zIHJlYXNvbmFibGUgdG8gc2F5 IHRoYXQgKnR5cGljYWwqIHByb2Nlc3NpbmcgYnkgYSByZWNlaXZpbmcgcGFydHkgd291bGQgYmUg dG8gdGFrZSB0aGUgKnVuaW9uKiBvZiBhbGwgUlBIIHBhc3Nwb3J0cyB0aGF0IHRoZXkgdHJ1c3Qs IGFuZCAqaW50ZXJzZWN0KiB0aGF0IHdpdGggdGhlIHByaW9yaXRpZXMgaW4gJ1Jlc291cmNlLVBy aW9yaXR5JyBoZWFkZXINCiBmaWVsZHMgdG8gZ2V0IHRoZSBhY3R1YWwgcHJpb3JpdHkgb3IgcHJp b3JpdGllcyB0byBiZSBhcHBsaWVkIHRvIHRoZSBjYWxsIChzdWJqZWN0IHRvIGxvY2FsIHBvbGlj eSkuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZu YnNwOyBwcmlvcml0eSB0cmVhdG1lbnQgaW4gYWNjb3JkYW5jZSB3aXRoIGxvY2FsIHBvbGljeSBm b3IgdGhlIGFzc29jaWF0ZWQ8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBjb21tdW5pY2F0aW9uIHNlcnZpY2UuPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IEluIGFkZGl0aW9uLCBbSS1ELmlldGYtc3Rpci1yZmM0NDc0YmlzXSBTZWN0aW9uIDYuMiBT dGVwIDQgcmVxdWlyZXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgJnF1b3Q7aWF0JnF1b3Q7 IHZhbHVlIGluICZxdW90O3JwaCZxdW90OyBjbGFpbSB0byBiZSB2ZXJpZmllZC48L3R0Pjxicj4N Cjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIGJlaGF2aW9yIG9mIGEgU0lQIFVBcyB1cG9uIHJl Y2VpdmluZyBhbiBJTlZJVEUgY29udGFpbmluZyBhPC90dD48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLm9m IGEgU0lQIFVBIHVwb24uLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPm9yPG86cD48L286cD48 L3A+DQo8cD4mcXVvdDsuLi5vZiBTSVAgVUFzIHVwb24uLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFBBU1Nwb3JUIG9iamVj dCB3aXRoIGEgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIHdpbGwgbGFyZ2VseSByZW1haW4gYSBtYXR0 ZXIgb2Y8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpbXBsZW1l bnRhdGlvbiBwb2xpY3kgZm9yIHRoZSBzcGVjaWZpYyBjb21tdW5pY2F0aW9uIHNlcnZpY2UuJm5i c3A7IEluPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IG1vc3QgY2FzZXMsaW1wbGVtZW50YXRp b25zIHdvdWxkIGFjdCBiYXNlZCBvbiBjb25maWRlbmNlIGluIHRoZTwvdHQ+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4m cXVvdDsuLi5jYXNlcywgaW1wbGVtZW50YXRpb25zLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8 cD4oc3BhY2UgYWZ0ZXIgY29tbWEpPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyB2ZXJhY2l0eSBvZiB0aGlzIGluZm9ybWF0aW9uLiZuYnNw OyBUaGUgdXNlIG9mIHRoZSBjb21wYWN0IGZvcm0gb2Y8L3NwYW4+PC90dD48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+UGFyYWdyYXBo IGJyZWFrIGJlZm9yZSAmcXVvdDtUaGUmcXVvdDsuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBQQVNTcG9yVCBpcyBub3Qgc3BlY2lmaWVk IGluIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjxicj4NCjx0dD41 LiZuYnNwOyBGdXJ0aGVyIEluZm9ybWF0aW9uIEFzc29jaWF0ZWQgd2l0aCBSZXNvdXJjZS1Qcmlv cml0eTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cD5TaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3Jp dHknLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlcmUgbWF5 IGJlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNhbGxpbmcgcGFydHkgb3IgdGhl PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNhbGwgdGhhdCBjb3VsZCBiZSByZWxldmFudCB0 byBhdXRob3JpemF0aW9uIGZvciBSZXNvdXJjZS1Qcmlvcml0eS48L3R0Pjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+U2lu Z2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFRoaXMgbWF5IGluY2x1ZGUg aW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgZGV2aWNlIHN1YnNjcmlwdGlvbiBvZjwvc3Bhbj48 L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoZSBjYWxsZXIsIG9yIHRvIGFu eSBpbnN0aXR1dGlvbnMgdGhhdCB0aGUgY2FsbGVyIG9yIGRldmljZSBpczwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBhc3NvY2lhdGVkIHdpdGgsIG9yIGV2ZW4gY2F0ZWdvcmllcyBvZiBpbnN0 aXR1dGlvbnMuJm5ic3A7IEFsbCBvZiB0aGVzZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBk YXRhIGVsZW1lbnRzIHdvdWxkIGJlbmVmaXQgZnJvbSB0aGUgc2VjdXJlIGF0dGVzdGF0aW9ucyBw cm92aWRlZCBieTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB0aGUgU1RJUiBhbmQgUEFTU3Bv clQgZnJhbWV3b3Jrcy4mbmJzcDsgVGhlIHNwZWNpZmljYXRpb24gb2YgdGhlICZxdW90O3JwaCZx dW90OzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBjbGFpbSBjb3VsZCBlbnRhaWwgdGhlIG9w dGlvbmFsIHByZXNlbmNlIG9mIG9uZSBvciBtb3JlIHN1Y2g8L3R0Pjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBmaWVsZHMuPC90dD48YnI+DQo8YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IEEgbmV3IElBTkEgcmVnaXN0cnkgaGFzIGJlZW4gZGVmaW5lZCB0byBob2xk IHBvdGVudGlhbCB2YWx1ZXMgb2YgdGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7ICZxdW90 O3JwaCZxdW90OyBhcnJheTsgc2VlIFNlY3Rpb24gNi4yLiZuYnNwOyBUaGUgZGVmaW5pdGlvbiBv ZiB0aGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIG1heTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyBoYXZlIG9uZSBvciBtb3JlIHN1Y2ggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBmaWVsZChzKS4m bmJzcDsgRGV0YWlscyBvZjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBzdWNoICZxdW90O3Jw aCZxdW90OyBjbGFpbSB0byBlbmNvbXBhc3Mgb3RoZXIgZGF0YSBlbGVtZW50cyBhcmUgbGVmdCBm b3IgZnV0dXJlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHZlcnNpb24gb2YgdGhpcyBzcGVj aWZpY2F0aW9uLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PjYuJm5ic3A7IElBTkEgQ29uc2lkZXJhdGlv bnM8L3R0Pjxicj4NCjxicj4NCjx0dD42LjEuJm5ic3A7IEpTT04gV2ViIFRva2VuIENsYWltcyBS ZWdpc3RyYXRpb248L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+SSB0aGluayB0aGVyZSdzIHNvbWUgY29uZnVzaW9u IGhlcmUuIFlvdSdyZSByZWdpc3RlcmluZyBhIFBBU1Nwb3JUIHBwdCB2YWx1ZSwgbm90IGEgbmV3 IEpXVCBjbGFpbS4gVGhhdCBpcyB0byBzYXksIHlvdSdyZSBhZGRpbmcgYW4gZW50cnkgdG8gdGhp cyB0YWJsZTo8bzpwPjwvbzpwPjwvcD4NCjxwPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlhbmEub3Jn L2Fzc2lnbm1lbnRzL3Bhc3Nwb3J0L3Bhc3Nwb3J0LnhodG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvcGFzc3BvcnQvcGFzc3BvcnQueGh0bWw8L2E+ PG86cD48L286cD48L3A+DQo8cD5Ob3QgdG8gdGhpcyB0YWJsZTo8bzpwPjwvbzpwPjwvcD4NCjxw PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2p3dC9qd3QueGh0bWwi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9qd3Qvand0 LnhodG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+WW91IHdvdWxkIG9ubHkgdXNlIHRoZSBzZWNv bmQgdGFibGUgaWYgeW91IGhhZCBhIG5ldyBrZXkgdG8gYWRkIHRvIHRoZSBQQVNTcG9yVCBoZWFk ZXIgLS0gdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IGRvIHRoYXQuPG86cD48L286cD48L3A+ DQo8cD5UaGlzIHNlY3Rpb24gYWxzbyBuZWVkcyBzb21lIGludHJvZHVjdG9yeSB0ZXh0IHRvIGxl dCB0aGUgSUFOQSBrbm93IGV4YWN0bHkgd2hhdCB0byBkbzsgZS5nLiAmcXVvdDtUaGlzIGRvY3Vt ZW50IHJlZ2lzdGVycyBhIG5ldyB2YWx1ZSBmb3IgdGhlICZxdW90O1BlcnNvbmFsIEFzc2VydGlv biBUb2tlbiAoUEFTU3BvclQpIEV4dGVuc2lvbnMmcXVvdDsgdGFibGUuPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJz cDsgbyZuYnNwOyBwcHQgdmFsdWU6ICZxdW90O3JwaCZxdW90OzwvdHQ+PGJyPg0KPGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBvJm5ic3A7IFNwZWNpZmljYXRpb24gRG9jdW1lbnQocyk6IFNlY3Rpb24g MyBvZiBbUkZDVGhpc108L3R0Pjxicj4NCjxicj4NCjx0dD42LjIuJm5ic3A7IFBBU1Nwb3JUICdy cGgnIFR5cGVzPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQg cmVxdWVzdHMgdGhhdCB0aGUgSUFOQSBhZGQgYSBuZXcgZW50cnkgdG8gdGhlIFBBU1Nwb3JUPC90 dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFR5cGVzIHJlZ2lzdHJ5IGZvciB0aGUgdHlwZSAmcXVv dDtycGgmcXVvdDsgd2hpY2ggaXMgc3BlY2lmaWVkIGluIFtSRkNUaGlzXS48L3R0Pjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHA+VGhlcmUgaXNuJ3QgYW4gSUFOQSB0YWJsZSBjYWxsZWQgJnF1b3Q7UEFTU3BvclQgVHlwZXMu JnF1b3Q7IEkgcHJlc3VtZSB0aGlzIGlzIHRoZSByZWdpc3RyYXRpb24gd2UganVzdCBkaXNjdXNz ZWQgaW4gc2VjdGlvbiA2LjEsIGFuZCBzbyB0aGUgYWJvdmUgdHdvIGxpbmVzIGNhbiBiZSByZW1v dmVkLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsm bmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGFsc28gcmVxdWVzdHMgdGhhdCB0aGUgSUFOQSBjcmVh dGUgYSBuZXcgcmVnaXN0cnk8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBmb3IgUEFTU3BvclQgJnF1b3Q7cnBoJnF1b3Q7IHR5cGVzLiZuYnNwOyBSZWdpc3RyYXRp b24gb2YgbmV3IFBBU1Nwb3JUICZxdW90O3JwaCZxdW90OyB0eXBlczwvdHQ+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyBzaGFsbCBiZSB1bmRlciB0aGUgc3BlY2lmaWNhdGlvbiByZXF1aXJlZCBwb2xp Y3kuJm5ic3A7IFRoaXMgcmVnaXN0cnkgaXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgdG8g YmUgaW5pdGlhbGx5IHBvcHVsYXRlZCB3aXRoIGEgc2luZ2xlIHZhbHVlIGZvciAmcXVvdDthdXRo JnF1b3Q7IHdoaWNoIGlzPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHNwZWNpZmllZCBpbiBb UkZDVGhpc10uPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgbmVlZHMgdG8gYmUgdmVyeSBjbGVhciBhYm91 dCB0aGUgZmllbGRzIHRvIGJlIGluY2x1ZGVkIGluIHRoaXMgbmV3IHJlZ2lzdHJ5IChlLmcuLCAm cXVvdDtSZWdpc3RyeSBlbnRyaWVzIG11c3QgY29udGFpbiB0d28gZmllbGRzOiB0aGUgbmFtZSBv ZiB0aGUgJ3JwaCcgdHlwZSBhbmQgdGhlIHNwZWNpZmljYXRpb24gaW4gd2hpY2ggdGhlIHR5cGUg aXMgZGVzY3JpYmVkJnF1b3Q7KS48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Ny4mbmJz cDsgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJz cDsgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGRpc2N1c3NlZCBpbiBbSS1ELmlldGYtc3Rp ci1yZmM0NDc0YmlzXTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpbiBTZWN0aW9uIDEwIGFy ZSBhcHBsaWNhYmxlIGhlcmUuPC90dD48YnI+DQo8YnI+DQo8dHQ+Ny4xLiZuYnNwOyBBdm9pZGFu Y2Ugb2YgcmVwbGF5IGFuZCBjdXQgYW5kIHBhc3RlIGF0dGFja3M8L3R0Pjxicj4NCjxicj4NCjx0 dD4mbmJzcDsmbmJzcDsgVGhlIFBBU1Nwb3JUIGV4dGVuc2lvbiB3aXRoIGEgJnF1b3Q7cHB0JnF1 b3Q7IHZhbHVlIG9mICZxdW90O3JwaCZxdW90OyBNVVNUIG9ubHkgYmUgc2VudDwvdHQ+PGJyPg0K PHR0PiZuYnNwOyZuYnNwOyB3aXRoIFNJUCBJTlZJVEUgd2hlbiAnUmVzb3VyY2UtUHJpb3JpdHkn IGhlYWRlciBpcyB1c2VkIHRvIGNvbnZleSB0aGU8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uaGVh ZGVyIGZpZWxkLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOyZuYnNwOyBwcmlvcml0eSBvZiB0aGUgY29tbXVuaWNhdGlvbiBhcyBkZWZp bmVkIGluIFtSRkM0NDEyXS4mbmJzcDsgVG8gYXZvaWQgdGhlPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgcmVwbGF5LCBhbmQgY3V0IGFuZCBwYXN0ZSBhdHRhY2tz LCB0aGUgcHJvY2VkdXJlcyBkZXNjcmliZWQgaW48L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsg U2VjdGlvbiAxMC4xIG9mIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNdIE1VU1QgYmUgZm9sbG93 ZWQuPC90dD48YnI+DQo8YnI+DQo8dHQ+Ny4yLiZuYnNwOyBTb2x1dGlvbiBDb25zaWRlcmF0aW9u czwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGUgdXNlIG9mIGV4dGVuc2lvbiB0 byBQQVNTcG9yVCB0b2tlbnMgd2l0aCAmcXVvdDtwcHQmcXVvdDsgdmFsdWUgJnF1b3Q7cnBoJnF1 b3Q7IGJhc2VkPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IG9uIHRoZSB2YWxpZGF0aW9uIG9m IHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBhbmQgdGhlIGFzc29jaWF0ZWQ8L3R0Pjxicj4NCjx0dD4m bmJzcDsmbmJzcDsgY2VydGlmaWNhdGUgcmVxdWlyZXMgY29uc2lkZXJhdGlvbiBvZiB0aGUgYXV0 aGVudGljYXRpb24gYW5kPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGF1dGhvcml0eSBvciBy ZXB1dGF0aW9uIG9mIHRoZSBzaWduZXIgdG8gYXR0ZXN0IHRvIHRoZSBpZGVudGl0eSBiZWluZzwv dHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBhc3NlcnRlZC4mbmJzcDsgVGhlIGZvbGxvd2luZyBj b25zaWRlcmF0aW9ucyBzaG91bGQgYmUgcmVjb2duaXplZCB3aGVuPC90dD48YnI+DQo8dHQ+Jm5i c3A7Jm5ic3A7IHVzaW5nIFBBU1Nwb3JUIGV4dGVuc2lvbiB3aXRoICZxdW90O3BwdCZxdW90OyB2 YWx1ZSBvZiAmcXVvdDtycGgmcXVvdDs6PC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IG8mbmJzcDsgQW4gYXV0aG9yaXR5IChzaWduZXIpIGlzIG9ubHkgYWxsb3dlZCB0byBzaWduIHRo ZSBjb250ZW50IG9mIGEgU0lQPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZvciB3aGljaCBpdCBoYXMgdGhlIHJp Z2h0IGF1dGhvcml0eS48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uaGVhZGVyIGZpZWxkLi4uJnF1 b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgYXV0aG9yaXR5IHRoYXQgc2lnbnMgdGhlIHRva2Vu IE1VU1QgaGF2ZSBhIHNlY3VyZSBtZXRob2QgZm9yPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aGVudGljYXRpb24gb2YgdGhl IGVuZCB1c2VyIG9yIHRoZSBkZXZpY2UuPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IG8mbmJzcDsgVGhlIHZlcmlmaWNhdGlvbiBvZiB0aGUgc2lnbmF0dXJlIE1VU1QgaW5jbHVkZSBt ZWFucyBvZiB2ZXJpZnlpbmc8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdGhhdCB0aGUgc2lnbmVyIGlzIGF1dGhvcml0YXRpdmUgZm9yIHRoZSBzaWduZWQgY29u dGVudCBvZiB0aGUgU0lQPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkl0J3Mgbm90IGNsZWFyIHdoYXQgYXV0aG9y aXR5IGlzIGJlaW5nIGNsYWltZWQgaGVyZS4gSXMgdGhpcyBzdXBwb3NlZCB0byBtZWFuIHNvbWV0 aGluZyBsaWtlICZxdW90Oy4uLnZlcmlmeWluZyB0aGF0IHRoZSBzaWduZXIgaXMgYXV0aG9yaXRh dGl2ZSBmb3IgdGhlIG9yaWdpbmF0aW5nIHRuIGluIHRoZSBQQVNTcG9yVC4uLiZxdW90Oz8gT3Ig JnF1b3Q7Li4uYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIHJlc291cmNlIHByaW9yaXR5IG5hbWVzcGFj ZSBpbiB0aGUgUEFTU3BvclQ/JnF1b3Q7DQogV2hhdGV2ZXIgdGhlIHNlcnZlciBpcyBwdXJwb3J0 ZWRseSBhdXRob3JpdGF0aXZlIGZvciBuZWVkcyB0byBiZSBjbGVhcmx5IHNwZWxsZWQgb3V0Ljxv OnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIuPC9zcGFuPjwvdHQ+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPiZxdW90Oy4uLmhlYWRlciBmaWVsZC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4vYQ0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnN0aXIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnN0 aXJAaWV0Zi5vcmciPnN0aXJAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGlyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B6C153849ESESSMB109erics_-- From nobody Sun Feb 4 09:14:00 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE8C127369 for ; Sun, 4 Feb 2018 09:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 QT9bFj8d4eMS for ; Sun, 4 Feb 2018 09:13:54 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE266126C25 for ; Sun, 4 Feb 2018 09:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517764430; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9GUIzBU9uTYBE/QgNBtbsfHW/A9O8h2wgvJ9QgPYZTM=; b=EOEC254mXgIePMx6PNaiM7RFKLePThmH+AV+S3FNNpo4dKpJWYY4SgcGw+peSy8X 0LVdooxbOvFsFNWE6TcAmGnhf6mfqKQ7yHHzJZKFv20YyUhGsTGzU25kSlDOBs0l 1Sassw7vCWDcTJOZ4uIbT1RsKJmAQTZwKr1VRr8wUJw=; X-AuditID: c1b4fb30-3b1ff70000004778-a4-5a773f4ed2fc Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F8.7B.18296.E4F377A5; Sun, 4 Feb 2018 18:13:50 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Sun, 4 Feb 2018 18:13:49 +0100 From: Christer Holmberg To: Christer Holmberg , Subir Das CC: "stir@ietf.org" , Adam Roach , "STIR Chairs" , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AdOTv2oSY/dEf4YfRra4GseuGeXVLAH6TDcAAIWJiHAAByyZYA== Date: Sun, 4 Feb 2018 17:13:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C153D09@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C153D09ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7t66ffXmUwZbfShZ7/i5it1h9/ByT xbMd61ktlq/dxmQx5cAydgdWj52z7rJ7LFnyk8lj1s4nLB5fLn9mC2CJ4rJJSc3JLEst0rdL 4MrY9a6JreBYL0fFj5k9bA2MTz6xdzFyckgImEh0L3sPZHNxCAkcZpSY1HKNGcJZzCgx78xz IIeDg03AQqL7nzZIg4hAlMSBtQvZQGqYBfYzSmxcOJkNJCEskC3xbMtvFoiiHImTv/4yQthO Ek92LQTbxiKgIjHt2Eywel4BX4nZfQ9ZIJbdYJS4f3MrM0iCU8BPovndP7AGRgExie+n1jCB 2MwC4hK3nsxngjhbQGLJnvPMELaoxMvH/1ghbCWJRbc/Q9XnS9x9vJgdYpmgxMmZT1gmMIrM QjJqFpKyWUjKZgH9zCygKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYn5aYbGeml FmUmFxfn5+nlpZZsYgTG48Etvw12ML587niIUYCDUYmH95Z1eZQQa2JZcWXuIUYJDmYlEd4Z k8qihHhTEiurUovy44tKc1KLDzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTBOvfsg 7K1wu4n4EueaK0LNV3ZK/lJ89/NVuvG7tlfC8xruJG29fG6BHlfIlpD6ENEozi7my9zNO+ob Qk4UXN7qEP9k4RoD+fX392oLNhybLhyY6L+h0ik5uCt19lKdzKff/zvEXjqp8vZS4N75ObxR ZqrM/7e5ml/P2b3Hdbfsi7re9q+HJgUqsRRnJBpqMRcVJwIAsNlfqcMCAAA= Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 17:13:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C153D09ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCmYW5kLCBpZiBSUEggaXMgb25seSBzdXBwb3NlZCB0byBiZSB1c2VkIGJ5IHRoZSBvcmlnaW5h dGluZyBuZXR3b3JrLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gc2F5IHRoYXQgbW9yZSBl eHBsaWNpdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogc3RpciBbbWFpbHRvOnN0 aXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50 OiAwNCBGZWJydWFyeSAyMDE4IDE4OjM0DQpUbzogU3ViaXIgRGFzIDxzdWJpcmRhczIxQGdtYWls LmNvbT4NCkNjOiBzdGlyQGlldGYub3JnOyBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPjsg U1RJUiBDaGFpcnMgPHN0aXItY2hhaXJzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1zdGlyLXJwaC5h bGxAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3Rpcl0gQUQgUmV2aWV3OiBkcmFmdC1p ZXRmLXN0aXItcnBoLTAyIC0gYXV0aG9yaXR5IHRvIGFzc2VydCB0aGUgY2FsbGVycyBpZGVudGl0 eSBhc3N1bWVkPw0KDQpIaSwNCg0KVGhlIHRleHQgc2F5czoNCg0KICAg4oCcVGhlIGNyZWRlbnRp YWxzIChlLmcuLCBhdXRob3JpdHkgcmVzcG9uc2libGUgZm9yIGF1dGhvcml6aW5nIFJlc291cmNl LQ0KICAgUHJpb3JpdHkpIHVzZWQgdG8gY3JlYXRlIHRoZSBzaWduYXR1cmUgbXVzdCBoYXZlIGF1 dGhvcml0eSBvdmVyIHRoZQ0KICAgbmFtZXNwYWNlIG9mIHRoZSAicnBoIiBjbGFpbSBhbmQgdGhl cmUgaXMgb25seSBvbmUgYXV0aG9yaXR5IHBlcg0KICAgY2xhaW0u4oCdDQoNCklmIHRoZSBjcmVk ZW50aWFscyBkb27igJl0IG5lZWQgdG8gaGF2ZSBhdXRob3JpdHkgb2YgdGhlIG90aGVyIGNsYWlt cyAoZS5nLiwg4oCcb3JpZ+KAnSkgaW4gdGhlIFJQSCBQQVNTUG9yVCBJIHRoaW5rIHlvdSBzaG91 bGQgZXhwbGljaXRseSBzYXkgc28uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTog U3ViaXIgRGFzIFttYWlsdG86c3ViaXJkYXMyMUBnbWFpbC5jb21dDQpTZW50OiAwMiBGZWJydWFy eSAyMDE4IDAxOjA0DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkNjOiBB ZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj47IFNU SVIgQ2hhaXJzIDxzdGlyLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86c3Rpci1jaGFpcnNAaWV0Zi5v cmc+Pjsgc3RpckBpZXRmLm9yZzxtYWlsdG86c3RpckBpZXRmLm9yZz47IGRyYWZ0LWlldGYtc3Rp ci1ycGguYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXN0aXItcnBoLmFsbEB0 b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3Rpcl0gQUQgUmV2aWV3OiBkcmFmdC1pZXRm LXN0aXItcnBoLTAyIC0gYXV0aG9yaXR5IHRvIGFzc2VydCB0aGUgY2FsbGVycyBpZGVudGl0eSBh c3N1bWVkPw0KDQpIZWxsbyBDaHJpc3RlciwNClRoZSBzaWduaW5nIGVudGl0eSBkb2VzIG5vdCBo YXZlIGFsd2F5cyB0aGUgYXV0aG9yaXR5IHRvIGFzc2VydCB0aGUgY2FsbGVyIGlkZW50aXR5IGlu IHJwaC4gV2UgYXJlIHN1Ym1pdHRpbmcgdmVyLTAzIGRyYWZ0ICBhbmQgaXQgaXMgY2xhcmlmaWVk ICBhcyBmb2xsb3dzOg0KIlRoZSBjcmVkZW50aWFscyAoZS5nLiwgYXV0aG9yaXR5IHJlc3BvbnNp YmxlIGZvciBhdXRob3JpemluZyBSZXNvdXJjZS1Qcmlvcml0eSkgdXNlZCB0byBjcmVhdGUgdGhl IHNpZ25hdHVyZSBtdXN0IGhhdmUgYXV0aG9yaXR5IG92ZXIgdGhlIG5hbWVzcGFjZSBvZiB0aGXi gJxycGgiIGNsYWltLi4iDQoNCi1TdWJpcg0KDQpPbiBNb24sIEphbiAyMiwgMjAxOCBhdCAzOjI3 IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpBbm90 aGVyIHF1ZXN0aW9uIGZvciBjbGFyaWZpY2F0aW9uLg0KDQpTZWN0aW9uIDMgY29udGFpbnMgdGhl IGZvbGxvd2luZyBleGFtcGxlOg0KDQogICAgeyAib3JpZyI6eyJ0biI6IjEyMTU1NTUxMjEyPHRl bDooMjE1KSUyMDU1NS0xMjEyPiJ9DQogICAgICJkZXN0Ijp7WyJ0biI6IjEyMTI1NTUxMjEzPHRl bDooMjEyKSUyMDU1NS0xMjEzPiJdfSwNCiAgICAgImlhdCI6MTQ0MzIwODM0NSwNCiAgICAgInJw aCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLjAiXX0NCg0K4oCmYW5kIHRoZSBmb2xsb3dpbmcgdGV4 dDoNCg0KICAg4oCcVGhlIGNyZWRlbnRpYWxzIChlLmcuLCBhdXRob3JpdHkgcmVzcG9uc2libGUg Zm9yIGF1dGhvcml6aW5nIFJlc291cmNlLQ0KICAgUHJpb3JpdHkpIHVzZWQgdG8gY3JlYXRlIHRo ZSBzaWduYXR1cmUgbXVzdCBoYXZlIGF1dGhvcml0eSBvdmVyIHRoZQ0KICAgInJwaCIgY2xhaW3i gKbigJ0NCg0KU2luY2UgdGhlIGNsYWltIGFsc28gY29udGFpbnMg4oCcb3JpZ+KAnSwgaXMgdGhl IGFzc3VtcHRpb24gdGhhdCB0aGUgc2lnbmluZyBlbnRpdHkgYWx3YXlzIGFsc28gaGFzIGF1dGhv cml0eSB0byBhc3NlcnQgdGhlIGNhbGxlcnMgaWRlbnRpdHk/IEkgdGhpbmsgaXQgd291bGQgYmUg Z29vZCB0byBleHBsaWNpdGx5IG1lbnRpb24gaXQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQoNCg0KDQpGcm9tOiBzdGlyIFttYWlsdG86c3Rpci1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpzdGlyLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQWRhbSBSb2FjaA0KU2VudDog MjAgSmFudWFyeSAyMDE4IDAwOjE1DQpUbzogU1RJUiBDaGFpcnMgPHN0aXItY2hhaXJzQGlldGYu b3JnPG1haWx0bzpzdGlyLWNoYWlyc0BpZXRmLm9yZz4+OyBzdGlyQGlldGYub3JnPG1haWx0bzpz dGlyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1zdGlyLXJwaC5hbGxAdG9vbHMuaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtc3Rpci1ycGguYWxsQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogW3N0 aXJdIEFEIFJldmlldzogZHJhZnQtaWV0Zi1zdGlyLXJwaC0wMg0KDQoNCkknbSBkb2luZyBteSBB RCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zdGlyLXJwaC0wMi4gVGhhbmtzIHRvIGV2ZXJ5b25lIHdo byBoYXMgd29ya2VkIG9uIHRoaXMgZG9jdW1lbnQsIGFuZCB0aGUgYXV0aG9ycyBhbmQgY2hhaXJz IGluIHBhcnRpY3VsYXIuDQoNClRoZSB0ZWNobmljYWwgY29udGVudCBoZXJlIGxvb2tzIGdlbmVy YWxseSBnb29kIHRvIG1lLiBJJ2QgbGlrZSB0byBzZWUgYSBmZXcgaXNzdWVzIGFkZHJlc3NlZCBi ZWZvcmUgSUVURiBMQy4gSW4gc2hvcnQgc3VtYXJ5Og0KDQogICogICBUaGUgdmFsaWRhdGlvbiBz ZWN0aW9uIG5lZWRzIHRvIGFkZCBhIGRpc2N1c3Npb24gb2YgaG93IHRvIHRyZWF0IGNhbGxzIHdo ZW4gdGhlIHByaW9yaXR5IHZhbHVlcyBpbiAicnBoIiBwYXNzcG9ydHMgYW5kIFNJUCAiUmVzb3Vy Y2UtUHJpb3JpdHkiIGhlYWRlciBmaWVsZHMgYXJlbid0IDEwMCUgaWRlbnRpY2FsLg0KICAqICAg VGhlIGV4YW1wbGVzIG5lZWQgc29tZSBhZGp1c3RtZW50Lg0KICAqICAgVGhlcmUgaXMgYSBtaW5v ciBwb2ludCBvZiBhbWJpZ3VpdHkgaW4gdGhlIFNlY3VyaXR5IFNlY3Rpb24sIGJ1dCB0aGlzIHNo b3VsZCBiZSBlYXN5IHRvIGZpeCwgYXMgbG9uZyBhcyB0aGUgV0cga25vd3Mgd2hhdCB3YXMgaW50 ZW5kZWQuDQogICogICBUaGUgSUFOQSBhY3Rpb25zIG5lZWQgYSBsaXR0bGUgYml0IG9mIGFkanVz dG1lbnQuDQogICogICBUaGVyZSBhcmUgYSBudW1iZXIgb2YgbWlub3IgZWRpdG9yaWFsIGlzc3Vl cyB0byBiZSBjbGVhbmVkIHVwLg0KDQpEZXRhaWxlZCBjb21tZW50cyBvbiB0aGVzZSBwb2ludHMg YXJlIGlubGluZSBpbiB0aGUgZG9jdW1lbnQgYmVsb3cuIEkndmUgcmVtb3ZlZCBzb21lIHBvcnRp b25zIG9mIHRoZSBkb2N1bWVudCBvbiB3aGljaCBJIGhhdmUgbm8gY29tbWVudHMuDQoNCg0KDQpB YnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGV4dGVuZHMgdGhlIFNUSVIgUEFTU3BvclQgc3Bl Y2lmaWNhdGlvbiB0byBhbGxvdyB0aGUNCg0KDQoNCiIuLi50aGUgU2VjdXJlIFRlbGVwaG9uZSBJ ZGVudGl0eSBSZXZpc2l0ZWQgKFNUSVIpIFBlcnNvbmFsIEFzc2VydGlvbiBUb2tlbiAoUEFTU3Bv clQpIHNwZWNpZmljYXRpb24gZGVmaW5lZCBpbiBSRkMgODEyMi4uLiINCg0KKFNlZSA8aHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvbWF0ZXJpYWxzL2FiYnJldi5leHBhbnNpb24udHh0PjxodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJicmV2LmV4cGFuc2lvbi50eHQ+IGZv ciBndWlkYW5jZSBvbiBhYmJyZXZpYXRpb25zKQ0KDQoNCiAgIGluY2x1c2lvbiBvZiBjcnlwdG9n cmFwaGljYWxseS1zaWduZWQgYXNzZXJ0aW9ucyBvZiBhdXRob3JpemF0aW9uIGZvcg0KICAgdGhl IHZhbHVlcyBwb3B1bGF0ZWQgaW4gdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBm aWVsZCwNCiAgIHdoaWNoIGlzIHVzZWQgZm9yIGNvbW11bmljYXRpb25zIHJlc291cmNlIHByaW9y aXRpemF0aW9uLg0KDQouLi4NCg0KMS4gIEludHJvZHVjdGlvbg0KDQogICBQQVNTcG9yVCBbSS1E LmlldGYtc3Rpci1wYXNzcG9ydF0gaXMgYSB0b2tlbiBmb3JtYXQgYmFzZWQgb24gSldUDQogICBb UkZDNzUxOV0gZm9yIGNvbnZleWluZyBjcnlwdG9ncmFwaGljYWxseS1zaWduZWQgaW5mb3JtYXRp b24gYWJvdXQNCiAgIHRoZSBpZGVudGl0aWVzIGludm9sdmVkIGluIHBlcnNvbmFsIGNvbW11bmlj YXRpb25zOyBpdCBpcyB1c2VkIHdpdGgNCiAgIFNUSVIgW0ktRC5pZXRmLXN0aXItcmZjNDQ3NGJp c10gdG8gY29udmV5IGEgc2lnbmVkIGFzc2VydGlvbiBvZiB0aGUNCiAgIGlkZW50aXR5IG9mIHRo ZSBwYXJ0aWNpcGFudHMgaW4gcmVhbC10aW1lIGNvbW11bmljYXRpb25zIGVzdGFibGlzaGVkDQog ICB2aWEgYSBwcm90b2NvbCBsaWtlIFNJUC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIFBB U1Nwb3JUIHRvDQoNCg0KDQoiLi4ubGlrZSBTSVAgW1JGQzMyNjFdLi4uIg0KDQooV2Ugd2FudCB0 byBjaXRlIFNJUCB0aGUgZmlyc3QgdGltZSBpdCBpcyBtZW50aW9uZWQpDQoNCg0KICAgYWxsb3cg Y3J5cHRvZ3JhcGhpYy1zaWduaW5nIG9mIHRoZSBTSVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFk ZXINCiAgIGZpZWxkIGRlZmluZWQgaW4gW1JGQzQ0MTJdLg0KDQogICBbUkZDNDQxMl0gZGVmaW5l cyB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGZvcg0KICAgY29tbXVu aWNhdGlvbnMgUmVzb3VyY2UgUHJpb3JpdHkuICBBcyBzcGVjaWZpZWQgaW4gW1JGQzQ0MTJdLCB0 aGUNCiAgICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIG1heSBiZSB1c2VkIGJ5IFNJ UCB1c2VyIGFnZW50cw0KICAgW1JGQzMyNjFdLCBpbmNsdWRpbmcsIFB1YmxpYyBTd2l0Y2hlZCBU ZWxlcGhvbmUgTmV0d29yayAoUFNUTikNCg0KDQoNCiIuLi5pbmNsdWRpbmcgUHVibGljIFN3aXRj aGVkLi4uIg0KDQoocmVtb3ZlIHRoZSBjb21tYSkNCg0KDQogICBnYXRld2F5cyBhbmQgdGVybWlu YWxzLCBhbmQgU0lQIHByb3h5IHNlcnZlcnMgdG8gaW5mbHVlbmNlDQoNCg0KDQoiLi4uYW5kIGJ5 IFNJUCBwcm94eSBzZXJ2ZXJzLCB0byBpbmZsdWVuY2UuLi4iDQoNCihhZGQgImJ5IiBhbmQgY29t bWEpDQoNCg0KICAgcHJpb3JpdGl6YXRpb24gYWZmb3JkZWQgdG8gY29tbXVuaWNhdGlvbiBzZXNz aW9ucyxpbmNsdWRpbmcgUFNUTg0KDQoNCiIuLi5zZXNzaW9ucywgaW5jbHVkaW5nLi4uIg0KDQoo c3BhY2UgYWZ0ZXIgY29tbWEpDQoNCg0KICAgY2FsbHMuICBIb3dldmVyLCB0aGUgU0lQICdSZXNv dXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGNvdWxkIGJlDQogICBzcG9vZmVkIGFuZCBhYnVz ZWQgYnkgdW5hdXRob3JpemVkIGVudGl0aWVzLg0KDQogICBUaGUgU1RJUiBhcmNoaXRlY3R1cmUg W1JGQzczNDBdYXNzdW1lcyB0aGF0IGFuIGF1dGhvcml0eSBvbiB0aGUNCg0KDQoNCiIuLi5TVElS IGFyY2hpdGVjdHVyZSBbUkZDNzM0MF0gYXNzdW1lcy4uLiINCg0KKHNwYWNlIGJlZm9yZSAiYXNz dW1lcyIpDQoNCg0KICAgb3JpZ2luYXRpbmcgc2lkZSBvZiBhIGNhbGwgcHJvdmlkZXMgYSBjcnlw dG9ncmFwaGljIGFzc3VyYW5jZSBvZiB0aGUNCiAgIHZhbGlkaXR5IG9mIHRoZSBjYWxsaW5nIHBh cnR5IG51bWJlciBpbiBvcmRlciB0byBwcmV2ZW50DQogICBpbXBlcnNvbmF0aW9uIGF0dGFja3Mu ICBUaGUgU1RJUiBhcmNoaXRlY3R1cmUgYWxsb3dzIGV4dGVuc2lvbiB0aGF0DQoNCg0KDQoiLi4u YWxsb3dzIGV4dGVuc2lvbnMuLi4iDQoNCg0KICAgY2FuIGJlIHV0aWxpemVkIGJ5IGF1dGhvcml0 aWVzIHN1cHBvcnRpbmcgcmVhbC10aW1lIGNvbW11bmljYXRpb24NCiAgIHNlcnZpY2VzIHVzaW5n IHRoZSAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCB0bw0KICAgY3J5cHRvZ3JhcGhp Y2FsbHkgc2lnbiB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGFuZA0K ICAgY29udmV5IGFzc2VydGlvbiBvZiB0aGUgYXV0aG9yaXphdGlvbiBmb3IgJ1Jlc291cmNlLVBy aW9yaXR5Jy4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIGF1dGhvcml0eSBvbiB0aGUgb3JpZ2luYXRp bmcgc2lkZSB2ZXJpZnlpbmcgdGhlDQogICBhdXRob3JpemF0aW9uIG9mIGEgcGFydGljdWxhciBj b21tdW5pY2F0aW9uIGZvciBSZXNvdXJjZS1Qcmlvcml0eSBjYW4NCg0KDQoNClNpbmdsZSBxdW90 ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScuDQoNCg0KICAgdXNlIGEgUEFTU1BvclQgY2xh aW0gdG8gY3J5cHRvZ3JhcGhpY2FsbHktc2lnbiB0aGUgU0lQICdSZXNvdXJjZS0NCg0KDQoNCiIu Li5jcnlwdG9ncmFwaGljYWxseSBzaWduLi4uIg0KDQoNCiAgIFByaW9yaXR5JyBoZWFkZXIgZmll bGQgYW5kIGNvbnZleSBhbiBhc3NlcnRpb24gb2YgdGhlIGF1dGhvcml6YXRpb24NCiAgIGZvciAn UmVzb3VyY2UtUHJpb3JpdHknLiAgVGhpcyB3aWxsIGFsbG93IGEgcmVjZWl2aW5nIGVudGl0eQ0K ICAgKGluY2x1ZGluZyBlbnRpdGllcyBsb2NhdGVkIGluIGRpZmZlcmVudCBuZXR3b3JrIGRvbWFp bnMvYm91bmRhcmllcykNCiAgIHRvIHZlcmlmeSB0aGUgdmFsaWRpdHkgb2YgYXNzZXJ0aW9ucyBh dXRob3JpemluZyBSZXNvdXJjZS1Qcmlvcml0eS4NCg0KDQoNClNpbmdsZSBxdW90ZXMgYXJvdW5k ICdSZXNvdXJjZS1Qcmlvcml0eScuDQoNCg0KICAgQ3J5cHRvZ3JhcGhpY2FsbHktc2lnbmVkIFNJ UCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlcnMgd2lsbCBhbGxvdyBhDQoNCg0KDQoiLi4uY3J5 cHRvZ3JhcGhpY2FsbHkgc2lnbmVkIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVs ZHMuLi4iDQoNCihyZW1vdmUgaHlwaGVuLCBhbmQgcmVwbGFjZSAiaGVhZGVycyIgd2l0aCAiaGVh ZGVyIGZpZWxkcyIpDQoNCg0KICAgcmVjZWl2aW5nIGVudGl0eSB0byB2ZXJpZnkgYW5kIGFjdCBv biB0aGUgaW5mb3JtYXRpb24gd2l0aCBjb25maWRlbmNlDQogICB0aGF0IHRoZSBpbmZvcm1hdGlv biBoYXZlIG5vdCBiZWVuIHNwb29mZWQgb3IgY29tcHJvbWlzZWQuDQoNCg0KDQoiLi4uaGFzIG5v dCBiZWVuIHNwb29mZWQgb3IgY29tcHJvbWlzZWQuIg0KDQoNCg0KICAgVGhpcyBzcGVjaWZpY2F0 aW9uIGRvY3VtZW50cyBhbiBvcHRpb25hbCBleHRlbnNpb24gdG8gUEFTU3BvclQgYW5kDQogICB0 aGUgYXNzb2NpYXRlZCBTVElSIG1lY2hhbmlzbXMgdG8gcHJvdmlkZSBhIGZ1bmN0aW9uIHRvIHNp Z24gdGhlIFNJUA0KICAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQuICBUaGlzIFBB U1Nwb3JUIG9iamVjdCBpcyB1c2VkIHRvDQogICBwcm92aWRlIGF0dGVzdGF0aW9uIG9mIGEgY2Fs bGluZyB1c2VyIGF1dGhvcml6YXRpb24gZm9yIHByaW9yaXR5DQogICBjb21tdW5pY2F0aW9ucy4g IFRoaXMgaXMgbmVjZXNzYXJ5IGluIGFkZGl0aW9uIHRvIHRoZSBQQVNTcG9yVCBvYmplY3QNCiAg IHRoYXQgaXMgdXNlZCBmb3IgY2FsbGluZyB1c2VyIHRlbGVwaG9uZSBudW1iZXIgYXR0ZXN0YXRp b24uICBIb3cgdGhlDQogICBvcHRpb25hbCBleHRlbnNpb24gdG8gUEFTU3BvclQgaXMgdXNlZCBm b3IgcmVhbC10aW1lIGNvbW11bmljYXRpb25zDQogICBzdXBwb3J0ZWQgdXNpbmcgU0lQICdSZXNv dXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGlzIGRlZmluZWQgaW4NCiAgIG90aGVyIGRvY3Vt ZW50cyBhbmQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KDQoNCkkg YXNzdW1lIHRoZXNlIG90aGVyIGRvY3VtZW50cyBhcmUgdW5kZXIgZGV2ZWxvcG1lbnQ/IElmIHNv LCB0aGV5IHNob3VsZCBiZSBjaXRlZCBoZXJlLg0KDQoNCg0KMi4gIFRlcm1pbm9sb2d5DQoNCiAg IFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAi U0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJN QVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5IFtSRkMyMTE5XS4NCg0KDQoNClRoaXMgZG9j dW1lbnQgaGFzIHNldmVyYWwgbm9uLW5vcm1hdGl2ZSB1c2VzIG9mICJtdXN0IiwgInNob3VsZCwi IGFuZCAibWF5LCIgYW5kIHNvIGl0IG5lZWRzIHRvIHVzZSB0aGUgUkZDODE3NCBib2lsZXJwbGF0 ZSBpbnN0ZWFkIG9mIHRoZSBSRkMyMTE5IGJvaWxlcnBsYXRlLg0KDQoNCg0KMy4gIFBBU1Nwb3JU ICdycGgnIENsYWltDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgbmV3IEpTT04g V2ViIFRva2VuIGNsYWltIGZvciAicnBoIiwNCiAgIHdoaWNoIHByb3ZpZGVzIGFuIGFzc2VydGlv biBmb3IgaW5mb3JtYXRpb24gaW4gU0lQICdSZXNvdXJjZS0NCiAgIFByaW9yaXR5J2hlYWRlci4N Cg0KDQoNCiIuLi5Qcmlvcml0eScgaGVhZGVyIGZpZWxkLiINCg0KKHNwYWNlIGFmdGVyIGNsb3Np bmcgcXVvdGF0aW9uIG1hcmssICJoZWFkZXIgZmllbGQiIGluc3RlYWQgb2YgImhlYWRlciIpDQoN Cg0KDQogICBUaGUgY3JlYXRvciBvZiBhIFBBU1Nwb3JUIG9iamVjdCBhZGRzIGEgInBwdCIgdmFs dWUgb2YgInJwaCIgdG8gdGhlDQogICBoZWFkZXIgb2YgYSBQQVNTcG9yVCBvYmplY3QsIGluIHdo aWNoIGNhc2UgdGhlIFBBU1Nwb3JUIGNsYWltcyBNVVNUDQogICBjb250YWluIGEgInJwaCIgY2xh aW0sIGFuZCBhbnkgZW50aXRpZXMgdmVyaWZ5aW5nIHRoZSBQQVNTcG9yVCBvYmplY3QNCiAgIHdp bGwgYmUgcmVxdWlyZWQgdG8gdW5kZXJzdGFuZCB0aGUgInBwdCIgZXh0ZW5zaW9uIGluIG9yZGVy IHRvDQogICBwcm9jZXNzIHRoZSBQQVNTcG9yVCBpbiBxdWVzdGlvbi4gIEEgUEFTU1BvclQgaGVh ZGVyIHdpdGggdGhlICJwcHQiDQogICBpbmNsdWRlZCB3aWxsIGxvb2sgYXMgZm9sbG93czoNCg0K ICAgeyAgInR5cCI6InBhc3Nwb3J0IiwNCiAgICAgInBwdCI6InJwaCIsDQogICAgICJhbGciOiJF UzI1NiIsDQogICAgICJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLm9yZy9jZXJ0LmNlciI8aHR0 cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXI+fQ0KDQoNCg0KSWRlYWxseSwgdGhpcyB3b3Vs ZCBiZSBlaXRoZXIgcHJldHR5LXByaW50ZWQgb3IgY2Fub25pY2FsaXplZC4gU2luY2UgaXQncyB0 b28gbG9uZyB0byBmaXQgb24gYSBsaW5lIGluIGNhbm9uaWNhbCBmb3JtLCBJIHByb3Bvc2U6DQoN CnsNCiAgInR5cCI6InBhc3Nwb3J0IiwNCiAgInBwdCI6InJwaCIsDQogICJhbGciOiJFUzI1NiIs DQogICJ4NXUiOiJodHRwczovL3d3dy5leGFtcGxlLm9yZy9jZXJ0LmNlciI8aHR0cHM6Ly93d3cu ZXhhbXBsZS5vcmcvY2VydC5jZXI+DQp9DQoNCg0KDQogICBUaGUgInJwaCIgY2xhaW0gd2lsbCBw cm92aWRlIGFuIGFzc2VydGlvbiBvZiBhdXRob3JpemF0aW9uLCJhdXRoIiwNCg0KDQoNCiIuLi5h dXRob3JpemF0aW9uLCAiYXV0aCIsIC4uLiINCg0KKHNwYWNlIGJldHdlZW4gY29tbWEgYW5kIG9w ZW5pbmcgcXVvdGF0aW9uIG1hcmspDQoNCg0KICAgZm9yIGluZm9ybWF0aW9uIGluIHRoZSBTSVAg IlJlc291cmNlLVByaW9yaXR5IiBoZWFkZXIgZmllbGQgKGkuZS4sDQogICBSZXNvdXJjZS1Qcmlv cml0eTogbmFtZXNwYWNlICIuIiByLXByaW9yaXR5KSBiYXNlZCBvbiBbUkZDNDQxMl0uDQoNCg0K DQpUaGUgdXNlIG9mIHRoZSBzdHJpbmcgJ25hbWVzcGFjZSAiLiIgci1wcmlvcml0eScgaGVyZSBh bmQgZWxzZXdoZXJlIGluIHRoZSBkb2N1bWVudCBoYXMgYSBkZXRyaW1lbnRhbCBpbXBhY3Qgb24g cmVhZGFiaWxpdHkuIEkgc3Ryb25nbHkgc3VnZ2VzdCByZXBsYWNpbmcgaXQgd2l0aCAici12YWx1 ZSIgKHRoZSBuYW1lIG9mIHRoaXMgcHJvZHVjdGlvbiBpbiBSRkM0NDEyKSBldmVyeXdoZXJlLg0K DQoNCiAgIFNwZWNpZmljYWxseSwgdGhlICJycGgiIGNsYWltIGluY2x1ZGVzIGFzc2VydGlvbiBv ZiB0aGUgcHJpb3JpdHktDQogICBsZXZlbCBvZiB0aGUgdXNlciB0byBiZSB1c2VkIGZvciBhIGdp dmVuIGNvbW11bmljYXRpb24gc2Vzc2lvbi4gIFRoZQ0KICAgdmFsdWUgb2YgdGhlICJycGgiIGNs YWltIGlzIGFuIGFycmF5IGNvbnRhaW5pbmcgb25lIG9yIG1vcmUgb2YgSlNPTg0KICAgb2JqZWN0 cyBmb3IgdGhlIGNvbnRlbnQgb2YgdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciB0 aGF0IGlzDQogICBiZWluZyBhc3NlcnRlZCBvZiB3aGljaCBvbmUgb2YgdGhlICJycGgiIG9iamVj dCwgaXMgbWFuZGF0b3J5Lg0KDQoNCg0KVGhpcyBsYXN0IHNlbnRlbmNlIGlzIHZlcnkgaGFyZCB0 byBwYXJzZTsgYW5kIChiYXNlZCBvbiB0aGUgZXhhbXBsZSkgdGhlIHZhbHVlIGlzIGludGVuZGVk IHRvIGJlIGEgSlNPTiBPYmplY3QgKGN1cmx5IGJyYWNlcykgcmF0aGVyIHRoYW4gYSBKU09OIEFy cmF5IChzcXVhcmUgYnJhY2VzKS4gSSBzdWdnZXN0OiAnVGhlIHZhbHVlIG9mIHRoZSAicnBoIiBj bGFpbSBpcyBhbiBPYmplY3Qgd2l0aCBvbmUgb3IgbW9yZSBrZXlzLiBFYWNoIGtleSBpcyBhc3Nv Y2lhdGVkIHdpdGggYSBKU09OIEFycmF5LiBUaGVzZSBhcnJheXMgY29udGFpbiBTdHJpbmdzIHRo YXQgY29ycmVzcG9uZCB0byB0aGUgci12YWx1ZXMgaW5kaWNhdGVkIGluIHRoZSBTSVAgIlJlc291 cmNlLVByaW9yaXR5IiBoZWFkZXIgZmllbGQuJyAobm90ZTogImhlYWRlciBmaWVsZCIsIG5vdCAi aGVhZGVyIikNCg0KDQoNCiAgIFRoZSBmb2xsb3dpbmcgaXMgYW4gZXhhbXBsZSAicnBoIiBjbGFp bSBmb3IgYSBTSVAgIlJlc291cmNlLVByaW9yaXR5Ig0KICAgaGVhZGVyIGZpZWxkIHdpdGggYSAi bmFtZXNwYWNlICIuIiByLXByaW9yaXR5IiB2YWx1ZSBvZiAiZXRzLjAiIGFuZA0KICAgd2l0aCBh ICJuYW1lc3BhY2UgIi4iIHItcHJpb3JpdHkiIHZhbHVlIG9mICJ3cHMuMCIuDQoNCiAgICB7ICJv cmlnIjp7InRuIjoiMTIxNTU1NTEyMTI8dGVsOigyMTUpJTIwNTU1LTEyMTI+In0NCiAgICAgImRl c3QiOntbInRuIjoiMTIxMjU1NTEyMTM8dGVsOigyMTIpJTIwNTU1LTEyMTM+Il19LA0KICAgICAi aWF0IjoxNDQzMjA4MzQ1LA0KICAgICAicnBoIjp7ImF1dGgiOlsiZXRzLjAiLCJ3cHMuMCJdfQ0K DQoNCg0KQXMgYWJvdmUsIEkgcmVjb21tZW5kIHByZXR0eS1wcmludGluZyB0aGlzLiBJdCdzIGFs c28gbWlzc2luZyBhIGNvbW1hIGFmdGVyIHRoZSAib3JpZyIgdmFsdWUsIGFuZCB0aGUgdG9wLWxl dmVsIHN0cnVjdHVyZSBpcyBtaXNzaW5nIGEgY2xvc2luZyBicmFjZS4gVGhlIHZhbHVlIGZvciAi aWF0IiBuZWVkcyB0byBiZSBlbmNsb3NlZCBpbiBxdW90ZXMuDQoNClRoZSBOQU5QQSBoYXMgYWxs b2NhdGVkIE5QQTU1NTAxeHggZm9yIGV4YW1wbGUgdXNlLCBub3QgTlBBNTU1eHh4eCwgbXVjaCBv ZiB3aGljaCByZW1haW5zIGFzc2lnbmFibGUgKGNmIDxodHRwczovL3d3dy5uYXRpb25hbG5hbnBh LmNvbS9wZGYvTlJVRi9BVElTLTAzMDAxMTUucGRmPjxodHRwczovL3d3dy5uYXRpb25hbG5hbnBh LmNvbS9wZGYvTlJVRi9BVElTLTAzMDAxMTUucGRmPikuDQoNClB1dHRpbmcgYWxsIHRoaXMgdG9n ZXRoZXIsIEkgYmVsaWV2ZSB3aGF0IHlvdSB3YW50IGlzOg0KDQp7DQogICJvcmlnIjp7InRuIjoi MTIxNTU1NTAxMTI8dGVsOigyMTUpJTIwNTU1LTAxMTI+In0sDQogICJkZXN0Ijp7WyJ0biI6IjEy MTI1NTUwMTEzPHRlbDooMjEyKSUyMDU1NS0wMTEzPiJdfSwNCiAgImlhdCI6IjE0NDMyMDgzNDUi LA0KICAicnBoIjp7ImF1dGgiOlsiZXRzLjAiLCJ3cHMuMCJdfQ0KfQ0KDQoNCg0KICAgQWZ0ZXIg dGhlIGhlYWRlciBhbmQgY2xhaW1zIFBBU1Nwb3JUIG9iamVjdHMgaGF2ZSBiZWVuIGNvbnN0cnVj dGVkLA0KICAgdGhlaXIgc2lnbmF0dXJlIGlzIGdlbmVyYXRlZCBub3JtYWxseSBwZXIgdGhlIGd1 aWRhbmNlIGluDQogICBbSS1ELmlldGYtc3Rpci1wYXNzcG9ydF0gdXNpbmcgdGhlIGZ1bGwgZm9y bSBvZiBQQVNTUG9yVC4gIFRoZQ0KICAgY3JlZGVudGlhbHMgKGUuZy4sIGF1dGhvcml0eSByZXNw b25zaWJsZSBmb3IgYXV0aG9yaXppbmcgUmVzb3VyY2UtDQogICBQcmlvcml0eSkgdXNlZCB0byBj cmVhdGUgdGhlIHNpZ25hdHVyZSBtdXN0IGhhdmUgYXV0aG9yaXR5IG92ZXIgdGhlDQogICAicnBo IiBjbGFpbSBhbmQgdGhlcmUgaXMgb25seSBvbmUgYXV0aG9yaXR5IHBlciBjbGFpbS4gIFRoZSBh dXRob3JpdHkNCiAgIE1VU1QgdXNlIGl0cyBjcmVkZW50aWFscyAoaS5lLiwgQ0VSVCkgYXNzb2Np YXRlZCB3aXRoIHRoZSBzcGVjaWZpYw0KICAgc2VydmljZSBzdXBwb3J0ZWQgYnkgdGhlIFNJUCBu YW1lc3BhY2UgaW4gdGhlIGNsYWltLg0KDQo0LiAgJ3JwaCcgaW4gU0lQDQoNCiAgIFRoaXMgc2Vj dGlvbiBzcGVjaWZpZXMgU0lQLXNwZWNpZmljIHVzYWdlIGZvciB0aGUgInJwaCIgY2xhaW0gaW4N CiAgIFBBU1Nwb3JULg0KDQo0LjEuICBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIEJlaGF2aW9yDQoN CiAgIFRoZSBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIHdpbGwgY3JlYXRlIHRoZSAicnBoIiBjbGFp bSB1c2luZyB0aGUNCiAgIHZhbHVlcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiAzIGJhc2VkIG9uIFtS RkM0NDEyXS4gIFRoZSBjb25zdHJ1Y3Rpb24NCiAgIG9mICJycGgiIGNsYWltIGZvbGxvd3MgdGhl IHN0ZXBzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQgb2YNCiAgIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0 NzRiaXNdLg0KDQogICBUaGUgcmVzdWx0aW5nIElkZW50aXR5IGhlYWRlciBmb3IgInJwaCIgbWln aHQgbG9vayBhcyBmb2xsb3dzOg0KDQoNCg0KIi4uLmhlYWRlciBmaWVsZC4uLiINCg0KDQoNCiAg ICJleUpoYkdjaU9pSkZVekkxTmlJc0luUjVjQ0k2SWtwWFZDSjkuZXlKcGMzTWlPaUpsZVVvd1pW aEJhVTlwU25kDQogICBaV0U1NlkwYzVlV1JEU1hORVVXOXBZMGhDTUVscWIybGpia0p2U1dsM1Rr TnBTbWhpUjJOcFQybEtSbFY2U1RGTw0KICAgYVVselJGRnZhV1ZFVmpGSmFuQnZaRWhTZDJONmIz Wk1NMlF6WkhrMWJHVkhSblJqUjNoc1RHMU9kbUpUT1dwYVcNCiAgIEVvd1RHMU9iR051TUU1RFp6 QkxJSHg4NG9DWkx1S0FtWHg4SUdWNVFXbGlNMHB3V25sSk5tVjVTakJpYVVrMlNXDQogICBwRmVV MVVWVEZPVkZWNFRXcEZlVWx1TUU1RGFVcHJXbGhPTUVscWNEZFhlVW93WW1sSk5rbHFSWGxOVkVr eFRsUg0KICAgVmVFMXFSWHBKYkRFNVRFRXdTMGx0Ykdoa1EwazJUVlJSTUUxNlNYZFBSRTB3VGxO M1RrTnBTbmxqUjJkcFQyNXoNCiAgIGFWbFlWakJoUTBrMlYzbEtiR1JJVFhWTlEwbHpTVzVrZDJO NU5IZEpiREU1UkZGdlBTSjkuczM3UzZWQzhITTZEDQogICBsNll6SmVRRHNyWmN3SjBsaXp4aFVy QTdmXzk4b1dCSHZvLWNsLW44TUlob0NyMTh2WVlGeTNibFh2czNmc2xNXw0KICAgb29zMlAyRHl3 IjsgaW5mbz0gImh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyIjxodHRwczovL3d3dy5l eGFtcGxlLm9yZy9jZXJ0LmNlcj47YWxnPUVTMjU2Ow0KICAgcHB0PSJycGgiDQoNCg0KDQpUaGlz IGV4YW1wbGUgaGFzIGEgbnVtYmVyIG9mIGlzc3VlczoNCg0KICAqICAgSW4gdGhlIElkZW50aXR5 IGhlYWRlciBmaWVsZCwgdGhlIHNpZ25lZC1pZGVudGl0eS1kaWdlc3Qgc2hvdWxkbid0IGJlIHF1 b3RlZC4NCiAgKiAgIEluIHRoZSBJZGVudGl0eSBoZWFkZXIgZmllbGQsIGluZm8gaXMgZW5jbG9z ZWQgaW4gPD4gcmF0aGVyIHRoYW4gIiIuDQogICogICBJbiB0aGUgSWRlbnRpdHkgaGVhZGVyIGZp ZWxkLCBwcHQgaXMgYSB0b2tlbiByYXRoZXIgdGhhbiBhIHF1b3RlZCBzdHJpbmcuDQogICogICBU aGUgc2lnbmVkLWlkZW50aXR5LWRpZ2VzdCBoZWFkZXIgbmVlZHMgdG8gaW5kaWNhdGUgYSAidHlw IiBvZiAicGFzc3BvcnQiIHJhdGhlciB0aGFuIEpXVCwgYW5kIGl0IG5lZWRzIHRvIGluY2x1ZGUg Ym90aCBhICJwcHQiIGFuZCAieDV1IiBmaWVsZC4NCiAgKiAgIFRoZSBzaWduZWQtaWRlbnRpdHkt ZGlnZXN0IGJvZHkgc2hvdWxkIGNvbnRhaW4gb25seSB0aGUgcGFzc3BvcnQgY2xhaW0gcmF0aGVy IHRoYW4gYSBKU09OIG9iamVjdCB0aGF0IGl0c2VsZiBjb250YWlucyBhIGJhc2U2NC1lbmNvZGVk IEpXUyBoZWFkZXIgY29uY2F0ZW5hdGVkIHdpdGggYSBjbGFpbS4NCiAgKiAgIEkgYmVsaWV2ZSB0 aGF0LCBldmVuIHdoZW4gdGhlIGJvZHkgaXMgaW5jbHVkZWQsIHZhbHVlcyBpbiB0aGUgaGVhZGVy IGFuZCBib2R5IG5lZWQgdG8gYmUgYmUgY2Fub25pY2FsaXplZCAoaS5lLiwgYWxsIG9uIG9uZSBs aW5lLCBubyBzcGFjZXMsIGluIGFscGhhYmV0aWNhbCBvcmRlciwgZXRjLikNCg0KSSB3b3VsZCBh bHNvIHJlY29tbWVuZCBmb2xsb3dpbmcgdGhlIGNvbnZlbnRpb24gb2YgaW5kaWNhdGluZyB0aGF0 IGxpbmUtd3JhcHMgYXJlIG9ubHkgZm9yIHJlYWRhYmlsaXR5LCBhbmQgaW5jbHVkaW5nIHRoZSBo ZWFkZXIgZmllbGQgbmFtZSBpbiB0aGUgZXhhbXBsZS4gUHV0dGluZyBhbGwgdGhpcyB0b2dldGhl ciwgSSBiZWxpZXZlIHdoYXQgeW91IHdhbnQgaXM6DQoNCiAgIEZvciBleGFtcGxlLCBhIElkZW50 aXR5IGhlYWRlciBmaWVsZCBmb3IgInJwaCIgbWlnaHQgbG9vaw0KICAgYXMgZm9sbG93cyAoYmFj a3NsYXNoZXMgc2hvd24gZm9yIGxpbmUgZm9sZGluZyBvbmx5KToNCg0KICAgSWRlbnRpdHk6IGV5 SmhiR2NpT2lKRlV6STFOaUlzSW5Cd2RDSTZJbkp3YUNJc0luUjVjQ0k2SW5CaGMzTndiM0owSSBc DQogICBpd2llRFYxSWpvaWFIUjBjSE02THk5M2QzY3VaWGhoYlhCc1pTNWpiMjB2WTJWeWRDNWpa WElpZlFvLmV5SmtaWE4wIFwNCiAgIElqcDdXeUowYmlJNklqRXlNVEkxTlRVd01URXpJbDE5TENK cFlYUWlPaUl4TkRRek1qQTRNelExSWl3aWIzSnBaeUkgXA0KICAgNmV5SjBiaUk2SWpFeU1UVTFO VFV3TVRFeUluMHNJbkp3YUNJNmV5SmhkWFJvSWpwYkltVjBjeTR3SWl3aWQzQnpMaiBcDQogICBB aVhYMTlDZy5zMzdTNlZDOEhNNkRsNll6SmVRRHNyWmN3SjBsaXp4aFVyQTdmXzk4b1dCSHZvLWNs LW44TUlob0NyIFwNCiAgIDE4dllZRnkzYmxYdnMzZnNsTV9vb3MyUDJEeXc7aW5mbz08aHR0cHM6 Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXIgXA0KICAgPjthbGc9RVMyNTY7cHB0PXJwaA0KDQoo Tm90ZTogdGhpcyBleGFtcGxlIGFzc3VtZXMgdGhlIGNhbGxpbmcgYW5kIGNhbGxlZCBwYXJ0eSBu dW1iZXJzIGluIHRoZSBwcmV2aW91cyBleGFtcGxlIGFyZSBjaGFuZ2VkIHRvIDEyMTU1NTUwMTEy PHRlbDooMjE1KSUyMDU1NS0wMTEyPiBhbmQgMTIxNTU1NTAxMTM8dGVsOigyMTUpJTIwNTU1LTAx MTM+LCByZXNwZWN0aXZlbHkpDQoNCg0KDQogICBBIFNJUCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNl IHR5cGljYWxseSB3aWxsIGRlcml2ZSB0aGUgdmFsdWUgb2YgInJwaCINCiAgIGZyb20gdGhlICdS ZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGJhc2VkIG9uIHBvbGljeSBhc3NvY2lhdGVk DQogICB3aXRoIHNlcnZpY2Ugc3BlY2lmaWMgdXNlIG9mIHRoZSAibmFtZXNwYWNlICIuIiByLXBy aW9yaXR5IiB2YWx1ZXMNCiAgIGJhc2VkIG9uIFtSRkM0NDEyXS4gIFRoZSBhdXRoZW50aWNhdGlv biBzZXJ2aWNlIGRlcml2ZXMgdGhlIHZhbHVlIG9mDQogICB0aGUgUEFTU1BvclQgY2xhaW0gYnkg dmVyaWZ5aW5nIHRoZSBhdXRob3JpemF0aW9uIGZvciBSZXNvdXJjZS0NCiAgIFByaW9yaXR5IChp LmUuLCB2ZXJpZnlpbmcgYSBjYWxsaW5nIHVzZXIgcHJpdmlsZWdlIGZvciBSZXNvdXJjZS0NCiAg IFByaW9yaXR5IGJhc2VkIG9uIGl0cyBpZGVudGl0eSkgd2hpY2ggbWlnaHQgYmUgZGVyaXZlZCBm cm9tIGN1c3RvbWVyDQogICBwcm9maWxlIGRhdGEgb3IgZnJvbSBhY2Nlc3MgdG8gZXh0ZXJuYWwg c2VydmljZXMuDQoNCiAgIFtSRkM0NDEyXSBhbGxvd3MgbXVsdGlwbGUgIm5hbWVzcGFjZSAiLiIg ci1wcmlvcml0eSIgcGFpcnMsIGVpdGhlciBpbg0KICAgYSBzaW5nbGUgU0lQIFJlc291cmNlLVBy aW9yaXR5IGhlYWRlciBvciBhY3Jvc3MgbXVsdGlwbGUgU0lQDQoNCg0KDQpTaW5nbGUgcXVvdGVz IGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQoiLi4uaGVhZGVyIGZpZWxkLi4uIg0KDQoN CiAgIFJlc291cmNlLVByaW9yaXR5IGhlYWRlcnMuICBIb3dldmVyLCBpdCBpcyBub3QgbmVjZXNz YXJ5IHRvIHNpZ24gYWxsDQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJp b3JpdHknLg0KDQoiLi4uaGVhZGVyIGZpZWxkcy4uLiINCg0KDQogICBjb250ZW50IG9mIGEgU0lQ IFJlc291cmNlLVByaW9yaXR5IGhlYWRlciBvciBhbGwgU0lQIFJlc291cmNlLQ0KDQoNCg0KU2lu Z2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy4NCg0KIi4uLmhlYWRlciBmaWVs ZC4uLiINCg0KDQogICBQcmlvcml0eSBoZWFkZXJzIGluIGEgZ2l2ZW4gU0lQIG1lc3NhZ2UuICBB biBhdXRob3JpdHkgaXMgb25seQ0KDQoNCg0KU2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNl LVByaW9yaXR5Jy4NCg0KIi4uLmhlYWRlciBmaWVsZHMuLi4iDQoNCg0KICAgcmVzcG9uc2libGUg Zm9yIHNpZ25pbmcgdGhlIGNvbnRlbnQgb2YgYSBTSVAgUmVzb3VyY2UtUHJpb3JpdHkgaGVhZGVy DQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQoiLi4u aGVhZGVyIGZpZWxkLi4uIg0KDQoNCiAgIGZvciB3aGljaCBpdCBoYXMgYXV0aG9yaXR5IChlLmcu LCBhIHNwZWNpZmljICJuYW1lc3BhY2UgIi4iDQogICByLXByaW9yaXR5IikuDQoNCjQuMi4gIFZl cmlmaWNhdGlvbiBTZXJ2aWNlIEJlaGF2aW9yDQoNCiAgIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRi aXNdIFNlY3Rpb24gNi4yIFN0ZXAgNSByZXF1aXJlcyB0aGF0DQogICBzcGVjaWZpY2F0aW9ucyBk ZWZpbmluZyAicHB0IiB2YWx1ZXMgZGVzY3JpYmUgYW55IGFkZGl0aW9uYWwgdmVyaWZpZXINCiAg IGJlaGF2aW9yLiAgVGhlIGJlaGF2aW9yIHNwZWNpZmllZCBmb3IgdGhlICJwcHQiIHZhbHVlcyBv ZiAicnBoIiBpcyBhcw0KICAgZm9sbG93czoNCg0KICAgVGhlIHZlcmlmaWNhdGlvbiBzZXJ2aWNl IE1VU1QgZXh0cmFjdCB0aGUgdmFsdWUgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgImF1dGgiIGtl eSBpbiBhIGZ1bGwgZm9ybSBQQVNTUG9yVCB3aXRoIGEgInBwdCIgdmFsdWUgb2YgInJwaCIuICBJ Zg0KICAgdGhlIHNpZ25hdHVyZSB2YWxpZGF0ZXMsIHRoZW4gdGhlIHZlcmlmaWNhdGlvbiBzZXJ2 aWNlIGNhbiB1c2UgdGhlDQogICB2YWx1ZSBvZiB0aGUgInJwaCIgY2xhaW0gYXMgdmFsaWRhdGlv biB0aGF0IHRoZSBjYWxsaW5nIHBhcnR5IGlzDQogICBhdXRob3JpemVkIGZvciBSZXNvdXJjZS1Q cmlvcml0eSwgd2hpY2ggd291bGQgaW4gdHVybiBiZSB1c2VkIGZvcg0KDQoNClNpbmdsZSBxdW90 ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScuDQoNClRoaXMgdGV4dCBpcyBhbWJpZ3VvdXMg YWJvdXQgd2hldGhlciB0aGUgdmFsaWRhdGlvbiBpbmRpY2F0ZXMgdGhhdCB0aGUgY2FsbGluZyBw YXJ0eSBpcyBhdXRob3JpemVkIHRvIHVzZSB0aGUgcHJpb3JpdGllcyBpbmRpY2F0ZWQgaW4gdGhl IHBhc3Nwb3J0IG9iamVjdCwgb3IgdGhlIHZhbHVlcyBpbiB0aGUgU0lQICdSZXNvdXJjZS1Qcmlv cml0eScgaGVhZGVyIGZpZWxkOyBhbmQgKHRha2VuIG9uIGl0cyBmYWNlKSBpbXBsaWVzIHRoZSBs YXR0ZXIsIHdoZW4gdGhlIGludGVudGlvbiBoZXJlIHNob3VsZCBjbGVhcmx5IGJlIHRoZSBmb3Jt ZXIuDQoNCiIuLi5hdXRob3JpemVkIGZvciAnUmVzb3VyY2UtUHJpb3JpdHknIGluZGljYXRlZCBp biB0aGUgY2xhaW0uIFRoaXMgdmFsdWUgd291bGQgaW4gdHVybiBiZSB1c2VkIGZvci4uLiINCg0K VGhlIHRleHQgYWxzbyBuZWVkcyB0byBzYXkgc29tZXRoaW5nIGFib3V0IGNvbXBhcmluZyB2YWx1 ZXMgaW4gdGhlIGNsYWltIHRvIHZhbHVlcyBpbiB0aGUgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFk ZXIgZmllbGQsIGFuZCB3aGF0IGEgbWlzbWF0Y2ggbWlnaHQgbWVhbi4gVGhlIGRvY3VtZW50IHNh eXMgZWxzZXdoZXJlIHRoYXQgdGhlIHNpZ25hdHVyZSBtaWdodCBvbmx5IGNvdmVyIHNvbWUgb2Yg dGhlIHItdmFsdWVzLCB3aGljaCBtYWtlcyBpdCBlbnRpcmVseSBwb3NzaWJsZSB0aGF0IHRoZSAn UmVzb3VyY2UtUHJpb3JpdHknIGZpZWxkIG1pZ2h0IGNvbnRhaW4gbW9yZSB2YWx1ZXMgdGhhbiBh cmUgc2lnbmVkLiBPbiB0aGUgb3RoZXIgaGFuZCwgaW50ZXJtZWRpYXJpZXMgbWlnaHQgcmVhc29u YWJseSByZW1vdmUgci12YWx1ZXMgYXMgdGhlIGNhbGwgaXMgcHJvY2Vzc2VkLiBUaGlzIHByb2Jh Ymx5IG1lYW5zIHRoYXQgdGhvc2UgcmVtb3ZlZCBwcmlvcml0aWVzIHNob3VsZCBub3QgYmUgdXNl ZCwgZXZlbiBpZiB0aGV5IGFyZSBwcmVzZW50IGluIHRoZSBwYXNzcG9ydC4gSXQgc2VlbXMgcmVh c29uYWJsZSB0byBzYXkgdGhhdCAqdHlwaWNhbCogcHJvY2Vzc2luZyBieSBhIHJlY2VpdmluZyBw YXJ0eSB3b3VsZCBiZSB0byB0YWtlIHRoZSAqdW5pb24qIG9mIGFsbCBSUEggcGFzc3BvcnRzIHRo YXQgdGhleSB0cnVzdCwgYW5kICppbnRlcnNlY3QqIHRoYXQgd2l0aCB0aGUgcHJpb3JpdGllcyBp biAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZHMgdG8gZ2V0IHRoZSBhY3R1YWwgcHJp b3JpdHkgb3IgcHJpb3JpdGllcyB0byBiZSBhcHBsaWVkIHRvIHRoZSBjYWxsIChzdWJqZWN0IHRv IGxvY2FsIHBvbGljeSkuDQoNCg0KICAgcHJpb3JpdHkgdHJlYXRtZW50IGluIGFjY29yZGFuY2Ug d2l0aCBsb2NhbCBwb2xpY3kgZm9yIHRoZSBhc3NvY2lhdGVkDQogICBjb21tdW5pY2F0aW9uIHNl cnZpY2UuDQoNCiAgIEluIGFkZGl0aW9uLCBbSS1ELmlldGYtc3Rpci1yZmM0NDc0YmlzXSBTZWN0 aW9uIDYuMiBTdGVwIDQgcmVxdWlyZXMNCiAgICJpYXQiIHZhbHVlIGluICJycGgiIGNsYWltIHRv IGJlIHZlcmlmaWVkLg0KDQogICBUaGUgYmVoYXZpb3Igb2YgYSBTSVAgVUFzIHVwb24gcmVjZWl2 aW5nIGFuIElOVklURSBjb250YWluaW5nIGENCg0KDQoNCiIuLi5vZiBhIFNJUCBVQSB1cG9uLi4u Ig0KDQpvcg0KDQoiLi4ub2YgU0lQIFVBcyB1cG9uLi4uIg0KDQoNCiAgIFBBU1Nwb3JUIG9iamVj dCB3aXRoIGEgInJwaCIgY2xhaW0gd2lsbCBsYXJnZWx5IHJlbWFpbiBhIG1hdHRlciBvZg0KICAg aW1wbGVtZW50YXRpb24gcG9saWN5IGZvciB0aGUgc3BlY2lmaWMgY29tbXVuaWNhdGlvbiBzZXJ2 aWNlLiAgSW4NCiAgIG1vc3QgY2FzZXMsaW1wbGVtZW50YXRpb25zIHdvdWxkIGFjdCBiYXNlZCBv biBjb25maWRlbmNlIGluIHRoZQ0KDQoNCg0KIi4uLmNhc2VzLCBpbXBsZW1lbnRhdGlvbnMuLi4i DQoNCihzcGFjZSBhZnRlciBjb21tYSkNCg0KDQogICB2ZXJhY2l0eSBvZiB0aGlzIGluZm9ybWF0 aW9uLiAgVGhlIHVzZSBvZiB0aGUgY29tcGFjdCBmb3JtIG9mDQoNCg0KDQpQYXJhZ3JhcGggYnJl YWsgYmVmb3JlICJUaGUiLg0KDQoNCiAgIFBBU1Nwb3JUIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhp cyBkb2N1bWVudC4NCg0KNS4gIEZ1cnRoZXIgSW5mb3JtYXRpb24gQXNzb2NpYXRlZCB3aXRoIFJl c291cmNlLVByaW9yaXR5DQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJp b3JpdHknLg0KDQoNCg0KICAgVGhlcmUgbWF5IGJlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJv dXQgdGhlIGNhbGxpbmcgcGFydHkgb3IgdGhlDQogICBjYWxsIHRoYXQgY291bGQgYmUgcmVsZXZh bnQgdG8gYXV0aG9yaXphdGlvbiBmb3IgUmVzb3VyY2UtUHJpb3JpdHkuDQoNCg0KDQpTaW5nbGUg cXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQoNCiAgIFRoaXMgbWF5IGluY2x1 ZGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgZGV2aWNlIHN1YnNjcmlwdGlvbiBvZg0KICAg dGhlIGNhbGxlciwgb3IgdG8gYW55IGluc3RpdHV0aW9ucyB0aGF0IHRoZSBjYWxsZXIgb3IgZGV2 aWNlIGlzDQogICBhc3NvY2lhdGVkIHdpdGgsIG9yIGV2ZW4gY2F0ZWdvcmllcyBvZiBpbnN0aXR1 dGlvbnMuICBBbGwgb2YgdGhlc2UNCiAgIGRhdGEgZWxlbWVudHMgd291bGQgYmVuZWZpdCBmcm9t IHRoZSBzZWN1cmUgYXR0ZXN0YXRpb25zIHByb3ZpZGVkIGJ5DQogICB0aGUgU1RJUiBhbmQgUEFT U3BvclQgZnJhbWV3b3Jrcy4gIFRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSAicnBoIg0KICAgY2xh aW0gY291bGQgZW50YWlsIHRoZSBvcHRpb25hbCBwcmVzZW5jZSBvZiBvbmUgb3IgbW9yZSBzdWNo DQogICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGZpZWxkcy4NCg0KICAgQSBuZXcgSUFOQSByZWdp c3RyeSBoYXMgYmVlbiBkZWZpbmVkIHRvIGhvbGQgcG90ZW50aWFsIHZhbHVlcyBvZiB0aGUNCiAg ICJycGgiIGFycmF5OyBzZWUgU2VjdGlvbiA2LjIuICBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgInJw aCIgY2xhaW0gbWF5DQogICBoYXZlIG9uZSBvciBtb3JlIHN1Y2ggYWRkaXRpb25hbCBpbmZvcm1h dGlvbiBmaWVsZChzKS4gIERldGFpbHMgb2YNCiAgIHN1Y2ggInJwaCIgY2xhaW0gdG8gZW5jb21w YXNzIG90aGVyIGRhdGEgZWxlbWVudHMgYXJlIGxlZnQgZm9yIGZ1dHVyZQ0KICAgdmVyc2lvbiBv ZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNCjYuICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCjYuMS4g IEpTT04gV2ViIFRva2VuIENsYWltcyBSZWdpc3RyYXRpb24NCg0KDQoNCkkgdGhpbmsgdGhlcmUn cyBzb21lIGNvbmZ1c2lvbiBoZXJlLiBZb3UncmUgcmVnaXN0ZXJpbmcgYSBQQVNTcG9yVCBwcHQg dmFsdWUsIG5vdCBhIG5ldyBKV1QgY2xhaW0uIFRoYXQgaXMgdG8gc2F5LCB5b3UncmUgYWRkaW5n IGFuIGVudHJ5IHRvIHRoaXMgdGFibGU6DQoNCmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1l bnRzL3Bhc3Nwb3J0L3Bhc3Nwb3J0LnhodG1sDQoNCk5vdCB0byB0aGlzIHRhYmxlOg0KDQpodHRw czovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9qd3Qvand0LnhodG1sDQoNCllvdSB3b3VsZCBv bmx5IHVzZSB0aGUgc2Vjb25kIHRhYmxlIGlmIHlvdSBoYWQgYSBuZXcga2V5IHRvIGFkZCB0byB0 aGUgUEFTU3BvclQgaGVhZGVyIC0tIHRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBkbyB0aGF0 Lg0KDQpUaGlzIHNlY3Rpb24gYWxzbyBuZWVkcyBzb21lIGludHJvZHVjdG9yeSB0ZXh0IHRvIGxl dCB0aGUgSUFOQSBrbm93IGV4YWN0bHkgd2hhdCB0byBkbzsgZS5nLiAiVGhpcyBkb2N1bWVudCBy ZWdpc3RlcnMgYSBuZXcgdmFsdWUgZm9yIHRoZSAiUGVyc29uYWwgQXNzZXJ0aW9uIFRva2VuIChQ QVNTcG9yVCkgRXh0ZW5zaW9ucyIgdGFibGUuDQoNCiAgIG8gIHBwdCB2YWx1ZTogInJwaCINCg0K ICAgbyAgU3BlY2lmaWNhdGlvbiBEb2N1bWVudChzKTogU2VjdGlvbiAzIG9mIFtSRkNUaGlzXQ0K DQo2LjIuICBQQVNTcG9yVCAncnBoJyBUeXBlcw0KDQogICBUaGlzIGRvY3VtZW50IHJlcXVlc3Rz IHRoYXQgdGhlIElBTkEgYWRkIGEgbmV3IGVudHJ5IHRvIHRoZSBQQVNTcG9yVA0KICAgVHlwZXMg cmVnaXN0cnkgZm9yIHRoZSB0eXBlICJycGgiIHdoaWNoIGlzIHNwZWNpZmllZCBpbiBbUkZDVGhp c10uDQoNCg0KDQpUaGVyZSBpc24ndCBhbiBJQU5BIHRhYmxlIGNhbGxlZCAiUEFTU3BvclQgVHlw ZXMuIiBJIHByZXN1bWUgdGhpcyBpcyB0aGUgcmVnaXN0cmF0aW9uIHdlIGp1c3QgZGlzY3Vzc2Vk IGluIHNlY3Rpb24gNi4xLCBhbmQgc28gdGhlIGFib3ZlIHR3byBsaW5lcyBjYW4gYmUgcmVtb3Zl ZC4NCg0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gYWxzbyByZXF1ZXN0cyB0aGF0IHRoZSBJQU5B IGNyZWF0ZSBhIG5ldyByZWdpc3RyeQ0KICAgZm9yIFBBU1Nwb3JUICJycGgiIHR5cGVzLiAgUmVn aXN0cmF0aW9uIG9mIG5ldyBQQVNTcG9yVCAicnBoIiB0eXBlcw0KICAgc2hhbGwgYmUgdW5kZXIg dGhlIHNwZWNpZmljYXRpb24gcmVxdWlyZWQgcG9saWN5LiAgVGhpcyByZWdpc3RyeSBpcw0KICAg dG8gYmUgaW5pdGlhbGx5IHBvcHVsYXRlZCB3aXRoIGEgc2luZ2xlIHZhbHVlIGZvciAiYXV0aCIg d2hpY2ggaXMNCiAgIHNwZWNpZmllZCBpbiBbUkZDVGhpc10uDQoNCg0KDQpUaGlzIG5lZWRzIHRv IGJlIHZlcnkgY2xlYXIgYWJvdXQgdGhlIGZpZWxkcyB0byBiZSBpbmNsdWRlZCBpbiB0aGlzIG5l dyByZWdpc3RyeSAoZS5nLiwgIlJlZ2lzdHJ5IGVudHJpZXMgbXVzdCBjb250YWluIHR3byBmaWVs ZHM6IHRoZSBuYW1lIG9mIHRoZSAncnBoJyB0eXBlIGFuZCB0aGUgc3BlY2lmaWNhdGlvbiBpbiB3 aGljaCB0aGUgdHlwZSBpcyBkZXNjcmliZWQiKS4NCg0KDQoNCjcuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucw0KDQogICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFtJ LUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNdDQogICBpbiBTZWN0aW9uIDEwIGFyZSBhcHBsaWNhYmxl IGhlcmUuDQoNCjcuMS4gIEF2b2lkYW5jZSBvZiByZXBsYXkgYW5kIGN1dCBhbmQgcGFzdGUgYXR0 YWNrcw0KDQogICBUaGUgUEFTU3BvclQgZXh0ZW5zaW9uIHdpdGggYSAicHB0IiB2YWx1ZSBvZiAi cnBoIiBNVVNUIG9ubHkgYmUgc2VudA0KICAgd2l0aCBTSVAgSU5WSVRFIHdoZW4gJ1Jlc291cmNl LVByaW9yaXR5JyBoZWFkZXIgaXMgdXNlZCB0byBjb252ZXkgdGhlDQoNCg0KDQoiLi4uaGVhZGVy IGZpZWxkLi4uIg0KDQoNCiAgIHByaW9yaXR5IG9mIHRoZSBjb21tdW5pY2F0aW9uIGFzIGRlZmlu ZWQgaW4gW1JGQzQ0MTJdLiAgVG8gYXZvaWQgdGhlDQogICByZXBsYXksIGFuZCBjdXQgYW5kIHBh c3RlIGF0dGFja3MsIHRoZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAxMC4x IG9mIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNdIE1VU1QgYmUgZm9sbG93ZWQuDQoNCjcuMi4g IFNvbHV0aW9uIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSB1c2Ugb2YgZXh0ZW5zaW9uIHRvIFBB U1Nwb3JUIHRva2VucyB3aXRoICJwcHQiIHZhbHVlICJycGgiIGJhc2VkDQogICBvbiB0aGUgdmFs aWRhdGlvbiBvZiB0aGUgZGlnaXRhbCBzaWduYXR1cmUgYW5kIHRoZSBhc3NvY2lhdGVkDQogICBj ZXJ0aWZpY2F0ZSByZXF1aXJlcyBjb25zaWRlcmF0aW9uIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBh bmQNCiAgIGF1dGhvcml0eSBvciByZXB1dGF0aW9uIG9mIHRoZSBzaWduZXIgdG8gYXR0ZXN0IHRv IHRoZSBpZGVudGl0eSBiZWluZw0KICAgYXNzZXJ0ZWQuICBUaGUgZm9sbG93aW5nIGNvbnNpZGVy YXRpb25zIHNob3VsZCBiZSByZWNvZ25pemVkIHdoZW4NCiAgIHVzaW5nIFBBU1Nwb3JUIGV4dGVu c2lvbiB3aXRoICJwcHQiIHZhbHVlIG9mICJycGgiOg0KDQogICBvICBBbiBhdXRob3JpdHkgKHNp Z25lcikgaXMgb25seSBhbGxvd2VkIHRvIHNpZ24gdGhlIGNvbnRlbnQgb2YgYSBTSVANCiAgICAg ICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZvciB3aGljaCBpdCBoYXMgdGhlIHJpZ2h0IGF1 dGhvcml0eS4NCg0KDQoNCiIuLi5oZWFkZXIgZmllbGQuLi4iDQoNCg0KICAgICAgVGhlIGF1dGhv cml0eSB0aGF0IHNpZ25zIHRoZSB0b2tlbiBNVVNUIGhhdmUgYSBzZWN1cmUgbWV0aG9kIGZvcg0K ICAgICAgYXV0aGVudGljYXRpb24gb2YgdGhlIGVuZCB1c2VyIG9yIHRoZSBkZXZpY2UuDQoNCiAg IG8gIFRoZSB2ZXJpZmljYXRpb24gb2YgdGhlIHNpZ25hdHVyZSBNVVNUIGluY2x1ZGUgbWVhbnMg b2YgdmVyaWZ5aW5nDQogICAgICB0aGF0IHRoZSBzaWduZXIgaXMgYXV0aG9yaXRhdGl2ZSBmb3Ig dGhlIHNpZ25lZCBjb250ZW50IG9mIHRoZSBTSVANCg0KDQoNCkl0J3Mgbm90IGNsZWFyIHdoYXQg YXV0aG9yaXR5IGlzIGJlaW5nIGNsYWltZWQgaGVyZS4gSXMgdGhpcyBzdXBwb3NlZCB0byBtZWFu IHNvbWV0aGluZyBsaWtlICIuLi52ZXJpZnlpbmcgdGhhdCB0aGUgc2lnbmVyIGlzIGF1dGhvcml0 YXRpdmUgZm9yIHRoZSBvcmlnaW5hdGluZyB0biBpbiB0aGUgUEFTU3BvclQuLi4iPyBPciAiLi4u YXV0aG9yaXRhdGl2ZSBmb3IgdGhlIHJlc291cmNlIHByaW9yaXR5IG5hbWVzcGFjZSBpbiB0aGUg UEFTU3BvclQ/IiBXaGF0ZXZlciB0aGUgc2VydmVyIGlzIHB1cnBvcnRlZGx5IGF1dGhvcml0YXRp dmUgZm9yIG5lZWRzIHRvIGJlIGNsZWFybHkgc3BlbGxlZCBvdXQuDQoNCg0KICAgICAgJ1Jlc291 cmNlLVByaW9yaXR5JyBoZWFkZXIuDQoNCg0KDQoiLi4uaGVhZGVyIGZpZWxkLiINCg0KDQovYQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3RpciBt YWlsaW5nIGxpc3QNCnN0aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXINCg0K --_000_7594FB04B1934943A5C02806D1A2204B6C153D09ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnR0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDMyNzMxMjQ2Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTEwNjMyNzc4ODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTM3OTYyODAyOTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTM3NTY4MjYwO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNTYzOTA1Nzg1Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMjg5NDkxOTUyO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMw0KCXttc28tbGlzdC1pZDoyMDIyNTgyMzMwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MzE0MDAzNDA7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwz OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy ODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+4oCmYW5kLCBpZiBSUEggaXMg b25seSBzdXBwb3NlZCB0byBiZSB1c2VkIGJ5IHRoZSBvcmlnaW5hdGluZyBuZXR3b3JrLCBJIHRo aW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gc2F5IHRoYXQgbW9yZSBleHBsaWNpdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBzdGlyIFttYWlsdG86 c3Rpci1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xt YmVyZzxicj4NCjxiPlNlbnQ6PC9iPiAwNCBGZWJydWFyeSAyMDE4IDE4OjM0PGJyPg0KPGI+VG86 PC9iPiBTdWJpciBEYXMgJmx0O3N1YmlyZGFzMjFAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gc3RpckBpZXRmLm9yZzsgQWRhbSBSb2FjaCAmbHQ7YWRhbUBub3N0cnVtLmNvbSZndDs7IFNU SVIgQ2hhaXJzICZsdDtzdGlyLWNoYWlyc0BpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtc3Rpci1y cGguYWxsQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3Rpcl0gQUQg UmV2aWV3OiBkcmFmdC1pZXRmLXN0aXItcnBoLTAyIC0gYXV0aG9yaXR5IHRvIGFzc2VydCB0aGUg Y2FsbGVycyBpZGVudGl0eSBhc3N1bWVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlRoZSB0ZXh0IHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4mbmJzcDsmbmJzcDsg4oCcVGhlIGNyZWRlbnRpYWxzIChlLmcuLCBhdXRob3JpdHkgcmVzcG9u c2libGUgZm9yIGF1dGhvcml6aW5nIFJlc291cmNlLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgUHJpb3JpdHkpIHVzZWQgdG8gY3JlYXRl IHRoZSBzaWduYXR1cmUgbXVzdCBoYXZlIGF1dGhvcml0eSBvdmVyIHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgbmFtZXNwYWNlIG9m IHRoZSAmcXVvdDtycGgmcXVvdDsgY2xhaW0gYW5kIHRoZXJlIGlzIG9ubHkgb25lIGF1dGhvcml0 eSBwZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 Jm5ic3A7IGNsYWltLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SWYgdGhlIGNyZWRlbnRpYWxzIGRvbuKAmXQgbmVlZCB0byBoYXZlIGF1dGhvcml0eSBvZiB0aGUg b3RoZXIgY2xhaW1zIChlLmcuLCDigJxvcmln4oCdKSBpbiB0aGUgUlBIIFBBU1NQb3JUIEkgdGhp bmsgeW91IHNob3VsZCBleHBsaWNpdGx5DQogc2F5IHNvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IFN1YmlyIERhcyBbPGEgaHJlZj0ibWFpbHRvOnN1YmlyZGFzMjFA Z21haWwuY29tIj5tYWlsdG86c3ViaXJkYXMyMUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IDAyIEZlYnJ1YXJ5IDIwMTggMDE6MDQ8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhv bG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Ij5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g QWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFkYW1Abm9z dHJ1bS5jb208L2E+Jmd0OzsgU1RJUiBDaGFpcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGlyLWNo YWlyc0BpZXRmLm9yZyI+c3Rpci1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1h aWx0bzpzdGlyQGlldGYub3JnIj5zdGlyQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtc3Rpci1ycGguYWxsQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtc3Rpci1y cGguYWxsQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3N0aXJd IEFEIFJldmlldzogZHJhZnQtaWV0Zi1zdGlyLXJwaC0wMiAtIGF1dGhvcml0eSB0byBhc3NlcnQg dGhlIGNhbGxlcnMgaWRlbnRpdHkgYXNzdW1lZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gQ2hyaXN0ZXIsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2lnbmluZyBlbnRpdHkgZG9lcyBub3Qg aGF2ZSBhbHdheXMgdGhlIGF1dGhvcml0eSB0byBhc3NlcnQgdGhlIGNhbGxlciBpZGVudGl0eSBp biBycGguIFdlIGFyZSBzdWJtaXR0aW5nIHZlci0wMyBkcmFmdCZuYnNwOyBhbmQgaXQgaXMgY2xh cmlmaWVkJm5ic3A7IGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7 VGhlIGNyZWRlbnRpYWxzIChlLmcuLCBhdXRob3JpdHkgcmVzcG9uc2libGUgZm9yIGF1dGhvcml6 aW5nIFJlc291cmNlLVByaW9yaXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlIG11c3Qg aGF2ZSBhdXRob3JpdHkgb3ZlciB0aGUgbmFtZXNwYWNlIG9mIHRoZeKAnHJwaCZxdW90Ow0KIGNs YWltLi4mcXVvdDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LVN1YmlyDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgSmFuIDIyLCAyMDE4IGF0IDM6MjcgUE0sIENocmlzdGVyIEhvbG1iZXJnICZs dDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9 Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QW5vdGhlciBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDMgY29udGFpbnMg dGhlIGZvbGxvd2luZyBleGFtcGxlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyB7ICZxdW90O29yaWcmcXVvdDs6eyZxdW90 O3RuJnF1b3Q7OiZxdW90Ozwvc3Bhbj48YSBocmVmPSJ0ZWw6KDIxNSklMjA1NTUtMTIxMiIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MTIxNTU1NTEyMTI8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mcXVvdDt9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Rlc3QmcXVvdDs6e1smcXVvdDt0biZxdW90Ozom cXVvdDs8L3NwYW4+PGEgaHJlZj0idGVsOigyMTIpJTIwNTU1LTEyMTMiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjEyMTI1NTUxMjEzPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+JnF1b3Q7XX0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O2lhdCZxdW90OzoxNDQzMjA4MzQ1LDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtycGgmcXVvdDs6eyZxdW90O2F1dGgm cXVvdDs6WyZxdW90O2V0cy4wJnF1b3Q7LCZxdW90O3dwcy4wJnF1b3Q7XX08L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igKZhbmQgdGhlIGZvbGxvd2luZyB0 ZXh0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyDigJxUaGUgY3JlZGVudGlhbHMgKGUuZy4sIGF1dGhvcml0eSByZXNwb25zaWJsZSBm b3IgYXV0aG9yaXppbmcgUmVzb3VyY2UtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IFByaW9yaXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlIG11c3QgaGF2ZSBhdXRob3Jp dHkgb3ZlciB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJnF1b3Q7cnBoJnF1 b3Q7IGNsYWlt4oCm4oCdDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxhIG5hbWU9Im1fLTI5Mzg3NDc5MDYxMjMyMDM0OTRfX01haWxFbmRDb21wb3NlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlNpbmNlIHRoZSBjbGFpbSBhbHNvIGNvbnRhaW5zIOKAnG9yaWfigJ0sIGlzIHRoZSBhc3N1 bXB0aW9uIHRoYXQgdGhlIHNpZ25pbmcgZW50aXR5IGFsd2F5cyBhbHNvIGhhcyBhdXRob3JpdHkN CiB0byBhc3NlcnQgdGhlIGNhbGxlcnMgaWRlbnRpdHk/IEkgdGhpbmsgaXQgd291bGQgYmUgZ29v ZCB0byBleHBsaWNpdGx5IG1lbnRpb24gaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gc3Rpcg0KIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzdGlyLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5z dGlyLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWRhbSBSb2FjaDxicj4NCjxiPlNlbnQ6PC9iPiAy MCBKYW51YXJ5IDIwMTggMDA6MTU8YnI+DQo8Yj5Ubzo8L2I+IFNUSVIgQ2hhaXJzICZsdDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnN0aXItY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+c3Rpci1jaGFpcnNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnN0aXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5zdGlyQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc3Rpci1ycGguYWxs QHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+ZHJhZnQtaWV0Zi1zdGlyLXJwaC5hbGxAdG9vbHMuaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc3Rpcl0g QUQgUmV2aWV3OiBkcmFmdC1pZXRmLXN0aXItcnBoLTAyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cD5JJ20gZG9pbmcgbXkgQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc3Rpci1ycGgtMDIu IFRoYW5rcyB0byBldmVyeW9uZSB3aG8gaGFzIHdvcmtlZCBvbiB0aGlzIGRvY3VtZW50LCBhbmQg dGhlIGF1dGhvcnMgYW5kIGNoYWlycyBpbiBwYXJ0aWN1bGFyLjxvOnA+PC9vOnA+PC9wPg0KPHA+ VGhlIHRlY2huaWNhbCBjb250ZW50IGhlcmUgbG9va3MgZ2VuZXJhbGx5IGdvb2QgdG8gbWUuIEkn ZCBsaWtlIHRvIHNlZSBhIGZldyBpc3N1ZXMgYWRkcmVzc2VkIGJlZm9yZSBJRVRGIExDLiBJbiBz aG9ydCBzdW1hcnk6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NClRoZSB2YWxpZGF0aW9uIHNl Y3Rpb24gbmVlZHMgdG8gYWRkIGEgZGlzY3Vzc2lvbiBvZiBob3cgdG8gdHJlYXQgY2FsbHMgd2hl biB0aGUgcHJpb3JpdHkgdmFsdWVzIGluICZxdW90O3JwaCZxdW90OyBwYXNzcG9ydHMgYW5kIFNJ UCAmcXVvdDtSZXNvdXJjZS1Qcmlvcml0eSZxdW90OyBoZWFkZXIgZmllbGRzIGFyZW4ndCAxMDAl IGlkZW50aWNhbC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMyI+DQpUaGUgZXhhbXBsZXMgbmVlZCBzb21lIGFkanVzdG1lbnQuPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzMiPg0KVGhlcmUgaXMgYSBtaW5vciBwb2ludCBvZiBhbWJpZ3VpdHkgaW4gdGhlIFNlY3VyaXR5 IFNlY3Rpb24sIGJ1dCB0aGlzIHNob3VsZCBiZSBlYXN5IHRvIGZpeCwgYXMgbG9uZyBhcyB0aGUg V0cga25vd3Mgd2hhdCB3YXMgaW50ZW5kZWQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KVGhlIElBTkEgYWN0aW9ucyBuZWVk IGEgbGl0dGxlIGJpdCBvZiBhZGp1c3RtZW50LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NClRoZXJlIGFyZSBhIG51bWJlciBv ZiBtaW5vciBlZGl0b3JpYWwgaXNzdWVzIHRvIGJlIGNsZWFuZWQgdXAuPG86cD48L286cD48L2xp PjwvdWw+DQo8cD5EZXRhaWxlZCBjb21tZW50cyBvbiB0aGVzZSBwb2ludHMgYXJlIGlubGluZSBp biB0aGUgZG9jdW1lbnQgYmVsb3cuIEkndmUgcmVtb3ZlZCBzb21lIHBvcnRpb25zIG9mIHRoZSBk b2N1bWVudCBvbiB3aGljaCBJIGhhdmUgbm8gY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGJyPg0KPHR0PkFic3RyYWN0PC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoaXMg ZG9jdW1lbnQgZXh0ZW5kcyB0aGUgU1RJUiBQQVNTcG9yVCBzcGVjaWZpY2F0aW9uIHRvIGFsbG93 IHRoZTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi50aGUgU2VjdXJlIFRlbGVwaG9uZSBJZGVudGl0 eSBSZXZpc2l0ZWQgKFNUSVIpIFBlcnNvbmFsIEFzc2VydGlvbiBUb2tlbiAoUEFTU3BvclQpIHNw ZWNpZmljYXRpb24gZGVmaW5lZCBpbiBSRkMgODEyMi4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0K PHA+KFNlZSA8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJi cmV2LmV4cGFuc2lvbi50eHQiIHRhcmdldD0iX2JsYW5rIj4NCiZsdDtodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJicmV2LmV4cGFuc2lvbi50eHQmZ3Q7PC9hPiBmb3IgZ3Vp ZGFuY2Ugb24gYWJicmV2aWF0aW9ucyk8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGluY2x1c2lvbiBvZiBjcnlwdG9ncmFwaGljYWxseS1z aWduZWQgYXNzZXJ0aW9ucyBvZiBhdXRob3JpemF0aW9uIGZvcjwvc3Bhbj48L3R0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoZSB2YWx1ZXMgcG9wdWxhdGVkIGluIHRoZSBTSVAg J1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQsPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IHdoaWNoIGlzIHVzZWQgZm9yIGNvbW11bmljYXRpb25zIHJlc291cmNlIHByaW9yaXRpemF0 aW9uLjwvdHQ+PGJyPg0KPGJyPg0KPHR0Pi4uLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PjEuJm5ic3A7 IEludHJvZHVjdGlvbjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBQQVNTcG9yVCBb SS1ELmlldGYtc3Rpci1wYXNzcG9ydF0gaXMgYSB0b2tlbiBmb3JtYXQgYmFzZWQgb24gSldUPC90 dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFtSRkM3NTE5XSBmb3IgY29udmV5aW5nIGNyeXB0b2dy YXBoaWNhbGx5LXNpZ25lZCBpbmZvcm1hdGlvbiBhYm91dDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyB0aGUgaWRlbnRpdGllcyBpbnZvbHZlZCBpbiBwZXJzb25hbCBjb21tdW5pY2F0aW9uczsg aXQgaXMgdXNlZCB3aXRoPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFNUSVIgW0ktRC5pZXRm LXN0aXItcmZjNDQ3NGJpc10gdG8gY29udmV5IGEgc2lnbmVkIGFzc2VydGlvbiBvZiB0aGU8L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgaWRlbnRpdHkgb2YgdGhlIHBhcnRpY2lwYW50cyBpbiBy ZWFsLXRpbWUgY29tbXVuaWNhdGlvbnMgZXN0YWJsaXNoZWQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgdmlhIGEgcHJvdG9jb2wgbGlrZSBTSVAuJm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlvbiBl eHRlbmRzIFBBU1Nwb3JUIHRvPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLmxpa2UgU0lQIFtSRkMz MjYxXS4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+KFdlIHdhbnQgdG8gY2l0ZSBTSVAgdGhl IGZpcnN0IHRpbWUgaXQgaXMgbWVudGlvbmVkKTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgYWxsb3cgY3J5cHRvZ3JhcGhpYy1zaWduaW5n IG9mIHRoZSBTSVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXI8L3NwYW4+PC90dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBmaWVsZCBkZWZpbmVkIGluIFtSRkM0NDEyXS48L3R0 Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgW1JGQzQ0MTJdIGRlZmluZXMgdGhlIFNJUCAn UmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBmb3I8L3R0Pjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgY29tbXVuaWNhdGlvbnMgUmVzb3VyY2UgUHJpb3JpdHkuJm5ic3A7IEFzIHNwZWNpZmll ZCBpbiBbUkZDNDQxMl0sIHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyAnUmVzb3VyY2Ut UHJpb3JpdHknIGhlYWRlciBmaWVsZCBtYXkgYmUgdXNlZCBieSBTSVAgdXNlciBhZ2VudHM8L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgW1JGQzMyNjFdLCBpbmNsdWRpbmcsIFB1YmxpYyBTd2l0 Y2hlZCBUZWxlcGhvbmUgTmV0d29yayAoUFNUTik8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uaW5j bHVkaW5nIFB1YmxpYyBTd2l0Y2hlZC4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+KHJlbW92 ZSB0aGUgY29tbWEpPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZuYnNwOyZuYnNwOyBnYXRld2F5cyBhbmQgdGVybWluYWxzLCBhbmQgU0lQIHByb3h5IHNlcnZl cnMgdG8gaW5mbHVlbmNlPC9zcGFuPjwvdHQ+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLmFuZCBieSBTSVAgcHJveHkg c2VydmVycywgdG8gaW5mbHVlbmNlLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4oYWRkICZx dW90O2J5JnF1b3Q7IGFuZCBjb21tYSk8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IHByaW9yaXRpemF0aW9uIGFmZm9yZGVkIHRvIGNvbW11 bmljYXRpb24gc2Vzc2lvbnMsaW5jbHVkaW5nIFBTVE48L3NwYW4+PC90dD48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cD4mcXVvdDsuLi5zZXNzaW9ucywgaW5jbHVkaW5nLi4uJnF1b3Q7PG86cD48L286 cD48L3A+DQo8cD4oc3BhY2UgYWZ0ZXIgY29tbWEpPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBjYWxscy4mbmJzcDsgSG93ZXZlciwgdGhl IFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBjb3VsZCBiZTwvc3Bhbj48L3R0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHNwb29mZWQgYW5kIGFidXNlZCBieSB1 bmF1dGhvcml6ZWQgZW50aXRpZXMuPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRo ZSBTVElSIGFyY2hpdGVjdHVyZSBbUkZDNzM0MF1hc3N1bWVzIHRoYXQgYW4gYXV0aG9yaXR5IG9u IHRoZTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5TVElSIGFyY2hpdGVjdHVyZSBbUkZDNzM0MF0g YXNzdW1lcy4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+KHNwYWNlIGJlZm9yZSAmcXVvdDth c3N1bWVzJnF1b3Q7KTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mbmJzcDsmbmJzcDsgb3JpZ2luYXRpbmcgc2lkZSBvZiBhIGNhbGwgcHJvdmlkZXMgYSBjcnlw dG9ncmFwaGljIGFzc3VyYW5jZSBvZiB0aGU8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyB2YWxpZGl0eSBvZiB0aGUgY2FsbGluZyBwYXJ0eSBudW1iZXIgaW4gb3Jk ZXIgdG8gcHJldmVudDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpbXBlcnNvbmF0aW9uIGF0 dGFja3MuJm5ic3A7IFRoZSBTVElSIGFyY2hpdGVjdHVyZSBhbGxvd3MgZXh0ZW5zaW9uIHRoYXQ8 L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uYWxsb3dzIGV4dGVuc2lvbnMuLi4mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGNhbiBi ZSB1dGlsaXplZCBieSBhdXRob3JpdGllcyBzdXBwb3J0aW5nIHJlYWwtdGltZSBjb21tdW5pY2F0 aW9uPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgc2VydmljZXMg dXNpbmcgdGhlICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIHRvPC90dD48YnI+DQo8 dHQ+Jm5ic3A7Jm5ic3A7IGNyeXB0b2dyYXBoaWNhbGx5IHNpZ24gdGhlIFNJUCAnUmVzb3VyY2Ut UHJpb3JpdHknIGhlYWRlciBmaWVsZCBhbmQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgY29u dmV5IGFzc2VydGlvbiBvZiB0aGUgYXV0aG9yaXphdGlvbiBmb3IgJ1Jlc291cmNlLVByaW9yaXR5 Jy4mbmJzcDsgRm9yPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGV4YW1wbGUsIHRoZSBhdXRo b3JpdHkgb24gdGhlIG9yaWdpbmF0aW5nIHNpZGUgdmVyaWZ5aW5nIHRoZTwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBhdXRob3JpemF0aW9uIG9mIGEgcGFydGljdWxhciBjb21tdW5pY2F0aW9u IGZvciBSZXNvdXJjZS1Qcmlvcml0eSBjYW48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+U2luZ2xlIHF1b3RlcyBh cm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IHVzZSBhIFBBU1NQb3JUIGNsYWltIHRvIGNyeXB0 b2dyYXBoaWNhbGx5LXNpZ24gdGhlIFNJUCAnUmVzb3VyY2UtPC9zcGFuPjwvdHQ+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90 Oy4uLmNyeXB0b2dyYXBoaWNhbGx5IHNpZ24uLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFByaW9yaXR5JyBoZWFkZXIgZmll bGQgYW5kIGNvbnZleSBhbiBhc3NlcnRpb24gb2YgdGhlIGF1dGhvcml6YXRpb248L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBmb3IgJ1Jlc291cmNlLVByaW9yaXR5 Jy4mbmJzcDsgVGhpcyB3aWxsIGFsbG93IGEgcmVjZWl2aW5nIGVudGl0eTwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyAoaW5jbHVkaW5nIGVudGl0aWVzIGxvY2F0ZWQgaW4gZGlmZmVyZW50IG5l dHdvcmsgZG9tYWlucy9ib3VuZGFyaWVzKTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB0byB2 ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIGFzc2VydGlvbnMgYXV0aG9yaXppbmcgUmVzb3VyY2UtUHJp b3JpdHkuPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmdsZSBxdW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlv cml0eScuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNw OyZuYnNwOyBDcnlwdG9ncmFwaGljYWxseS1zaWduZWQgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScg aGVhZGVycyB3aWxsIGFsbG93IGE8L3NwYW4+PC90dD48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uY3J5cHRvZ3JhcGhp Y2FsbHkgc2lnbmVkIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZHMuLi4mcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwPihyZW1vdmUgaHlwaGVuLCBhbmQgcmVwbGFjZSAmcXVvdDto ZWFkZXJzJnF1b3Q7IHdpdGggJnF1b3Q7aGVhZGVyIGZpZWxkcyZxdW90Oyk8bzpwPjwvbzpwPjwv cD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IHJlY2VpdmluZyBl bnRpdHkgdG8gdmVyaWZ5IGFuZCBhY3Qgb24gdGhlIGluZm9ybWF0aW9uIHdpdGggY29uZmlkZW5j ZTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIGlu Zm9ybWF0aW9uIGhhdmUgbm90IGJlZW4gc3Bvb2ZlZCBvciBjb21wcm9taXNlZC48L3R0Pjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHA+JnF1b3Q7Li4uaGFzIG5vdCBiZWVuIHNwb29mZWQgb3IgY29tcHJvbWlzZWQuJnF1b3Q7 PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmlj YXRpb24gZG9jdW1lbnRzIGFuIG9wdGlvbmFsIGV4dGVuc2lvbiB0byBQQVNTcG9yVCBhbmQ8L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgdGhlIGFzc29jaWF0ZWQgU1RJUiBtZWNoYW5pc21zIHRv IHByb3ZpZGUgYSBmdW5jdGlvbiB0byBzaWduIHRoZSBTSVA8L3R0Pjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQuJm5ic3A7IFRoaXMgUEFTU3Bv clQgb2JqZWN0IGlzIHVzZWQgdG88L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgcHJvdmlkZSBh dHRlc3RhdGlvbiBvZiBhIGNhbGxpbmcgdXNlciBhdXRob3JpemF0aW9uIGZvciBwcmlvcml0eTwv dHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9ucy4mbmJzcDsgVGhpcyBpcyBu ZWNlc3NhcnkgaW4gYWRkaXRpb24gdG8gdGhlIFBBU1Nwb3JUIG9iamVjdDwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyB0aGF0IGlzIHVzZWQgZm9yIGNhbGxpbmcgdXNlciB0ZWxlcGhvbmUgbnVt YmVyIGF0dGVzdGF0aW9uLiZuYnNwOyBIb3cgdGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IG9wdGlvbmFsIGV4dGVuc2lvbiB0byBQQVNTcG9yVCBpcyB1c2VkIGZvciByZWFsLXRpbWUgY29t bXVuaWNhdGlvbnM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgc3VwcG9ydGVkIHVzaW5nIFNJ UCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBpcyBkZWZpbmVkIGluPC90dD48YnI+ DQo8dHQ+Jm5ic3A7Jm5ic3A7IG90aGVyIGRvY3VtZW50cyBhbmQgaXMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+SSBhc3N1bWUgdGhlc2Ugb3RoZXIg ZG9jdW1lbnRzIGFyZSB1bmRlciBkZXZlbG9wbWVudD8gSWYgc28sIHRoZXkgc2hvdWxkIGJlIGNp dGVkIGhlcmUuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PjIuJm5ic3A7IFRlcm1pbm9s b2d5PC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSBrZXkgd29yZHMgJnF1b3Q7 TVVTVCZxdW90OywgJnF1b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1b3Q7LCAm cXVvdDtTSEFMTCZxdW90OywgJnF1b3Q7U0hBTEwgTk9UJnF1b3Q7LDwvdHQ+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyAmcXVvdDtTSE9VTEQmcXVvdDssICZxdW90O1NIT1VMRCBOT1QmcXVvdDssICZx dW90O1JFQ09NTUVOREVEJnF1b3Q7LCAmcXVvdDtNQVkmcXVvdDssIGFuZCAmcXVvdDtPUFRJT05B TCZxdW90OyBpbiB0aGlzPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50IGFyZSB0 byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JGQzIxMTldLjwvdHQ+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cD5UaGlzIGRvY3VtZW50IGhhcyBzZXZlcmFsIG5vbi1ub3JtYXRpdmUgdXNlcyBv ZiAmcXVvdDttdXN0JnF1b3Q7LCAmcXVvdDtzaG91bGQsJnF1b3Q7IGFuZCAmcXVvdDttYXksJnF1 b3Q7IGFuZCBzbyBpdCBuZWVkcyB0byB1c2UgdGhlIFJGQzgxNzQgYm9pbGVycGxhdGUgaW5zdGVh ZCBvZiB0aGUgUkZDMjExOSBib2lsZXJwbGF0ZS48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8 dHQ+My4mbmJzcDsgUEFTU3BvclQgJ3JwaCcgQ2xhaW08L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSBuZXcgSlNPTiBXZWIgVG9rZW4g Y2xhaW0gZm9yICZxdW90O3JwaCZxdW90Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgd2hp Y2ggcHJvdmlkZXMgYW4gYXNzZXJ0aW9uIGZvciBpbmZvcm1hdGlvbiBpbiBTSVAgJ1Jlc291cmNl LTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBQcmlvcml0eSdoZWFkZXIuPC90dD48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPiZxdW90Oy4uLlByaW9yaXR5JyBoZWFkZXIgZmllbGQuJnF1b3Q7PG86cD48L286cD48L3A+ DQo8cD4oc3BhY2UgYWZ0ZXIgY2xvc2luZyBxdW90YXRpb24gbWFyaywgJnF1b3Q7aGVhZGVyIGZp ZWxkJnF1b3Q7IGluc3RlYWQgb2YgJnF1b3Q7aGVhZGVyJnF1b3Q7KTxvOnA+PC9vOnA+PC9wPg0K PHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIGNyZWF0b3Igb2YgYSBQQVNTcG9yVCBvYmpl Y3QgYWRkcyBhICZxdW90O3BwdCZxdW90OyB2YWx1ZSBvZiAmcXVvdDtycGgmcXVvdDsgdG8gdGhl PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGhlYWRlciBvZiBhIFBBU1Nwb3JUIG9iamVjdCwg aW4gd2hpY2ggY2FzZSB0aGUgUEFTU3BvclQgY2xhaW1zIE1VU1Q8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgY29udGFpbiBhICZxdW90O3JwaCZxdW90OyBjbGFpbSwgYW5kIGFueSBlbnRpdGll cyB2ZXJpZnlpbmcgdGhlIFBBU1Nwb3JUIG9iamVjdDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyB3aWxsIGJlIHJlcXVpcmVkIHRvIHVuZGVyc3RhbmQgdGhlICZxdW90O3BwdCZxdW90OyBleHRl bnNpb24gaW4gb3JkZXIgdG88L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgcHJvY2VzcyB0aGUg UEFTU3BvclQgaW4gcXVlc3Rpb24uJm5ic3A7IEEgUEFTU1BvclQgaGVhZGVyIHdpdGggdGhlICZx dW90O3BwdCZxdW90OzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpbmNsdWRlZCB3aWxsIGxv b2sgYXMgZm9sbG93czo8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgeyZuYnNwOyAm cXVvdDt0eXAmcXVvdDs6JnF1b3Q7cGFzc3BvcnQmcXVvdDssPC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O3BwdCZxdW90OzomcXVvdDtycGgmcXVvdDssPC90dD48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2FsZyZxdW90OzomcXVvdDtF UzI1NiZxdW90Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 eDV1JnF1b3Q7OjwvdHQ+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2Nl cnQuY2VyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZxdW90O2h0dHBzOi8vd3d3LmV4YW1w bGUub3JnL2NlcnQuY2VyJnF1b3Q7PC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPn08L3NwYW4+PC90dD48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+SWRlYWxseSwgdGhpcyB3b3VsZCBiZSBlaXRoZXIg cHJldHR5LXByaW50ZWQgb3IgY2Fub25pY2FsaXplZC4gU2luY2UgaXQncyB0b28gbG9uZyB0byBm aXQgb24gYSBsaW5lIGluIGNhbm9uaWNhbCBmb3JtLCBJIHByb3Bvc2U6PG86cD48L286cD48L3A+ DQo8cD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPns8L3NwYW4+PC90dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGJyPg0KPHR0PiZuYnNwOyAmcXVvdDt0eXAmcXVvdDs6JnF1b3Q7cGFzc3BvcnQmcXVv dDssPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZxdW90O3BwdCZxdW90OzomcXVvdDtycGgmcXVvdDss PC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZxdW90O2FsZyZxdW90OzomcXVvdDtFUzI1NiZxdW90Oyw8 L3R0Pjxicj4NCjx0dD4mbmJzcDsgJnF1b3Q7eDV1JnF1b3Q7OjwvdHQ+PC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZxdW90O2h0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyJnF1b3Q7PC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PGJyPg0KPHR0Pn08L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSAmcXVvdDtycGgmcXVvdDsgY2xhaW0gd2lsbCBwcm92 aWRlIGFuIGFzc2VydGlvbiBvZiBhdXRob3JpemF0aW9uLCZxdW90O2F1dGgmcXVvdDssPC90dD48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwPiZxdW90Oy4uLmF1dGhvcml6YXRpb24sICZxdW90O2F1dGgmcXVvdDssIC4uLiZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+KHNwYWNlIGJldHdlZW4gY29tbWEgYW5kIG9wZW5pbmcg cXVvdGF0aW9uIG1hcmspPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZuYnNwOyZuYnNwOyBmb3IgaW5mb3JtYXRpb24gaW4gdGhlIFNJUCAmcXVvdDtSZXNvdXJj ZS1Qcmlvcml0eSZxdW90OyBoZWFkZXIgZmllbGQgKGkuZS4sPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgUmVzb3VyY2UtUHJpb3JpdHk6IG5hbWVzcGFjZSAmcXVv dDsuJnF1b3Q7IHItcHJpb3JpdHkpIGJhc2VkIG9uIFtSRkM0NDEyXS48L3R0Pjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+ VGhlIHVzZSBvZiB0aGUgc3RyaW5nICduYW1lc3BhY2UgJnF1b3Q7LiZxdW90OyByLXByaW9yaXR5 JyBoZXJlIGFuZCBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50IGhhcyBhIGRldHJpbWVudGFsIGlt cGFjdCBvbiByZWFkYWJpbGl0eS4gSSBzdHJvbmdseSBzdWdnZXN0IHJlcGxhY2luZyBpdCB3aXRo ICZxdW90O3ItdmFsdWUmcXVvdDsgKHRoZSBuYW1lIG9mIHRoaXMgcHJvZHVjdGlvbiBpbiBSRkM0 NDEyKSBldmVyeXdoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mbmJzcDsmbmJzcDsgU3BlY2lmaWNhbGx5LCB0aGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWlt IGluY2x1ZGVzIGFzc2VydGlvbiBvZiB0aGUgcHJpb3JpdHktPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgbGV2ZWwgb2YgdGhlIHVzZXIgdG8gYmUgdXNlZCBmb3Ig YSBnaXZlbiBjb21tdW5pY2F0aW9uIHNlc3Npb24uJm5ic3A7IFRoZTwvdHQ+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyB2YWx1ZSBvZiB0aGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIGlzIGFuIGFycmF5 IGNvbnRhaW5pbmcgb25lIG9yIG1vcmUgb2YgSlNPTjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyBvYmplY3RzIGZvciB0aGUgY29udGVudCBvZiB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScg aGVhZGVyIHRoYXQgaXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYmVpbmcgYXNzZXJ0ZWQg b2Ygd2hpY2ggb25lIG9mIHRoZSAmcXVvdDtycGgmcXVvdDsgb2JqZWN0LCBpcyBtYW5kYXRvcnku PC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwPlRoaXMgbGFzdCBzZW50ZW5jZSBpcyB2ZXJ5IGhhcmQgdG8gcGFyc2U7 IGFuZCAoYmFzZWQgb24gdGhlIGV4YW1wbGUpIHRoZSB2YWx1ZSBpcyBpbnRlbmRlZCB0byBiZSBh IEpTT04gT2JqZWN0IChjdXJseSBicmFjZXMpIHJhdGhlciB0aGFuIGEgSlNPTiBBcnJheSAoc3F1 YXJlIGJyYWNlcykuIEkgc3VnZ2VzdDogJ1RoZSB2YWx1ZSBvZiB0aGUgJnF1b3Q7cnBoJnF1b3Q7 IGNsYWltIGlzIGFuIE9iamVjdCB3aXRoIG9uZSBvciBtb3JlIGtleXMuIEVhY2gga2V5DQogaXMg YXNzb2NpYXRlZCB3aXRoIGEgSlNPTiBBcnJheS4gVGhlc2UgYXJyYXlzIGNvbnRhaW4gU3RyaW5n cyB0aGF0IGNvcnJlc3BvbmQgdG8gdGhlIHItdmFsdWVzIGluZGljYXRlZCBpbiB0aGUgU0lQICZx dW90O1Jlc291cmNlLVByaW9yaXR5JnF1b3Q7IGhlYWRlciBmaWVsZC4nIChub3RlOiAmcXVvdDto ZWFkZXIgZmllbGQmcXVvdDssIG5vdCAmcXVvdDtoZWFkZXImcXVvdDspPG86cD48L286cD48L3A+ DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGUgZm9sbG93aW5nIGlzIGFuIGV4YW1wbGUg JnF1b3Q7cnBoJnF1b3Q7IGNsYWltIGZvciBhIFNJUCAmcXVvdDtSZXNvdXJjZS1Qcmlvcml0eSZx dW90OzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBoZWFkZXIgZmllbGQgd2l0aCBhICZxdW90 O25hbWVzcGFjZSAmcXVvdDsuJnF1b3Q7IHItcHJpb3JpdHkmcXVvdDsgdmFsdWUgb2YgJnF1b3Q7 ZXRzLjAmcXVvdDsgYW5kPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHdpdGggYSAmcXVvdDtu YW1lc3BhY2UgJnF1b3Q7LiZxdW90OyByLXByaW9yaXR5JnF1b3Q7IHZhbHVlIG9mICZxdW90O3dw cy4wJnF1b3Q7LjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyB7ICZxdW90 O29yaWcmcXVvdDs6eyZxdW90O3RuJnF1b3Q7OiZxdW90OzwvdHQ+PC9zcGFuPjxhIGhyZWY9InRl bDooMjE1KSUyMDU1NS0xMjEyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEyMTU1NTUxMjEy PC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90O308L3Nw YW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVv dDtkZXN0JnF1b3Q7OntbJnF1b3Q7dG4mcXVvdDs6JnF1b3Q7PC90dD48L3NwYW4+PGEgaHJlZj0i dGVsOigyMTIpJTIwNTU1LTEyMTMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+MTIxMjU1NTEy MTM8L3NwYW4+PC9hPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+JnF1b3Q7XX0s PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JnF1b3Q7aWF0JnF1b3Q7OjE0NDMyMDgzNDUsPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O3JwaCZxdW90Ozp7JnF1b3Q7YXV0aCZxdW90OzpbJnF1b3Q7ZXRzLjAm cXVvdDssJnF1b3Q7d3BzLjAmcXVvdDtdfTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5BcyBhYm92ZSwgSSByZWNv bW1lbmQgcHJldHR5LXByaW50aW5nIHRoaXMuIEl0J3MgYWxzbyBtaXNzaW5nIGEgY29tbWEgYWZ0 ZXIgdGhlICZxdW90O29yaWcmcXVvdDsgdmFsdWUsIGFuZCB0aGUgdG9wLWxldmVsIHN0cnVjdHVy ZSBpcyBtaXNzaW5nIGEgY2xvc2luZyBicmFjZS4gVGhlIHZhbHVlIGZvciAmcXVvdDtpYXQmcXVv dDsgbmVlZHMgdG8gYmUgZW5jbG9zZWQgaW4gcXVvdGVzLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhl IE5BTlBBIGhhcyBhbGxvY2F0ZWQgTlBBNTU1MDF4eCBmb3IgZXhhbXBsZSB1c2UsIG5vdCBOUEE1 NTV4eHh4LCBtdWNoIG9mIHdoaWNoIHJlbWFpbnMgYXNzaWduYWJsZSAoY2YNCjxhIGhyZWY9Imh0 dHBzOi8vd3d3Lm5hdGlvbmFsbmFucGEuY29tL3BkZi9OUlVGL0FUSVMtMDMwMDExNS5wZGYiIHRh cmdldD0iX2JsYW5rIj4NCiZsdDtodHRwczovL3d3dy5uYXRpb25hbG5hbnBhLmNvbS9wZGYvTlJV Ri9BVElTLTAzMDAxMTUucGRmJmd0OzwvYT4pLjxvOnA+PC9vOnA+PC9wPg0KPHA+UHV0dGluZyBh bGwgdGhpcyB0b2dldGhlciwgSSBiZWxpZXZlIHdoYXQgeW91IHdhbnQgaXM6PG86cD48L286cD48 L3A+DQo8cD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPns8L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyAmcXVvdDtvcmlnJnF1b3Q7OnsmcXVvdDt0biZxdW90 OzomcXVvdDs8L3R0Pjwvc3Bhbj48YSBocmVmPSJ0ZWw6KDIxNSklMjA1NTUtMDExMiIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xMjE1NTU1MDExMjwvc3Bhbj48L2E+PHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mcXVvdDt9LDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8 dHQ+Jm5ic3A7ICZxdW90O2Rlc3QmcXVvdDs6e1smcXVvdDt0biZxdW90OzomcXVvdDs8L3R0Pjwv c3Bhbj48YSBocmVmPSJ0ZWw6KDIxMiklMjA1NTUtMDExMyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4xMjEyNTU1MDExMzwvc3Bhbj48L2E+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mcXVvdDtdfSw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyAmcXVv dDtpYXQmcXVvdDs6JnF1b3Q7MTQ0MzIwODM0NSZxdW90Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsg JnF1b3Q7cnBoJnF1b3Q7OnsmcXVvdDthdXRoJnF1b3Q7OlsmcXVvdDtldHMuMCZxdW90OywmcXVv dDt3cHMuMCZxdW90O119PC90dD48YnI+DQo8dHQ+fTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgQWZ0ZXIgdGhlIGhlYWRlciBhbmQgY2xhaW1z IFBBU1Nwb3JUIG9iamVjdHMgaGF2ZSBiZWVuIGNvbnN0cnVjdGVkLDwvdHQ+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyB0aGVpciBzaWduYXR1cmUgaXMgZ2VuZXJhdGVkIG5vcm1hbGx5IHBlciB0aGUg Z3VpZGFuY2UgaW48L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgW0ktRC5pZXRmLXN0aXItcGFz c3BvcnRdIHVzaW5nIHRoZSBmdWxsIGZvcm0gb2YgUEFTU1BvclQuJm5ic3A7IFRoZTwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyBjcmVkZW50aWFscyAoZS5nLiwgYXV0aG9yaXR5IHJlc3BvbnNp YmxlIGZvciBhdXRob3JpemluZyBSZXNvdXJjZS08L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsg UHJpb3JpdHkpIHVzZWQgdG8gY3JlYXRlIHRoZSBzaWduYXR1cmUgbXVzdCBoYXZlIGF1dGhvcml0 eSBvdmVyIHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyAmcXVvdDtycGgmcXVvdDsgY2xh aW0gYW5kIHRoZXJlIGlzIG9ubHkgb25lIGF1dGhvcml0eSBwZXIgY2xhaW0uJm5ic3A7IFRoZSBh dXRob3JpdHk8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgTVVTVCB1c2UgaXRzIGNyZWRlbnRp YWxzIChpLmUuLCBDRVJUKSBhc3NvY2lhdGVkIHdpdGggdGhlIHNwZWNpZmljPC90dD48YnI+DQo8 dHQ+Jm5ic3A7Jm5ic3A7IHNlcnZpY2Ugc3VwcG9ydGVkIGJ5IHRoZSBTSVAgbmFtZXNwYWNlIGlu IHRoZSBjbGFpbS48L3R0Pjxicj4NCjxicj4NCjx0dD40LiZuYnNwOyAncnBoJyBpbiBTSVA8L3R0 Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhpcyBzZWN0aW9uIHNwZWNpZmllcyBTSVAt c3BlY2lmaWMgdXNhZ2UgZm9yIHRoZSAmcXVvdDtycGgmcXVvdDsgY2xhaW0gaW48L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgUEFTU3BvclQuPC90dD48YnI+DQo8YnI+DQo8dHQ+NC4xLiZuYnNw OyBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIEJlaGF2aW9yPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5i c3A7Jm5ic3A7IFRoZSBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIHdpbGwgY3JlYXRlIHRoZSAmcXVv dDtycGgmcXVvdDsgY2xhaW0gdXNpbmcgdGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHZh bHVlcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiAzIGJhc2VkIG9uIFtSRkM0NDEyXS4mbmJzcDsgVGhl IGNvbnN0cnVjdGlvbjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBvZiAmcXVvdDtycGgmcXVv dDsgY2xhaW0gZm9sbG93cyB0aGUgc3RlcHMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBvZjwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBbSS1ELmlldGYtc3Rpci1yZmM0NDc0YmlzXS48L3R0Pjxi cj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIHJlc3VsdGluZyBJZGVudGl0eSBoZWFkZXIg Zm9yICZxdW90O3JwaCZxdW90OyBtaWdodCBsb29rIGFzIGZvbGxvd3M6PC90dD48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw PiZxdW90Oy4uLmhlYWRlciBmaWVsZC4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgJnF1b3Q7ZXlKaGJHY2lPaUpGVXpJMU5pSXNJblI1Y0NJNklrcFhW Q0o5LmV5SnBjM01pT2lKbGVVb3daVmhCYVU5cFNuZDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyBaV0U1NlkwYzVlV1JEU1hORVVXOXBZMGhDTUVscWIybGpia0p2U1dsM1RrTnBTbWhpUjJOcFQy bEtSbFY2U1RGTzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBhVWx6UkZGdmFXVkVWakZKYW5C dlpFaFNkMk42YjNaTU0yUXpaSGsxYkdWSFJuUmpSM2hzVEcxT2RtSlRPV3BhVzwvdHQ+PGJyPg0K PHR0PiZuYnNwOyZuYnNwOyBFb3dURzFPYkdOdU1FNURaekJMSUh4ODRvQ1pMdUtBbVh4OElHVjVR V2xpTTBwd1dubEpObVY1U2pCaWFVazJTVzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBwRmVV MVVWVEZPVkZWNFRXcEZlVWx1TUU1RGFVcHJXbGhPTUVscWNEZFhlVW93WW1sSk5rbHFSWGxOVkVr eFRsUjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBWZUUxcVJYcEpiREU1VEVFd1MwbHRiR2hr UTBrMlRWUlJNRTE2U1hkUFJFMHdUbE4zVGtOcFNubGpSMmRwVDI1ejwvdHQ+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyBhVmxZVmpCaFEwazJWM2xLYkdSSVRYVk5RMGx6U1c1a2QyTjVOSGRKYkRFNVJG RnZQU0o5LnMzN1M2VkM4SE02RDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBsNll6SmVRRHNy WmN3SjBsaXp4aFVyQTdmXzk4b1dCSHZvLWNsLW44TUlob0NyMTh2WVlGeTNibFh2czNmc2xNXzwv dHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBvb3MyUDJEeXcmcXVvdDs7IGluZm89IDwvdHQ+PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZxdW90O2h0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyJnF1 b3Q7PC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjthbGc9RVMy NTY7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgcHB0PSZxdW90 O3JwaCZxdW90OzwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5UaGlzIGV4YW1wbGUgaGFzIGEgbnVtYmVyIG9mIGlz c3Vlczo8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPg0KSW4gdGhlIElkZW50aXR5IGhlYWRlciBm aWVsZCwgdGhlIHNpZ25lZC1pZGVudGl0eS1kaWdlc3Qgc2hvdWxkbid0IGJlIHF1b3RlZC48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZv NiI+DQpJbiB0aGUgSWRlbnRpdHkgaGVhZGVyIGZpZWxkLCBpbmZvIGlzIGVuY2xvc2VkIGluICZs dDsmZ3Q7IHJhdGhlciB0aGFuICZxdW90OyZxdW90Oy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+DQpJbiB0aGUgSWRlbnRpdHkg aGVhZGVyIGZpZWxkLCBwcHQgaXMgYSB0b2tlbiByYXRoZXIgdGhhbiBhIHF1b3RlZCBzdHJpbmcu PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwx IGxmbzYiPg0KVGhlIHNpZ25lZC1pZGVudGl0eS1kaWdlc3QgaGVhZGVyIG5lZWRzIHRvIGluZGlj YXRlIGEgJnF1b3Q7dHlwJnF1b3Q7IG9mICZxdW90O3Bhc3Nwb3J0JnF1b3Q7IHJhdGhlciB0aGFu IEpXVCwgYW5kIGl0IG5lZWRzIHRvIGluY2x1ZGUgYm90aCBhICZxdW90O3BwdCZxdW90OyBhbmQg JnF1b3Q7eDV1JnF1b3Q7IGZpZWxkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwzIGxldmVsMSBsZm82Ij4NClRoZSBzaWduZWQtaWRlbnRpdHktZGlnZXN0 IGJvZHkgc2hvdWxkIGNvbnRhaW4gb25seSB0aGUgcGFzc3BvcnQgY2xhaW0gcmF0aGVyIHRoYW4g YSBKU09OIG9iamVjdCB0aGF0IGl0c2VsZiBjb250YWlucyBhIGJhc2U2NC1lbmNvZGVkIEpXUyBo ZWFkZXIgY29uY2F0ZW5hdGVkIHdpdGggYSBjbGFpbS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+DQpJIGJlbGlldmUgdGhhdCwg ZXZlbiB3aGVuIHRoZSBib2R5IGlzIGluY2x1ZGVkLCB2YWx1ZXMgaW4gdGhlIGhlYWRlciBhbmQg Ym9keSBuZWVkIHRvIGJlIGJlIGNhbm9uaWNhbGl6ZWQgKGkuZS4sIGFsbCBvbiBvbmUgbGluZSwg bm8gc3BhY2VzLCBpbiBhbHBoYWJldGljYWwgb3JkZXIsIGV0Yy4pPG86cD48L286cD48L2xpPjwv dWw+DQo8cD5JIHdvdWxkIGFsc28gcmVjb21tZW5kIGZvbGxvd2luZyB0aGUgY29udmVudGlvbiBv ZiBpbmRpY2F0aW5nIHRoYXQgbGluZS13cmFwcyBhcmUgb25seSBmb3IgcmVhZGFiaWxpdHksIGFu ZCBpbmNsdWRpbmcgdGhlIGhlYWRlciBmaWVsZCBuYW1lIGluIHRoZSBleGFtcGxlLiBQdXR0aW5n IGFsbCB0aGlzIHRvZ2V0aGVyLCBJIGJlbGlldmUgd2hhdCB5b3Ugd2FudCBpczo8bzpwPjwvbzpw PjwvcD4NCjxwPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7 IEZvciBleGFtcGxlLCBhIElkZW50aXR5IGhlYWRlciBmaWVsZCBmb3IgJnF1b3Q7cnBoJnF1b3Q7 IG1pZ2h0IGxvb2s8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBh cyBmb2xsb3dzIChiYWNrc2xhc2hlcyBzaG93biBmb3IgbGluZSBmb2xkaW5nIG9ubHkpOjwvdHQ+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mbmJzcDsmbmJzcDsgSWRlbnRpdHk6IGV5SmhiR2NpT2lKRlV6STFOaUlzSW5Cd2RDSTZJ bkp3YUNJc0luUjVjQ0k2SW5CaGMzTndiM0owSSBcPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgaXdpZURWMUlqb2lhSFIwY0hNNkx5OTNkM2N1WlhoaGJYQnNaUzVq YjIwdlkyVnlkQzVqWlhJaWZRby5leUprWlhOMCBcPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IElqcDdXeUowYmlJNklqRXlNVEkxTlRVd01URXpJbDE5TENKcFlYUWlPaUl4TkRRek1qQTRNelEx SWl3aWIzSnBaeUkgXDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyA2ZXlKMGJpSTZJakV5TVRV MU5UVXdNVEV5SW4wc0luSndhQ0k2ZXlKaGRYUm9JanBiSW1WMGN5NHdJaXdpZDNCekxqIFw8L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgQWlYWDE5Q2cuczM3UzZWQzhITTZEbDZZekplUURzclpj d0owbGl6eGhVckE3Zl85OG9XQkh2by1jbC1uOE1JaG9DciBcPC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IDE4dllZRnkzYmxYdnMzZnNsTV9vb3MyUDJEeXc7aW5mbz0mbHQ7PC90dD48L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXIiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+aHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXI8L3NwYW4+PC9hPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IFw8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyAmZ3Q7O2FsZz1FUzI1NjtwcHQ9cnBoPC90dD48YnI+DQo8 L3NwYW4+PGJyPg0KKE5vdGU6IHRoaXMgZXhhbXBsZSBhc3N1bWVzIHRoZSBjYWxsaW5nIGFuZCBj YWxsZWQgcGFydHkgbnVtYmVycyBpbiB0aGUgcHJldmlvdXMgZXhhbXBsZSBhcmUgY2hhbmdlZCB0 bw0KPGEgaHJlZj0idGVsOigyMTUpJTIwNTU1LTAxMTIiIHRhcmdldD0iX2JsYW5rIj4xMjE1NTU1 MDExMjwvYT4gYW5kIDxhIGhyZWY9InRlbDooMjE1KSUyMDU1NS0wMTEzIiB0YXJnZXQ9Il9ibGFu ayI+DQoxMjE1NTU1MDExMzwvYT4sIHJlc3BlY3RpdmVseSk8bzpwPjwvbzpwPjwvcD4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IEEgU0lQIGF1dGhlbnRpY2F0aW9uIHNlcnZpY2UgdHlwaWNh bGx5IHdpbGwgZGVyaXZlIHRoZSB2YWx1ZSBvZiAmcXVvdDtycGgmcXVvdDs8L3R0Pjxicj4NCjx0 dD4mbmJzcDsmbmJzcDsgZnJvbSB0aGUgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQg YmFzZWQgb24gcG9saWN5IGFzc29jaWF0ZWQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgd2l0 aCBzZXJ2aWNlIHNwZWNpZmljIHVzZSBvZiB0aGUgJnF1b3Q7bmFtZXNwYWNlICZxdW90Oy4mcXVv dDsgci1wcmlvcml0eSZxdW90OyB2YWx1ZXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYmFz ZWQgb24gW1JGQzQ0MTJdLiZuYnNwOyBUaGUgYXV0aGVudGljYXRpb24gc2VydmljZSBkZXJpdmVz IHRoZSB2YWx1ZSBvZjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB0aGUgUEFTU1BvclQgY2xh aW0gYnkgdmVyaWZ5aW5nIHRoZSBhdXRob3JpemF0aW9uIGZvciBSZXNvdXJjZS08L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgUHJpb3JpdHkgKGkuZS4sIHZlcmlmeWluZyBhIGNhbGxpbmcgdXNl ciBwcml2aWxlZ2UgZm9yIFJlc291cmNlLTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBQcmlv cml0eSBiYXNlZCBvbiBpdHMgaWRlbnRpdHkpIHdoaWNoIG1pZ2h0IGJlIGRlcml2ZWQgZnJvbSBj dXN0b21lcjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBwcm9maWxlIGRhdGEgb3IgZnJvbSBh Y2Nlc3MgdG8gZXh0ZXJuYWwgc2VydmljZXMuPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IFtSRkM0NDEyXSBhbGxvd3MgbXVsdGlwbGUgJnF1b3Q7bmFtZXNwYWNlICZxdW90Oy4mcXVv dDsgci1wcmlvcml0eSZxdW90OyBwYWlycywgZWl0aGVyIGluPC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IGEgc2luZ2xlIFNJUCBSZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXIgb3IgYWNyb3NzIG11 bHRpcGxlIFNJUDwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5TaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2Ut UHJpb3JpdHknLjxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uaGVhZGVyIGZpZWxkLi4uJnF1 b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZu YnNwOyBSZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXJzLiZuYnNwOyBIb3dldmVyLCBpdCBpcyBub3Qg bmVjZXNzYXJ5IHRvIHNpZ24gYWxsPC9zcGFuPjwvdHQ+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmdsZSBxdW90ZXMgYXJvdW5k ICdSZXNvdXJjZS1Qcmlvcml0eScuPG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5oZWFkZXIg ZmllbGRzLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZuYnNwOyZuYnNwOyBjb250ZW50IG9mIGEgU0lQIFJlc291cmNlLVByaW9yaXR5IGhlYWRl ciBvciBhbGwgU0lQIFJlc291cmNlLTwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5TaW5nbGUgcXVvdGVzIGFyb3Vu ZCAnUmVzb3VyY2UtUHJpb3JpdHknLjxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uaGVhZGVy IGZpZWxkLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZuYnNwOyZuYnNwOyBQcmlvcml0eSBoZWFkZXJzIGluIGEgZ2l2ZW4gU0lQIG1lc3NhZ2Uu Jm5ic3A7IEFuIGF1dGhvcml0eSBpcyBvbmx5PC9zcGFuPjwvdHQ+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmdsZSBxdW90ZXMg YXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScuPG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5o ZWFkZXIgZmllbGRzLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyByZXNwb25zaWJsZSBmb3Igc2lnbmluZyB0aGUgY29udGVu dCBvZiBhIFNJUCBSZXNvdXJjZS1Qcmlvcml0eSBoZWFkZXI8L3NwYW4+PC90dD48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+U2luZ2xl IHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpwPjwvcD4NCjxwPiZx dW90Oy4uLmhlYWRlciBmaWVsZC4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgZm9yIHdoaWNoIGl0IGhhcyBhdXRob3JpdHkg KGUuZy4sIGEgc3BlY2lmaWMgJnF1b3Q7bmFtZXNwYWNlICZxdW90Oy4mcXVvdDs8L3NwYW4+PC90 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyByLXByaW9yaXR5JnF1b3Q7KS48L3R0 Pjxicj4NCjxicj4NCjx0dD40LjIuJm5ic3A7IFZlcmlmaWNhdGlvbiBTZXJ2aWNlIEJlaGF2aW9y PC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRi aXNdIFNlY3Rpb24gNi4yIFN0ZXAgNSByZXF1aXJlcyB0aGF0PC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IHNwZWNpZmljYXRpb25zIGRlZmluaW5nICZxdW90O3BwdCZxdW90OyB2YWx1ZXMgZGVz Y3JpYmUgYW55IGFkZGl0aW9uYWwgdmVyaWZpZXI8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsg YmVoYXZpb3IuJm5ic3A7IFRoZSBiZWhhdmlvciBzcGVjaWZpZWQgZm9yIHRoZSAmcXVvdDtwcHQm cXVvdDsgdmFsdWVzIG9mICZxdW90O3JwaCZxdW90OyBpcyBhczwvdHQ+PGJyPg0KPHR0PiZuYnNw OyZuYnNwOyBmb2xsb3dzOjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGUgdmVy aWZpY2F0aW9uIHNlcnZpY2UgTVVTVCBleHRyYWN0IHRoZSB2YWx1ZSBhc3NvY2lhdGVkIHdpdGgg dGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7ICZxdW90O2F1dGgmcXVvdDsga2V5IGluIGEg ZnVsbCBmb3JtIFBBU1NQb3JUIHdpdGggYSAmcXVvdDtwcHQmcXVvdDsgdmFsdWUgb2YgJnF1b3Q7 cnBoJnF1b3Q7LiZuYnNwOyBJZjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB0aGUgc2lnbmF0 dXJlIHZhbGlkYXRlcywgdGhlbiB0aGUgdmVyaWZpY2F0aW9uIHNlcnZpY2UgY2FuIHVzZSB0aGU8 L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgdmFsdWUgb2YgdGhlICZxdW90O3JwaCZxdW90OyBj bGFpbSBhcyB2YWxpZGF0aW9uIHRoYXQgdGhlIGNhbGxpbmcgcGFydHkgaXM8L3R0Pjxicj4NCjx0 dD4mbmJzcDsmbmJzcDsgYXV0aG9yaXplZCBmb3IgUmVzb3VyY2UtUHJpb3JpdHksIHdoaWNoIHdv dWxkIGluIHR1cm4gYmUgdXNlZCBmb3I8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cD5TaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLjxvOnA+PC9vOnA+PC9w Pg0KPHA+VGhpcyB0ZXh0IGlzIGFtYmlndW91cyBhYm91dCB3aGV0aGVyIHRoZSB2YWxpZGF0aW9u IGluZGljYXRlcyB0aGF0IHRoZSBjYWxsaW5nIHBhcnR5IGlzIGF1dGhvcml6ZWQgdG8gdXNlIHRo ZSBwcmlvcml0aWVzIGluZGljYXRlZCBpbiB0aGUgcGFzc3BvcnQgb2JqZWN0LCBvciB0aGUgdmFs dWVzIGluIHRoZSBTSVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQ7IGFuZCAodGFr ZW4gb24gaXRzIGZhY2UpIGltcGxpZXMgdGhlIGxhdHRlciwNCiB3aGVuIHRoZSBpbnRlbnRpb24g aGVyZSBzaG91bGQgY2xlYXJseSBiZSB0aGUgZm9ybWVyLjxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1 b3Q7Li4uYXV0aG9yaXplZCBmb3IgJ1Jlc291cmNlLVByaW9yaXR5JyBpbmRpY2F0ZWQgaW4gdGhl IGNsYWltLiBUaGlzIHZhbHVlIHdvdWxkIGluIHR1cm4gYmUgdXNlZCBmb3IuLi4mcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjxwPlRoZSB0ZXh0IGFsc28gbmVlZHMgdG8gc2F5IHNvbWV0aGluZyBhYm91 dCBjb21wYXJpbmcgdmFsdWVzIGluIHRoZSBjbGFpbSB0byB2YWx1ZXMgaW4gdGhlICdSZXNvdXJj ZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkLCBhbmQgd2hhdCBhIG1pc21hdGNoIG1pZ2h0IG1lYW4u IFRoZSBkb2N1bWVudCBzYXlzIGVsc2V3aGVyZSB0aGF0IHRoZSBzaWduYXR1cmUgbWlnaHQgb25s eSBjb3ZlciBzb21lIG9mIHRoZSByLXZhbHVlcywgd2hpY2ggbWFrZXMNCiBpdCBlbnRpcmVseSBw b3NzaWJsZSB0aGF0IHRoZSAnUmVzb3VyY2UtUHJpb3JpdHknIGZpZWxkIG1pZ2h0IGNvbnRhaW4g bW9yZSB2YWx1ZXMgdGhhbiBhcmUgc2lnbmVkLiBPbiB0aGUgb3RoZXIgaGFuZCwgaW50ZXJtZWRp YXJpZXMgbWlnaHQgcmVhc29uYWJseSByZW1vdmUgci12YWx1ZXMgYXMgdGhlIGNhbGwgaXMgcHJv Y2Vzc2VkLiBUaGlzIHByb2JhYmx5IG1lYW5zIHRoYXQgdGhvc2UgcmVtb3ZlZCBwcmlvcml0aWVz IHNob3VsZCBub3QgYmUNCiB1c2VkLCBldmVuIGlmIHRoZXkgYXJlIHByZXNlbnQgaW4gdGhlIHBh c3Nwb3J0LiBJdCBzZWVtcyByZWFzb25hYmxlIHRvIHNheSB0aGF0ICp0eXBpY2FsKiBwcm9jZXNz aW5nIGJ5IGEgcmVjZWl2aW5nIHBhcnR5IHdvdWxkIGJlIHRvIHRha2UgdGhlICp1bmlvbiogb2Yg YWxsIFJQSCBwYXNzcG9ydHMgdGhhdCB0aGV5IHRydXN0LCBhbmQgKmludGVyc2VjdCogdGhhdCB3 aXRoIHRoZSBwcmlvcml0aWVzIGluICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyDQogZmllbGRz IHRvIGdldCB0aGUgYWN0dWFsIHByaW9yaXR5IG9yIHByaW9yaXRpZXMgdG8gYmUgYXBwbGllZCB0 byB0aGUgY2FsbCAoc3ViamVjdCB0byBsb2NhbCBwb2xpY3kpLjxvOnA+PC9vOnA+PC9wPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgcHJpb3JpdHkgdHJlYXRtZW50 IGluIGFjY29yZGFuY2Ugd2l0aCBsb2NhbCBwb2xpY3kgZm9yIHRoZSBhc3NvY2lhdGVkPC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgY29tbXVuaWNhdGlvbiBzZXJ2 aWNlLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBJbiBhZGRpdGlvbiwgW0ktRC5p ZXRmLXN0aXItcmZjNDQ3NGJpc10gU2VjdGlvbiA2LjIgU3RlcCA0IHJlcXVpcmVzPC90dD48YnI+ DQo8dHQ+Jm5ic3A7Jm5ic3A7ICZxdW90O2lhdCZxdW90OyB2YWx1ZSBpbiAmcXVvdDtycGgmcXVv dDsgY2xhaW0gdG8gYmUgdmVyaWZpZWQuPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IFRoZSBiZWhhdmlvciBvZiBhIFNJUCBVQXMgdXBvbiByZWNlaXZpbmcgYW4gSU5WSVRFIGNvbnRh aW5pbmcgYTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5vZiBhIFNJUCBVQSB1cG9uLi4uJnF1b3Q7 PG86cD48L286cD48L3A+DQo8cD5vcjxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4ub2YgU0lQ IFVBcyB1cG9uLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOyZuYnNwOyBQQVNTcG9yVCBvYmplY3Qgd2l0aCBhICZxdW90O3JwaCZxdW90 OyBjbGFpbSB3aWxsIGxhcmdlbHkgcmVtYWluIGEgbWF0dGVyIG9mPC9zcGFuPjwvdHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb24gcG9saWN5IGZvciB0aGUg c3BlY2lmaWMgY29tbXVuaWNhdGlvbiBzZXJ2aWNlLiZuYnNwOyBJbjwvdHQ+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyBtb3N0IGNhc2VzLGltcGxlbWVudGF0aW9ucyB3b3VsZCBhY3QgYmFzZWQgb24g Y29uZmlkZW5jZSBpbiB0aGU8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uY2FzZXMsIGltcGxlbWVu dGF0aW9ucy4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+KHNwYWNlIGFmdGVyIGNvbW1hKTxv OnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsg dmVyYWNpdHkgb2YgdGhpcyBpbmZvcm1hdGlvbi4mbmJzcDsgVGhlIHVzZSBvZiB0aGUgY29tcGFj dCBmb3JtIG9mPC9zcGFuPjwvdHQ+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlBhcmFncmFwaCBicmVhayBiZWZvcmUgJnF1b3Q7VGhl JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz cDsmbmJzcDsgUEFTU3BvclQgaXMgbm90IHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50Ljwvc3Bh bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8YnI+DQo8dHQ+NS4mbmJzcDsgRnVydGhlciBJbmZvcm1h dGlvbiBBc3NvY2lhdGVkIHdpdGggUmVzb3VyY2UtUHJpb3JpdHk8L3R0Pjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+U2lu Z2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZXJlIG1heSBiZSBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBjYWxsaW5nIHBhcnR5IG9yIHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBjYWxsIHRoYXQgY291bGQgYmUgcmVsZXZhbnQgdG8gYXV0aG9yaXphdGlvbiBmb3IgUmVz b3VyY2UtUHJpb3JpdHkuPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmdsZSBxdW90ZXMgYXJvdW5kICdSZXNv dXJjZS1Qcmlvcml0eScuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZuYnNwOyZuYnNwOyBUaGlzIG1heSBpbmNsdWRlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8g dGhlIGRldmljZSBzdWJzY3JpcHRpb24gb2Y8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyB0aGUgY2FsbGVyLCBvciB0byBhbnkgaW5zdGl0dXRpb25zIHRoYXQgdGhl IGNhbGxlciBvciBkZXZpY2UgaXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYXNzb2NpYXRl ZCB3aXRoLCBvciBldmVuIGNhdGVnb3JpZXMgb2YgaW5zdGl0dXRpb25zLiZuYnNwOyBBbGwgb2Yg dGhlc2U8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgZGF0YSBlbGVtZW50cyB3b3VsZCBiZW5l Zml0IGZyb20gdGhlIHNlY3VyZSBhdHRlc3RhdGlvbnMgcHJvdmlkZWQgYnk8L3R0Pjxicj4NCjx0 dD4mbmJzcDsmbmJzcDsgdGhlIFNUSVIgYW5kIFBBU1Nwb3JUIGZyYW1ld29ya3MuJm5ic3A7IFRo ZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSAmcXVvdDtycGgmcXVvdDs8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgY2xhaW0gY291bGQgZW50YWlsIHRoZSBvcHRpb25hbCBwcmVzZW5jZSBvZiBvbmUg b3IgbW9yZSBzdWNoPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGFkZGl0aW9uYWwgaW5mb3Jt YXRpb24gZmllbGRzLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBBIG5ldyBJQU5B IHJlZ2lzdHJ5IGhhcyBiZWVuIGRlZmluZWQgdG8gaG9sZCBwb3RlbnRpYWwgdmFsdWVzIG9mIHRo ZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyAmcXVvdDtycGgmcXVvdDsgYXJyYXk7IHNlZSBT ZWN0aW9uIDYuMi4mbmJzcDsgVGhlIGRlZmluaXRpb24gb2YgdGhlICZxdW90O3JwaCZxdW90OyBj bGFpbSBtYXk8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgaGF2ZSBvbmUgb3IgbW9yZSBzdWNo IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gZmllbGQocykuJm5ic3A7IERldGFpbHMgb2Y8L3R0Pjxi cj4NCjx0dD4mbmJzcDsmbmJzcDsgc3VjaCAmcXVvdDtycGgmcXVvdDsgY2xhaW0gdG8gZW5jb21w YXNzIG90aGVyIGRhdGEgZWxlbWVudHMgYXJlIGxlZnQgZm9yIGZ1dHVyZTwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyB2ZXJzaW9uIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48L3R0Pjxicj4NCjxi cj4NCjx0dD42LiZuYnNwOyBJQU5BIENvbnNpZGVyYXRpb25zPC90dD48YnI+DQo8YnI+DQo8dHQ+ Ni4xLiZuYnNwOyBKU09OIFdlYiBUb2tlbiBDbGFpbXMgUmVnaXN0cmF0aW9uPC90dD48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPkkgdGhpbmsgdGhlcmUncyBzb21lIGNvbmZ1c2lvbiBoZXJlLiBZb3UncmUgcmVnaXN0ZXJp bmcgYSBQQVNTcG9yVCBwcHQgdmFsdWUsIG5vdCBhIG5ldyBKV1QgY2xhaW0uIFRoYXQgaXMgdG8g c2F5LCB5b3UncmUgYWRkaW5nIGFuIGVudHJ5IHRvIHRoaXMgdGFibGU6PG86cD48L286cD48L3A+ DQo8cD48YSBocmVmPSJodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9wYXNzcG9ydC9w YXNzcG9ydC54aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL3Bhc3Nwb3J0L3Bhc3Nwb3J0LnhodG1sPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+Tm90 IHRvIHRoaXMgdGFibGU6PG86cD48L286cD48L3A+DQo8cD48YSBocmVmPSJodHRwczovL3d3dy5p YW5hLm9yZy9hc3NpZ25tZW50cy9qd3Qvand0LnhodG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvand0L2p3dC54aHRtbDwvYT48bzpwPjwvbzpwPjwv cD4NCjxwPllvdSB3b3VsZCBvbmx5IHVzZSB0aGUgc2Vjb25kIHRhYmxlIGlmIHlvdSBoYWQgYSBu ZXcga2V5IHRvIGFkZCB0byB0aGUgUEFTU3BvclQgaGVhZGVyIC0tIHRoaXMgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBkbyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBzZWN0aW9uIGFsc28g bmVlZHMgc29tZSBpbnRyb2R1Y3RvcnkgdGV4dCB0byBsZXQgdGhlIElBTkEga25vdyBleGFjdGx5 IHdoYXQgdG8gZG87IGUuZy4gJnF1b3Q7VGhpcyBkb2N1bWVudCByZWdpc3RlcnMgYSBuZXcgdmFs dWUgZm9yIHRoZSAmcXVvdDtQZXJzb25hbCBBc3NlcnRpb24gVG9rZW4gKFBBU1Nwb3JUKSBFeHRl bnNpb25zJnF1b3Q7IHRhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgcHB0IHZhbHVlOiAm cXVvdDtycGgmcXVvdDs8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgbyZuYnNwOyBT cGVjaWZpY2F0aW9uIERvY3VtZW50KHMpOiBTZWN0aW9uIDMgb2YgW1JGQ1RoaXNdPC90dD48YnI+ DQo8YnI+DQo8dHQ+Ni4yLiZuYnNwOyBQQVNTcG9yVCAncnBoJyBUeXBlczwvdHQ+PGJyPg0KPGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IHJlcXVlc3RzIHRoYXQgdGhlIElBTkEg YWRkIGEgbmV3IGVudHJ5IHRvIHRoZSBQQVNTcG9yVDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyBUeXBlcyByZWdpc3RyeSBmb3IgdGhlIHR5cGUgJnF1b3Q7cnBoJnF1b3Q7IHdoaWNoIGlzIHNw ZWNpZmllZCBpbiBbUkZDVGhpc10uPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZXJlIGlzbid0IGFuIElBTkEg dGFibGUgY2FsbGVkICZxdW90O1BBU1Nwb3JUIFR5cGVzLiZxdW90OyBJIHByZXN1bWUgdGhpcyBp cyB0aGUgcmVnaXN0cmF0aW9uIHdlIGp1c3QgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNi4xLCBhbmQg c28gdGhlIGFib3ZlIHR3byBsaW5lcyBjYW4gYmUgcmVtb3ZlZC48bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFRoaXMgc3BlY2lmaWNhdGlv biBhbHNvIHJlcXVlc3RzIHRoYXQgdGhlIElBTkEgY3JlYXRlIGEgbmV3IHJlZ2lzdHJ5PC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgZm9yIFBBU1Nwb3JUICZxdW90 O3JwaCZxdW90OyB0eXBlcy4mbmJzcDsgUmVnaXN0cmF0aW9uIG9mIG5ldyBQQVNTcG9yVCAmcXVv dDtycGgmcXVvdDsgdHlwZXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgc2hhbGwgYmUgdW5k ZXIgdGhlIHNwZWNpZmljYXRpb24gcmVxdWlyZWQgcG9saWN5LiZuYnNwOyBUaGlzIHJlZ2lzdHJ5 IGlzPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRvIGJlIGluaXRpYWxseSBwb3B1bGF0ZWQg d2l0aCBhIHNpbmdsZSB2YWx1ZSBmb3IgJnF1b3Q7YXV0aCZxdW90OyB3aGljaCBpczwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyBzcGVjaWZpZWQgaW4gW1JGQ1RoaXNdLjwvdHQ+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cD5UaGlzIG5lZWRzIHRvIGJlIHZlcnkgY2xlYXIgYWJvdXQgdGhlIGZpZWxkcyB0byBiZSBpbmNs dWRlZCBpbiB0aGlzIG5ldyByZWdpc3RyeSAoZS5nLiwgJnF1b3Q7UmVnaXN0cnkgZW50cmllcyBt dXN0IGNvbnRhaW4gdHdvIGZpZWxkczogdGhlIG5hbWUgb2YgdGhlICdycGgnIHR5cGUgYW5kIHRo ZSBzcGVjaWZpY2F0aW9uIGluIHdoaWNoIHRoZSB0eXBlIGlzIGRlc2NyaWJlZCZxdW90OykuPG86 cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PjcuJm5ic3A7IFNlY3VyaXR5IENvbnNpZGVyYXRp b25zPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBkaXNjdXNzZWQgaW4gW0ktRC5pZXRmLXN0aXItcmZjNDQ3NGJpc108L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgaW4gU2VjdGlvbiAxMCBhcmUgYXBwbGljYWJsZSBoZXJlLjwvdHQ+ PGJyPg0KPGJyPg0KPHR0PjcuMS4mbmJzcDsgQXZvaWRhbmNlIG9mIHJlcGxheSBhbmQgY3V0IGFu ZCBwYXN0ZSBhdHRhY2tzPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSBQQVNT cG9yVCBleHRlbnNpb24gd2l0aCBhICZxdW90O3BwdCZxdW90OyB2YWx1ZSBvZiAmcXVvdDtycGgm cXVvdDsgTVVTVCBvbmx5IGJlIHNlbnQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgd2l0aCBT SVAgSU5WSVRFIHdoZW4gJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgaXMgdXNlZCB0byBjb252 ZXkgdGhlPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLmhlYWRlciBmaWVsZC4uLiZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgcHJp b3JpdHkgb2YgdGhlIGNvbW11bmljYXRpb24gYXMgZGVmaW5lZCBpbiBbUkZDNDQxMl0uJm5ic3A7 IFRvIGF2b2lkIHRoZTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7 IHJlcGxheSwgYW5kIGN1dCBhbmQgcGFzdGUgYXR0YWNrcywgdGhlIHByb2NlZHVyZXMgZGVzY3Jp YmVkIGluPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gMTAuMSBvZiBbSS1ELmll dGYtc3Rpci1yZmM0NDc0YmlzXSBNVVNUIGJlIGZvbGxvd2VkLjwvdHQ+PGJyPg0KPGJyPg0KPHR0 PjcuMi4mbmJzcDsgU29sdXRpb24gQ29uc2lkZXJhdGlvbnM8L3R0Pjxicj4NCjxicj4NCjx0dD4m bmJzcDsmbmJzcDsgVGhlIHVzZSBvZiBleHRlbnNpb24gdG8gUEFTU3BvclQgdG9rZW5zIHdpdGgg JnF1b3Q7cHB0JnF1b3Q7IHZhbHVlICZxdW90O3JwaCZxdW90OyBiYXNlZDwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBvbiB0aGUgdmFsaWRhdGlvbiBvZiB0aGUgZGlnaXRhbCBzaWduYXR1cmUg YW5kIHRoZSBhc3NvY2lhdGVkPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNlcnRpZmljYXRl IHJlcXVpcmVzIGNvbnNpZGVyYXRpb24gb2YgdGhlIGF1dGhlbnRpY2F0aW9uIGFuZDwvdHQ+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyBhdXRob3JpdHkgb3IgcmVwdXRhdGlvbiBvZiB0aGUgc2lnbmVy IHRvIGF0dGVzdCB0byB0aGUgaWRlbnRpdHkgYmVpbmc8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJz cDsgYXNzZXJ0ZWQuJm5ic3A7IFRoZSBmb2xsb3dpbmcgY29uc2lkZXJhdGlvbnMgc2hvdWxkIGJl IHJlY29nbml6ZWQgd2hlbjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB1c2luZyBQQVNTcG9y VCBleHRlbnNpb24gd2l0aCAmcXVvdDtwcHQmcXVvdDsgdmFsdWUgb2YgJnF1b3Q7cnBoJnF1b3Q7 OjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBvJm5ic3A7IEFuIGF1dGhvcml0eSAo c2lnbmVyKSBpcyBvbmx5IGFsbG93ZWQgdG8gc2lnbiB0aGUgY29udGVudCBvZiBhIFNJUDwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAnUmVzb3VyY2UtUHJpb3Jp dHknIGhlYWRlciBmb3Igd2hpY2ggaXQgaGFzIHRoZSByaWdodCBhdXRob3JpdHkuPC90dD48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwPiZxdW90Oy4uLmhlYWRlciBmaWVsZC4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VGhlIGF1dGhvcml0eSB0aGF0IHNpZ25zIHRoZSB0b2tlbiBNVVNUIGhhdmUgYSBzZWN1cmUgbWV0 aG9kIGZvcjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBlbmQgdXNlciBvciB0aGUgZGV2aWNl LjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRoZSB2ZXJpZmljYXRp b24gb2YgdGhlIHNpZ25hdHVyZSBNVVNUIGluY2x1ZGUgbWVhbnMgb2YgdmVyaWZ5aW5nPC90dD48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgdGhlIHNpZ25lciBp cyBhdXRob3JpdGF0aXZlIGZvciB0aGUgc2lnbmVkIGNvbnRlbnQgb2YgdGhlIFNJUDwvdHQ+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cD5JdCdzIG5vdCBjbGVhciB3aGF0IGF1dGhvcml0eSBpcyBiZWluZyBjbGFpbWVkIGhl cmUuIElzIHRoaXMgc3VwcG9zZWQgdG8gbWVhbiBzb21ldGhpbmcgbGlrZSAmcXVvdDsuLi52ZXJp ZnlpbmcgdGhhdCB0aGUgc2lnbmVyIGlzIGF1dGhvcml0YXRpdmUgZm9yIHRoZSBvcmlnaW5hdGlu ZyB0biBpbiB0aGUgUEFTU3BvclQuLi4mcXVvdDs/IE9yICZxdW90Oy4uLmF1dGhvcml0YXRpdmUg Zm9yIHRoZSByZXNvdXJjZSBwcmlvcml0eSBuYW1lc3BhY2UgaW4gdGhlIFBBU1Nwb3JUPyZxdW90 Ow0KIFdoYXRldmVyIHRoZSBzZXJ2ZXIgaXMgcHVycG9ydGVkbHkgYXV0aG9yaXRhdGl2ZSBmb3Ig bmVlZHMgdG8gYmUgY2xlYXJseSBzcGVsbGVkIG91dC48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICdSZXNv dXJjZS1Qcmlvcml0eScgaGVhZGVyLjwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5oZWFkZXIgZmll bGQuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+L2ENCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzdGlyIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzdGlyQGlldGYub3JnIj5zdGlyQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3RpciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3RpcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B6C153D09ESESSMB109erics_-- From nobody Sun Feb 4 14:56:40 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D03120725; Sun, 4 Feb 2018 14:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6QfI0AEDdO1l; Sun, 4 Feb 2018 14:56:34 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB42A129BBF; Sun, 4 Feb 2018 14:56:33 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id g18so10532598plo.7; Sun, 04 Feb 2018 14:56:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RaMQVp0UPYUWNBqEtm+M6TrgpIkIkpG5RE+1gfjZoyc=; b=Jc9loc1Kow7jr2nqrXQ3+EZEOhE3ixnGkQc5pS8NcHNd5MSFB0M0785uf0EC5eMGat QcYcYPHmciqe363vf5aVkeyCOuyqpquX5hMqIt4KBXM7r539Oidx/2XOYTK2Z9n/Y5YD jK4lrbfYFDrFB+x2p0qumIPOXnBtmhjfALTw0dUkSCYxMIGGfBOOsudI3T9iBLXMWyS8 f5mP3aittuut33CYLWTNffVIFLtgOlh9EdP8aWaYb+NNVm/6HGttZFbza8cEU0MMszpg vfBTpkJ6Egvqd9FYfoz8ObGhXRAeEuPIYNvkPAbg8pe9dvSbHRpo0EnouL0OXNXpvFhD y3Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RaMQVp0UPYUWNBqEtm+M6TrgpIkIkpG5RE+1gfjZoyc=; b=pqtJGgHOlcg1EiZltdjh/i+TMWWLjigicktPPtHlhW2p99i3O1k59RBmzk8OJzl2hd m1oX7ue4h9nbkuDT6+KQwT/xAETmjmejzdpWeipeLliy/7PWDMeHl2Go56MGtPIBlyFL vjv0qvB8svCImcJQylRPc22/w1SiaEIbD6PxScx69ml9eEm1Jte2VgkncNKmPHQQDwtK V939Z1kmnl/fSdrCgXE0piGhgOPxgVtWvqC4bYsA13yHoW0gSauu7aTWJ5LlLrIa8wZ8 eViuUrudqxfOB0cqKtmbDzcHeczQ8xJLn/PUIEW0XB6CcXTfXXkwwRHTaUSEoMedE3Sv YGKQ== X-Gm-Message-State: AKwxytc48ViphA1mTcArwLhLHXfPDlCTp4r25Ehz5DiurCp38DR5nbqh 1hdDsI6uDzp84NzaC55Soza+Rra1 X-Google-Smtp-Source: AH8x224SEqpanLgXOSqJrvHrASmAAJIeCCvVXtJkxeSxqai2wq8oOMJ7B5OrFNrOg6/WiCz4WczC+g== X-Received: by 2002:a17:902:be09:: with SMTP id r9-v6mr42240729pls.234.1517784992835; Sun, 04 Feb 2018 14:56:32 -0800 (PST) Received: from [100.99.176.227] (198.sub-174-214-12.myvzw.com. [174.214.12.198]) by smtp.gmail.com with ESMTPSA id z186sm10794533pgb.70.2018.02.04.14.56.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 14:56:31 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-DDE31DDA-26B7-4EB7-BDE8-37432C4CAA78 Mime-Version: 1.0 (1.0) From: Subir X-Mailer: iPhone Mail (14D27) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> Date: Mon, 5 Feb 2018 04:26:26 +0530 Cc: Adam Roach , STIR Chairs , "stir@ietf.org" , "draft-ietf-stir-rph.all@tools.ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> To: Christer Holmberg Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 22:56:39 -0000 --Apple-Mail-DDE31DDA-26B7-4EB7-BDE8-37432C4CAA78 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable We can add some texts to clarify that in the next version. The point is that= in some use cases service provider may have the authority to other claims s= uch as 'orig' and in other cases it may not have. We can add a may statemen= t clarifying this or explicitly say that it is not required to have authorit= y to other claims. Thanks, Subir=20 Sent from my iPhone > On Feb 4, 2018, at 10:03 PM, Christer Holmberg wrote: >=20 > Hi, > =20 > The text says: > =20 > =81gThe credentials (e.g., authority responsible for authorizing Resour= ce- > Priority) used to create the signature must have authority over the > namespace of the "rph" claim and there is only one authority per > claim.=81h > =20 > If the credentials don=81ft need to have authority of the other claims (e.= g., =81gorig=81h) in the RPH PASSPorT I think you should explicitly say so. > =20 > Regards, > =20 > Christer > =20 > =20 > From: Subir Das [mailto:subirdas21@gmail.com]=20 > Sent: 02 February 2018 01:04 > To: Christer Holmberg > Cc: Adam Roach ; STIR Chairs ; sti= r@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org > Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to asser= t the callers identity assumed? > =20 > Hello Christer, > The signing entity does not have always the authority to assert the caller= identity in rph. We are submitting ver-03 draft and it is clarified as fo= llows: > "The credentials (e.g., authority responsible for authorizing Resource-Pri= ority) used to create the signature must have authority over the namespace o= f the=81grph" claim.." > =20 > -Subir > =20 > On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg wrote: > Hi, > =20 > Another question for clarification. > =20 > Section 3 contains the following example: > =20 > { "orig":{"tn":"12155551212"} > "dest":{["tn":"12125551213"]}, > "iat":1443208345, > "rph":{"auth":["ets.0","wps.0"]} > =20 > =81cand the following text: > =20 > =81gThe credentials (e.g., authority responsible for authorizing Resour= ce- > Priority) used to create the signature must have authority over the > "rph" claim=81c=81h > =20 > Since the claim also contains =81gorig=81h, is the assumption that the sig= ning entity always also has authority to assert the callers identity? I thin= k it would be good to explicitly mention it. > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > =20 > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 20 January 2018 00:15 > To: STIR Chairs ; stir@ietf.org; draft-ietf-stir-rph= .all@tools.ietf.org > Subject: [stir] AD Review: draft-ietf-stir-rph-02 > =20 > I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who h= as worked on this document, and the authors and chairs in particular. >=20 > The technical content here looks generally good to me. I'd like to see a f= ew issues addressed before IETF LC. In short sumary: >=20 > The validation section needs to add a discussion of how to treat calls whe= n the priority values in "rph" passports and SIP "Resource-Priority" header f= ields aren't 100% identical. > The examples need some adjustment. > There is a minor point of ambiguity in the Security Section, but this shou= ld be easy to fix, as long as the WG knows what was intended. > The IANA actions need a little bit of adjustment. > There are a number of minor editorial issues to be cleaned up. > Detailed comments on these points are inline in the document below. I've r= emoved some portions of the document on which I have no comments. >=20 > =20 >=20 >=20 > Abstract >=20 > This document extends the STIR PASSporT specification to allow the > =20 >=20 > "...the Secure Telephone Identity Revisited (STIR) Personal Assertion Toke= n (PASSporT) specification defined in RFC 8122..." >=20 > (See for guida= nce on abbreviations) >=20 > =20 >=20 > inclusion of cryptographically-signed assertions of authorization for > the values populated in the SIP 'Resource-Priority' header field, > which is used for communications resource prioritization. >=20 > ... >=20 > 1. Introduction >=20 > PASSporT [I-D.ietf-stir-passport] is a token format based on JWT > [RFC7519] for conveying cryptographically-signed information about > the identities involved in personal communications; it is used with > STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the > identity of the participants in real-time communications established > via a protocol like SIP. This specification extends PASSporT to > =20 >=20 > "...like SIP [RFC3261]..." >=20 > (We want to cite SIP the first time it is mentioned) >=20 > =20 >=20 > allow cryptographic-signing of the SIP 'Resource-Priority' header > field defined in [RFC4412]. >=20 > [RFC4412] defines the SIP 'Resource-Priority' header field for > communications Resource Priority. As specified in [RFC4412], the > 'Resource-Priority' header field may be used by SIP user agents > [RFC3261], including, Public Switched Telephone Network (PSTN) > =20 >=20 > "...including Public Switched..." >=20 > (remove the comma) >=20 > =20 >=20 > gateways and terminals, and SIP proxy servers to influence > =20 >=20 > "...and by SIP proxy servers, to influence..." >=20 > (add "by" and comma) >=20 > =20 >=20 > prioritization afforded to communication sessions,including PSTN > =20 > "...sessions, including..." >=20 > (space after comma) >=20 > =20 >=20 > calls. However, the SIP 'Resource-Priority' header field could be > spoofed and abused by unauthorized entities. >=20 > The STIR architecture [RFC7340]assumes that an authority on the > =20 >=20 > "...STIR architecture [RFC7340] assumes..." >=20 > (space before "assumes") >=20 > =20 >=20 > originating side of a call provides a cryptographic assurance of the > validity of the calling party number in order to prevent > impersonation attacks. The STIR architecture allows extension that > =20 >=20 > "...allows extensions..." >=20 > =20 >=20 > can be utilized by authorities supporting real-time communication > services using the 'Resource-Priority' header field to > cryptographically sign the SIP 'Resource-Priority' header field and > convey assertion of the authorization for 'Resource-Priority'. For > example, the authority on the originating side verifying the > authorization of a particular communication for Resource-Priority can > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > =20 >=20 > use a PASSPorT claim to cryptographically-sign the SIP 'Resource- > =20 >=20 > "...cryptographically sign..." >=20 > =20 >=20 > Priority' header field and convey an assertion of the authorization > for 'Resource-Priority'. This will allow a receiving entity > (including entities located in different network domains/boundaries) > to verify the validity of assertions authorizing Resource-Priority. > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > =20 >=20 > Cryptographically-signed SIP 'Resource-Priority' headers will allow a > =20 >=20 > "...cryptographically signed SIP 'Resource-Priority' header fields..." >=20 > (remove hyphen, and replace "headers" with "header fields") >=20 > =20 >=20 > receiving entity to verify and act on the information with confidence > that the information have not been spoofed or compromised. > =20 >=20 > "...has not been spoofed or compromised." >=20 > =20 >=20 >=20 > This specification documents an optional extension to PASSporT and > the associated STIR mechanisms to provide a function to sign the SIP > 'Resource-Priority' header field. This PASSporT object is used to > provide attestation of a calling user authorization for priority > communications. This is necessary in addition to the PASSporT object > that is used for calling user telephone number attestation. How the > optional extension to PASSporT is used for real-time communications > supported using SIP 'Resource-Priority' header field is defined in > other documents and is outside the scope of this document. > =20 >=20 > I assume these other documents are under development? If so, they should b= e cited here. >=20 > =20 >=20 >=20 > 2. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > =20 >=20 > This document has several non-normative uses of "must", "should," and "may= ," and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boi= lerplate. >=20 > =20 >=20 >=20 > 3. PASSporT 'rph' Claim >=20 > This specification defines a new JSON Web Token claim for "rph", > which provides an assertion for information in SIP 'Resource- > Priority'header. > =20 >=20 > "...Priority' header field." >=20 > (space after closing quotation mark, "header field" instead of "header") >=20 > =20 >=20 >=20 > The creator of a PASSporT object adds a "ppt" value of "rph" to the > header of a PASSporT object, in which case the PASSporT claims MUST > contain a "rph" claim, and any entities verifying the PASSporT object > will be required to understand the "ppt" extension in order to > process the PASSporT in question. A PASSPorT header with the "ppt" > included will look as follows: >=20 > { "typ":"passport", > "ppt":"rph", > "alg":"ES256", > "x5u":"https://www.example.org/cert.cer"} > =20 >=20 > Ideally, this would be either pretty-printed or canonicalized. Since it's t= oo long to fit on a line in canonical form, I propose: >=20 > { > "typ":"passport", > "ppt":"rph", > "alg":"ES256", > "x5u":"https://www.example.org/cert.cer" > } >=20 > =20 >=20 >=20 > The "rph" claim will provide an assertion of authorization,"auth", > =20 >=20 > "...authorization, "auth", ..." >=20 > (space between comma and opening quotation mark) >=20 > =20 >=20 > for information in the SIP "Resource-Priority" header field (i.e., > Resource-Priority: namespace "." r-priority) based on [RFC4412]. > =20 >=20 > The use of the string 'namespace "." r-priority' here and elsewhere in the= document has a detrimental impact on readability. I strongly suggest replac= ing it with "r-value" (the name of this production in RFC4412) everywhere. >=20 > =20 >=20 > Specifically, the "rph" claim includes assertion of the priority- > level of the user to be used for a given communication session. The > value of the "rph" claim is an array containing one or more of JSON > objects for the content of the SIP 'Resource-Priority' header that is > being asserted of which one of the "rph" object, is mandatory. > =20 >=20 > This last sentence is very hard to parse; and (based on the example) the v= alue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object with= one or more keys. Each key is associated with a JSON Array. These arrays c= ontain Strings that correspond to the r-values indicated in the SIP "Resourc= e-Priority" header field.' (note: "header field", not "header") >=20 > =20 >=20 >=20 > The following is an example "rph" claim for a SIP "Resource-Priority" > header field with a "namespace "." r-priority" value of "ets.0" and > with a "namespace "." r-priority" value of "wps.0". >=20 > { "orig":{"tn":"12155551212"} > "dest":{["tn":"12125551213"]}, > "iat":1443208345, > "rph":{"auth":["ets.0","wps.0"]} > =20 >=20 > As above, I recommend pretty-printing this. It's also missing a comma afte= r the "orig" value, and the top-level structure is missing a closing brace. T= he value for "iat" needs to be enclosed in quotes. >=20 > The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much o= f which remains assignable (cf ). >=20 > Putting all this together, I believe what you want is: >=20 > { > "orig":{"tn":"12155550112"}, > "dest":{["tn":"12125550113"]}, > "iat":"1443208345", > "rph":{"auth":["ets.0","wps.0"]} > } >=20 > =20 >=20 >=20 > After the header and claims PASSporT objects have been constructed, > their signature is generated normally per the guidance in > [I-D.ietf-stir-passport] using the full form of PASSPorT. The > credentials (e.g., authority responsible for authorizing Resource- > Priority) used to create the signature must have authority over the > "rph" claim and there is only one authority per claim. The authority > MUST use its credentials (i.e., CERT) associated with the specific > service supported by the SIP namespace in the claim. >=20 > 4. 'rph' in SIP >=20 > This section specifies SIP-specific usage for the "rph" claim in > PASSporT. >=20 > 4.1. Authentication Service Behavior >=20 > The Authentication Service will create the "rph" claim using the > values discussed in section 3 based on [RFC4412]. The construction > of "rph" claim follows the steps described in Section 4 of > [I-D.ietf-stir-rfc4474bis]. >=20 > The resulting Identity header for "rph" might look as follows: > =20 >=20 > "...header field..." >=20 > =20 >=20 >=20 > "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd > ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO > aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW > EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW > pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR > VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z > aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D > l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ > oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256; > ppt=3D"rph" > =20 >=20 > This example has a number of issues: >=20 > In the Identity header field, the signed-identity-digest shouldn't be quot= ed. > In the Identity header field, info is enclosed in <> rather than "". > In the Identity header field, ppt is a token rather than a quoted string. > The signed-identity-digest header needs to indicate a "typ" of "passport" r= ather than JWT, and it needs to include both a "ppt" and "x5u" field. > The signed-identity-digest body should contain only the passport claim rat= her than a JSON object that itself contains a base64-encoded JWS header conc= atenated with a claim. > I believe that, even when the body is included, values in the header and b= ody need to be be canonicalized (i.e., all on one line, no spaces, in alphab= etical order, etc.) > I would also recommend following the convention of indicating that line-wr= aps are only for readability, and including the header field name in the exa= mple. Putting all this together, I believe what you want is: >=20 > For example, a Identity header field for "rph" might look > as follows (backslashes shown for line folding only): >=20 > Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ > iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ > Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ > 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ > AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ > 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D >;alg=3DES256;ppt=3Drph >=20 > (Note: this example assumes the calling and called party numbers in the pr= evious example are changed to 12155550112 and 12155550113, respectively) >=20 > =20 >=20 >=20 > A SIP authentication service typically will derive the value of "rph" > from the 'Resource-Priority' header field based on policy associated > with service specific use of the "namespace "." r-priority" values > based on [RFC4412]. The authentication service derives the value of > the PASSPorT claim by verifying the authorization for Resource- > Priority (i.e., verifying a calling user privilege for Resource- > Priority based on its identity) which might be derived from customer > profile data or from access to external services. >=20 > [RFC4412] allows multiple "namespace "." r-priority" pairs, either in > a single SIP Resource-Priority header or across multiple SIP > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header field..." >=20 > =20 >=20 > Resource-Priority headers. However, it is not necessary to sign all > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header fields..." >=20 > =20 >=20 > content of a SIP Resource-Priority header or all SIP Resource- > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header field..." >=20 > =20 >=20 > Priority headers in a given SIP message. An authority is only > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header fields..." >=20 > =20 >=20 > responsible for signing the content of a SIP Resource-Priority header > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header field..." >=20 > =20 >=20 > for which it has authority (e.g., a specific "namespace "." > r-priority"). >=20 > 4.2. Verification Service Behavior >=20 > [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that > specifications defining "ppt" values describe any additional verifier > behavior. The behavior specified for the "ppt" values of "rph" is as > follows: >=20 > The verification service MUST extract the value associated with the > "auth" key in a full form PASSPorT with a "ppt" value of "rph". If > the signature validates, then the verification service can use the > value of the "rph" claim as validation that the calling party is > authorized for Resource-Priority, which would in turn be used for > =20 > Single quotes around 'Resource-Priority'. >=20 > This text is ambiguous about whether the validation indicates that the cal= ling party is authorized to use the priorities indicated in the passport obj= ect, or the values in the SIP 'Resource-Priority' header field; and (taken o= n its face) implies the latter, when the intention here should clearly be th= e former. >=20 > "...authorized for 'Resource-Priority' indicated in the claim. This value w= ould in turn be used for..." >=20 > The text also needs to say something about comparing values in the claim t= o values in the 'Resource-Priority' header field, and what a mismatch might m= ean. The document says elsewhere that the signature might only cover some of= the r-values, which makes it entirely possible that the 'Resource-Priority'= field might contain more values than are signed. On the other hand, interme= diaries might reasonably remove r-values as the call is processed. This prob= ably means that those removed priorities should not be used, even if they ar= e present in the passport. It seems reasonable to say that *typical* process= ing by a receiving party would be to take the *union* of all RPH passports t= hat they trust, and *intersect* that with the priorities in 'Resource-Priori= ty' header fields to get the actual priority or priorities to be applied to t= he call (subject to local policy). >=20 > =20 >=20 > priority treatment in accordance with local policy for the associated > communication service. >=20 > In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires > "iat" value in "rph" claim to be verified. >=20 > The behavior of a SIP UAs upon receiving an INVITE containing a > =20 >=20 > "...of a SIP UA upon..." >=20 > or >=20 > "...of SIP UAs upon..." >=20 > =20 >=20 > PASSporT object with a "rph" claim will largely remain a matter of > implementation policy for the specific communication service. In > most cases,implementations would act based on confidence in the > =20 >=20 > "...cases, implementations..." >=20 > (space after comma) >=20 > =20 >=20 > veracity of this information. The use of the compact form of > =20 >=20 > Paragraph break before "The". >=20 > =20 >=20 > PASSporT is not specified in this document. >=20 > 5. Further Information Associated with Resource-Priority > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > =20 >=20 >=20 > There may be additional information about the calling party or the > call that could be relevant to authorization for Resource-Priority. > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > =20 >=20 > This may include information related to the device subscription of > the caller, or to any institutions that the caller or device is > associated with, or even categories of institutions. All of these > data elements would benefit from the secure attestations provided by > the STIR and PASSporT frameworks. The specification of the "rph" > claim could entail the optional presence of one or more such > additional information fields. >=20 > A new IANA registry has been defined to hold potential values of the > "rph" array; see Section 6.2. The definition of the "rph" claim may > have one or more such additional information field(s). Details of > such "rph" claim to encompass other data elements are left for future > version of this specification. >=20 > 6. IANA Considerations >=20 > 6.1. JSON Web Token Claims Registration > =20 >=20 > I think there's some confusion here. You're registering a PASSporT ppt val= ue, not a new JWT claim. That is to say, you're adding an entry to this tabl= e: >=20 > https://www.iana.org/assignments/passport/passport.xhtml >=20 > Not to this table: >=20 > https://www.iana.org/assignments/jwt/jwt.xhtml >=20 > You would only use the second table if you had a new key to add to the PAS= SporT header -- this specification does not do that. >=20 > This section also needs some introductory text to let the IANA know exactl= y what to do; e.g. "This document registers a new value for the "Personal As= sertion Token (PASSporT) Extensions" table. >=20 >=20 > o ppt value: "rph" >=20 > o Specification Document(s): Section 3 of [RFCThis] >=20 > 6.2. PASSporT 'rph' Types >=20 > This document requests that the IANA add a new entry to the PASSporT > Types registry for the type "rph" which is specified in [RFCThis]. > =20 >=20 > There isn't an IANA table called "PASSporT Types." I presume this is the r= egistration we just discussed in section 6.1, and so the above two lines can= be removed. >=20 > =20 >=20 > This specification also requests that the IANA create a new registry > for PASSporT "rph" types. Registration of new PASSporT "rph" types > shall be under the specification required policy. This registry is > to be initially populated with a single value for "auth" which is > specified in [RFCThis]. > =20 >=20 > This needs to be very clear about the fields to be included in this new re= gistry (e.g., "Registry entries must contain two fields: the name of the 'rp= h' type and the specification in which the type is described"). >=20 > =20 >=20 >=20 > 7. Security Considerations >=20 > The security considerations discussed in [I-D.ietf-stir-rfc4474bis] > in Section 10 are applicable here. >=20 > 7.1. Avoidance of replay and cut and paste attacks >=20 > The PASSporT extension with a "ppt" value of "rph" MUST only be sent > with SIP INVITE when 'Resource-Priority' header is used to convey the > =20 >=20 > "...header field..." >=20 > =20 >=20 > priority of the communication as defined in [RFC4412]. To avoid the > replay, and cut and paste attacks, the procedures described in > Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. >=20 > 7.2. Solution Considerations >=20 > The use of extension to PASSporT tokens with "ppt" value "rph" based > on the validation of the digital signature and the associated > certificate requires consideration of the authentication and > authority or reputation of the signer to attest to the identity being > asserted. The following considerations should be recognized when > using PASSporT extension with "ppt" value of "rph": >=20 > o An authority (signer) is only allowed to sign the content of a SIP > 'Resource-Priority' header for which it has the right authority. > =20 >=20 > "...header field..." >=20 > =20 >=20 > The authority that signs the token MUST have a secure method for > authentication of the end user or the device. >=20 > o The verification of the signature MUST include means of verifying > that the signer is authoritative for the signed content of the SIP > =20 >=20 > It's not clear what authority is being claimed here. Is this supposed to m= ean something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource prio= rity namespace in the PASSporT?" Whatever the server is purportedly authorit= ative for needs to be clearly spelled out. >=20 > =20 >=20 > 'Resource-Priority' header. > =20 >=20 > "...header field." >=20 > =20 >=20 > /a >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > =20 --Apple-Mail-DDE31DDA-26B7-4EB7-BDE8-37432C4CAA78 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

We can add some texts to clarify t= hat in the next version. The point is that in some use cases service provide= r may have the authority to  other claims such as 'orig' and in other c= ases it may not have.  We can add a may statement clarifying this or ex= plicitly say that it is not required to have authority to other claims.

Tha= nks,

Subir 
Sent from my iPhone

On Feb 4, 2018, at 10= :03 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 <= /o:p>

The text say= s:

 <= /o:p>

  = =E2=80=9CThe credentials (e.g., authority responsible for authorizing Resou= rce-

  = Priority) used to create the signature must have authority over the

  = namespace of the "rph" claim and there is only one authority per=

  = claim.=E2=80=9D

 <= /o:p>

If the crede= ntials don=E2=80=99t need to have authority of the other claims (e.g., =E2=80= =9Corig=E2=80=9D) in the RPH PASSPorT I think you should explicitly say so.

 <= /o:p>

Regards,

 <= /o:p>

Christer

 <= /o:p>

 <= /o:p>

From: Sub= ir Das [mailto:subirdas21@gmail.com<= /a>]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.c= om>; STIR Chairs <stir-cha= irs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.= all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to a= ssert the callers identity assumed?

 

Hello Christer,

The signing entity does not have always the authority= to assert the caller identity in rph. We are submitting ver-03 draft  a= nd it is clarified  as follows:

"The credentials (e.g., authority respo= nsible for authorizing Resource-Priority) used to create the signature must h= ave authority over the namespace of the=E2=80=9Crph" claim.."

 

-Subir

 

On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg &l= t;christ= er.holmberg@ericsson.com> wrote:

Hi,

 

Another question for clarification.<= /p>

 

Section 3 contains the following example:<= /o:p>

 

    { "orig":{"tn":"12155551212"= }

     "dest":{["tn":"12125551213"]},

     "iat":1443208345,=

     "rph":{"auth":["ets.0","wps.0= "]}

 

=E2=80=A6and the following text:

=

 

   =E2=80=9CThe credentials (e.g., authority= responsible for authorizing Resource-

   Priority) used to create the signature mu= st have authority over the

   "rph" claim=E2=80=A6=E2=80=9D

&nb= sp;

Since the claim also contains =E2=80=9Corig=E2=80=9D, i= s the assumption that the signing entity always also has authority to assert the callers identity? I think it would be good to explicitly ment= ion it.

 

Regards,

 

Christer

 

 

 

 

 

 

From: stir [mailto:<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri"= ;,sans-serif">stir-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org>; sti= r@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: [stir] AD Review: draft-ietf-stir-rph-02

 

I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who h= as worked on this document, and the authors and chairs in particular.

The technical content here looks generally good to me. I'd like to see a f= ew issues addressed before IETF LC. In short sumary:

  • The validation section needs to add a discussion of how to treat calls when t= he priority values in "rph" passports and SIP "Resource-Priority" header fie= lds aren't 100% identical.
  • The examples need some adjustment.
  • There is a minor point of ambiguity in the Security Section, but this should= be easy to fix, as long as the WG knows what was intended.
    • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto;mso-list:l1 level1 lfo3"> The IANA actions need a little bit of adjustment.
  • There are a number of minor editorial issues to be cleaned up.

Detailed comments on these points are inline in the document below. I've r= emoved some portions of the document on which I have no comments.=

 


Abstract

   This document extends the STIR PASSporT specification to al= low the

 

"...the Secure Telephone Identity Revisited (STIR) Personal Assertion Tok= en (PASSporT) specification defined in RFC 8122..."

(See <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for gu= idance on abbreviations)

 

   inclusion of crypt= ographically-signed assertions of authorization for
   the values populated in the SIP 'Resource-Priority' header f= ield,
   which is used for communications resource prioritization.

...

1.  Introduction

   PASSporT [I-D.ietf-stir-passport] is a token format based o= n JWT
   [RFC7519] for conveying cryptographically-signed informatio= n about
   the identities involved in personal communications; it is u= sed with
   STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertio= n of the
   identity of the participants in real-time communications es= tablished
   via a protocol like SIP.  This specification extends P= ASSporT to

 

"...like SIP [RFC3261]..."

(We want to cite SIP the first time it is mentioned)

 

   allow cryptographi= c-signing of the SIP 'Resource-Priority' header
   field defined in [RFC4412].

   [RFC4412] defines the SIP 'Resource-Priority' header field f= or
   communications Resource Priority.  As specified in [RFC= 4412], the
   'Resource-Priority' header field may be used by SIP user ag= ents
   [RFC3261], including, Public Switched Telephone Network (PS= TN)

 

"...including Public Switched..."

(remove the comma)

 

   gateways and termi= nals, and SIP proxy servers to influence

 

"...and by SIP proxy servers, to influence..."

(add "by" and comma)

 

   prioritization aff= orded to communication sessions,including PSTN

 

"...sessions, including..."

(space after comma)

 

   calls.  Howev= er, the SIP 'Resource-Priority' header field could be
   spoofed and abused by unauthorized entities.

   The STIR architecture [RFC7340]assumes that an authority on= the

 

"...STIR architecture [RFC7340] assumes..."

(space before "assumes")

 

   originating side o= f a call provides a cryptographic assurance of the
   validity of the calling party number in order to prevent
   impersonation attacks.  The STIR architecture allows e= xtension that

 

"...allows extensions..."

 

   can be utilized by= authorities supporting real-time communication
   services using the 'Resource-Priority' header field to=
   cryptographically sign the SIP 'Resource-Priority' header f= ield and
   convey assertion of the authorization for 'Resource-Priorit= y'.  For
   example, the authority on the originating side verifying th= e
   authorization of a particular communication for Resource-Pr= iority can

 

Single quotes around 'Resource-Priority'.

 

   use a PASSPorT cla= im to cryptographically-sign the SIP 'Resource-

 

"...cryptographically sign..."

 

   Priority' header f= ield and convey an assertion of the authorization
   for 'Resource-Priority'.  This will allow a receiving e= ntity
   (including entities located in different network domains/bo= undaries)
   to verify the validity of assertions authorizing Resource-P= riority.

 

Single quotes around 'Resource-Priority'.

 

   Cryptographically-= signed SIP 'Resource-Priority' headers will allow a

 

"...cryptographically signed SIP 'Resource-Priority' header fields..."

(remove hyphen, and replace "headers" with "header fields")

 

   receiving entity t= o verify and act on the information with confidence
   that the information have not been spoofed or compromised.<= /tt>

 

"...has not been spoofed or compromised."

 


   This specification documents an optional extension to PASSp= orT and
   the associated STIR mechanisms to provide a function to sig= n the SIP
   'Resource-Priority' header field.  This PASSporT objec= t is used to
   provide attestation of a calling user authorization for pri= ority
   communications.  This is necessary in addition to the P= ASSporT object
   that is used for calling user telephone number attestation.=   How the
   optional extension to PASSporT is used for real-time commun= ications
   supported using SIP 'Resource-Priority' header field is def= ined in
   other documents and is outside the scope of this document.<= /tt>

 

I assume these other documents are under development? If so, they should b= e cited here.

 


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHA= LL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL= " in this
   document are to be interpreted as described in RFC 2119 [RFC= 2119].

 

This document has several non-normative uses of "must", "should," and "ma= y," and so it needs to use the RFC8174 boilerplate instead of the RFC2119 bo= ilerplate.

 


3.  PASSporT 'rph' Claim

   This specification defines a new JSON Web Token claim for "= rph",
   which provides an assertion for information in SIP 'Resourc= e-
   Priority'header.

 

"...Priority' header field."

(space after closing quotation mark, "header field" instead of "header")<= o:p>

 


   The creator of a PASSporT object adds a "ppt" value of "rph= " to the
   header of a PASSporT object, in which case the PASSporT cla= ims MUST
   contain a "rph" claim, and any entities verifying the PASSp= orT object
   will be required to understand the "ppt" extension in order= to
   process the PASSporT in question.  A PASSPorT header w= ith the "ppt"
   included will look as follows:

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.example.org/cert.cer"= }

 

Ideally, this would be either pretty-printed or canonicalized. Since it's= too long to fit on a line in canonical form, I propose:

{
  "typ":"passport",
  "ppt":"rph",
  "alg":"ES256",
  "x5u":"https://www.example.org/cert.cer"
}

 


   The "rph" claim will provide an assertion of authorization,= "auth",

 

"...authorization, "auth", ..."

(space between comma and opening quotation mark)

 

   for information in= the SIP "Resource-Priority" header field (i.e.,
   Resource-Priority: namespace "." r-priority) based on [RFC4= 412].

 

The use of the string 'namespace "." r-priority' here and elsewhere in th= e document has a detrimental impact on readability. I strongly suggest repla= cing it with "r-value" (the name of this production in RFC4412) everywhere.<= o:p>

 

   Specifically, the "= rph" claim includes assertion of the priority-
   level of the user to be used for a given communication sess= ion.  The
   value of the "rph" claim is an array containing one or more= of JSON
   objects for the content of the SIP 'Resource-Priority' head= er that is
   being asserted of which one of the "rph" object, is mandato= ry.

 

This last sentence is very hard to parse; and (based on the example) the v= alue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object with= one or more keys. Each key is associated with a JSON Array. These arrays contain Strings that correspo= nd to the r-values indicated in the SIP "Resource-Priority" header field.' (= note: "header field", not "header")

 


   The following is an example "rph" claim for a SIP "Resource= -Priority"
   header field with a "namespace "." r-priority" value of "et= s.0" and
   with a "namespace "." r-priority" value of "wps.0".
    { "orig":{"tn":"12155551212"}
     "dest":{["tn":"12125551213"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0","wps.0"]}

 

As above, I recommend pretty-printing this. It's also missing a comma aft= er the "orig" value, and the top-level structure is missing a closing brace.= The value for "iat" needs to be enclosed in quotes.

The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much o= f which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).

Putting all this together, I believe what you want is:

{
  "orig":{"tn":"12155550112"},
=   "dest":{["tn":"12125550113"]},=   "iat":"1443208345",
  "rph":{"auth":["ets.0","wps.0"]}
}

 


   After the header and claims PASSporT objects have been cons= tructed,
   their signature is generated normally per the guidance in
   [I-D.ietf-stir-passport] using the full form of PASSPorT.&n= bsp; The
   credentials (e.g., authority responsible for authorizing Re= source-
   Priority) used to create the signature must have authority o= ver the
   "rph" claim and there is only one authority per claim. = ; The authority
   MUST use its credentials (i.e., CERT) associated with the s= pecific
   service supported by the SIP namespace in the claim.
4.  'rph' in SIP

   This section specifies SIP-specific usage for the "rph" cla= im in
   PASSporT.

4.1.  Authentication Service Behavior

   The Authentication Service will create the "rph" claim usin= g the
   values discussed in section 3 based on [RFC4412].  The= construction
   of "rph" claim follows the steps described in Section 4 of<= /tt>
   [I-D.ietf-stir-rfc4474bis].

   The resulting Identity header for "rph" might look as follo= ws:

 

"...header field..."

 


   "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBa= U9pSnd
   ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRl= V6STFO
   aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJ= TOWpaW
   EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBi= aUk2SW
   pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNV= EkxTlR
   VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2= dpT25z
   aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6V= C8HM6D
   l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs= 3fslM_
   oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256;
   ppt=3D"rph"

 

This example has a number of issues:

  • In the Identity header field, the signed-identity-digest shouldn't be quoted= .
  • In the Identity header field, info is enclosed in <> rather than "".
  • In the Identity header field, ppt is a token rather than a quoted string.
  • The signed-identity-digest header needs to indicate a "typ" of "passport" ra= ther than JWT, and it needs to include both a "ppt" and "x5u" field.
  • The signed-identity-digest body should contain only the passport claim rathe= r than a JSON object that itself contains a base64-encoded JWS header concat= enated with a claim.
  • I believe that, even when the body is included, values in the header and bod= y need to be be canonicalized (i.e., all on one line, no spaces, in alphabet= ical order, etc.)

I would also recommend following the convention of indicating that line-w= raps are only for readability, and including the header field name in the ex= ample. Putting all this together, I believe what you want is:

=

   For example, a Identity= header field for "rph" might look
   as follows (backslashes shown for line folding only):<= /span>

   Identity: eyJhbGciOiJFU= zI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \
   iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.= eyJkZXN0 \
   Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiw= ib3JpZyI \
   6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIi= wid3BzLj \
   AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-= n8MIhoCr \
   18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D<https://www.example.org/cer= t.cer \
   >;alg=3DES256;ppt=3Drph

(Note: this example assumes the calling and called party numbers in the prev= ious example are changed to 12155550112 and 12155550113, respectively)

 


   A SIP authentication service typically will derive the valu= e of "rph"
   from the 'Resource-Priority' header field based on policy a= ssociated
   with service specific use of the "namespace "." r-priority"= values
   based on [RFC4412].  The authentication service derive= s the value of
   the PASSPorT claim by verifying the authorization for Resou= rce-
   Priority (i.e., verifying a calling user privilege for Reso= urce-
   Priority based on its identity) which might be derived from= customer
   profile data or from access to external services.

   [RFC4412] allows multiple "namespace "." r-priority" pairs,= either in
   a single SIP Resource-Priority header or across multiple SI= P

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   Resource-Priority h= eaders.  However, it is not necessary to sign all

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

   content of a SIP R= esource-Priority header or all SIP Resource-

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   Priority headers i= n a given SIP message.  An authority is only

=

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

   responsible for si= gning the content of a SIP Resource-Priority header

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   for which it has a= uthority (e.g., a specific "namespace "."
   r-priority").

4.2.  Verification Service Behavior

   [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that=
   specifications defining "ppt" values describe any additiona= l verifier
   behavior.  The behavior specified for the "ppt" values= of "rph" is as
   follows:

   The verification service MUST extract the value associated w= ith the
   "auth" key in a full form PASSPorT with a "ppt" value of "r= ph".  If
   the signature validates, then the verification service can u= se the
   value of the "rph" claim as validation that the calling par= ty is
   authorized for Resource-Priority, which would in turn be us= ed for

 

Single quotes around 'Resource-Priority'.

This text is ambiguous about whether the validation indicates that the ca= lling party is authorized to use the priorities indicated in the passport ob= ject, or the values in the SIP 'Resource-Priority' header field; and (taken o= n its face) implies the latter, when the intention here should clearly be the former.

"...authorized for 'Resource-Priority' indicated in the claim. This value= would in turn be used for..."

The text also needs to say something about comparing values in the claim t= o values in the 'Resource-Priority' header field, and what a mismatch might m= ean. The document says elsewhere that the signature might only cover some of= the r-values, which makes it entirely possible that the 'Resource-Priority' field might contain more v= alues than are signed. On the other hand, intermediaries might reasonably re= move r-values as the call is processed. This probably means that those remov= ed priorities should not be used, even if they are present in the passport. It seems reasonable to say t= hat *typical* processing by a receiving party would be to take the *union* o= f all RPH passports that they trust, and *intersect* that with the prioritie= s in 'Resource-Priority' header fields to get the actual priority or priorities to be applied to the call (= subject to local policy).

 

   priority treatment= in accordance with local policy for the associated
   communication service.

   In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 r= equires
   "iat" value in "rph" claim to be verified.

   The behavior of a SIP UAs upon receiving an INVITE containi= ng a

 

"...of a SIP UA upon..."

or

"...of SIP UAs upon..."

 

   PASSporT object wi= th a "rph" claim will largely remain a matter of
   implementation policy for the specific communication servic= e.  In
   most cases,implementations would act based on confidence in= the

 

"...cases, implementations..."

(space after comma)

 

   veracity of this i= nformation.  The use of the compact form of

 

Paragraph break before "The".

 

   PASSporT is not sp= ecified in this document.

5.  Further Information Associated with Resource-Priority

 

Single quotes around 'Resource-Priority'.

 


   There may be additional information about the calling party= or the
   call that could be relevant to authorization for Resource-P= riority.

 

Single quotes around 'Resource-Priority'.

 

   This may include i= nformation related to the device subscription of
   the caller, or to any institutions that the caller or devic= e is
   associated with, or even categories of institutions.  A= ll of these
   data elements would benefit from the secure attestations pr= ovided by
   the STIR and PASSporT frameworks.  The specification o= f the "rph"
   claim could entail the optional presence of one or more suc= h
   additional information fields.

   A new IANA registry has been defined to hold potential valu= es of the
   "rph" array; see Section 6.2.  The definition of the "= rph" claim may
   have one or more such additional information field(s). = ; Details of
   such "rph" claim to encompass other data elements are left f= or future
   version of this specification.

6.  IANA Considerations

6.1.  JSON Web Token Claims Registration

=

 

I think there's some confusion here. You're registering a PASSporT ppt va= lue, not a new JWT claim. That is to say, you're adding an entry to this tab= le:

https://www.iana.org/assignments/passport/passport.xhtml

Not to this table:

https://www.iana.org/assignments/jwt/jwt.xhtml

You would only use the second table if you had a new key to add to the PA= SSporT header -- this specification does not do that.

This section also needs some introductory text to let the IANA know exact= ly what to do; e.g. "This document registers a new value for the "Personal A= ssertion Token (PASSporT) Extensions" table.


   o  ppt value: "rph"

   o  Specification Document(s): Section 3 of [RFCThis]

6.2.  PASSporT 'rph' Types

   This document requests that the IANA add a new entry to the= PASSporT
   Types registry for the type "rph" which is specified in [RFC= This].

 

There isn't an IANA table called "PASSporT Types." I presume this is the r= egistration we just discussed in section 6.1, and so the above two lines can= be removed.

 

   This specification= also requests that the IANA create a new registry
   for PASSporT "rph" types.  Registration of new PASSpor= T "rph" types
   shall be under the specification required policy.  Thi= s registry is
   to be initially populated with a single value for "auth" wh= ich is
   specified in [RFCThis].

 

This needs to be very clear about the fields to be included in this new r= egistry (e.g., "Registry entries must contain two fields: the name of the 'r= ph' type and the specification in which the type is described").<= /p>

 


7.  Security Considerations

   The security considerations discussed in [I-D.ietf-stir-rfc= 4474bis]
   in Section 10 are applicable here.

7.1.  Avoidance of replay and cut and paste attacks

   The PASSporT extension with a "ppt" value of "rph" MUST onl= y be sent
   with SIP INVITE when 'Resource-Priority' header is used to c= onvey the

 

"...header field..."

 

   priority of the co= mmunication as defined in [RFC4412].  To avoid the
   replay, and cut and paste attacks, the procedures described= in
   Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed= .

7.2.  Solution Considerations

   The use of extension to PASSporT tokens with "ppt" value "r= ph" based
   on the validation of the digital signature and the associat= ed
   certificate requires consideration of the authentication an= d
   authority or reputation of the signer to attest to the iden= tity being
   asserted.  The following considerations should be reco= gnized when
   using PASSporT extension with "ppt" value of "rph":
   o  An authority (signer) is only allowed to sign the c= ontent of a SIP
      'Resource-Priority' header for which it h= as the right authority.

 

"...header field..."

 

      T= he authority that signs the token MUST have a secure method for<= span style=3D"font-size:10.0pt;font-family:"Courier New"">
      authentication of the end user or the dev= ice.

   o  The verification of the signature MUST include mean= s of verifying
      that the signer is authoritative for the s= igned content of the SIP

 

It's not clear what authority is being claimed here. Is this supposed to m= ean something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource prio= rity namespace in the PASSporT?" Whatever the server is purportedly authoritative for needs to be clearly sp= elled out.

 

      '= Resource-Priority' header.

 

"...header field."

 

/a


_______________________________________________
stir mailing list
stir@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/stir

 

= --Apple-Mail-DDE31DDA-26B7-4EB7-BDE8-37432C4CAA78-- From nobody Sun Feb 4 15:00:24 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3260E129BBF; Sun, 4 Feb 2018 15:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1o3x8IbDtKf5; Sun, 4 Feb 2018 15:00:19 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17886120725; Sun, 4 Feb 2018 15:00:18 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id s9so16853280pgq.13; Sun, 04 Feb 2018 15:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ez/oKEJPh2AEi4HfbK/t/rI3KlAmAfJolgM/1Nlkzlg=; b=RLeCRI3LXbhnFV8sXlyUedqNcPQq3RZsX8u/AlL9ZFLp/S9hu73PVJcKFwB25jg2l8 apsuMfDh6q6VwnDNLwSadxvlKPz6Og6+bDvBOfYebA5/BzylzN2lndWCuQLGcX7JyGZt R7jS6ssP7VAdfIBkeSJMLQzglCC5epphyqILC6pLeCExXUl385jO1bvF4A6atQZc6/Ch Hc7I5m9geCIFuatmBOKmdB6xMICMCyX7xpErlM6GHhRvBLf3cSCUwngIN3wZTc7Uib/i Aii6modCTQscfUHDSGV5mWrfNyoMnxjrtv8NiueRKnQV7O7szeF8L9H3Ku3QzJKmghhK aoeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ez/oKEJPh2AEi4HfbK/t/rI3KlAmAfJolgM/1Nlkzlg=; b=Ga9QBtPmlLACbYcdL+HHRo9DkRKkbcHb34rl3G0qypQjZdMpjnnVFyK5xPCz+zfTV4 HWOncwMa81Bo1zQwwSWFufRiv3cpuipBFWRBy11PjVQy9plVHgsMKwIAg3ARoPR4w82N sSYbSIIcQAcY2MDyVyac+VDwM9B2SKvLJGHzQUvrL7XJS3wKEdo6dKHux2f8Ck2qzvX9 J18n/0v2Hx8AQJi2bO2OZKsd3PnXS8z0TCHW0VLIpwkoKBBCvnUeyC85F0RSpIhfwyeq 68n0uCqmAcciR4Q8GdoSuxZizsEwE/v/yIAjprG3be2EtDbPdmEmg5Ztd5sL/rakRdxE j69g== X-Gm-Message-State: AKwxyteBxDY8u3DoIxLlRE9v+E/iIc9tzewU3/LdnJy4jWkKj9vlpdNs XPy6VbDavtywk8D5LUybAFpBnaNF X-Google-Smtp-Source: AH8x225Bo3EZCo/yEYimM6I02cDIoPepu3veeB34TOsVhRJNFdBl9SZ/qXNiXkF4ARk0U0uZkWpoGw== X-Received: by 10.101.101.149 with SMTP id u21mr10160455pgv.251.1517785216552; Sun, 04 Feb 2018 15:00:16 -0800 (PST) Received: from [100.99.176.227] (198.sub-174-214-12.myvzw.com. [174.214.12.198]) by smtp.gmail.com with ESMTPSA id v81sm14572231pfi.65.2018.02.04.15.00.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 15:00:15 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-3BA3D7FD-F093-477C-A67E-9D2C7C6BE988 Mime-Version: 1.0 (1.0) From: Subir X-Mailer: iPhone Mail (14D27) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C153D09@ESESSMB109.ericsson.se> Date: Mon, 5 Feb 2018 04:30:09 +0530 Cc: "stir@ietf.org" , Adam Roach , STIR Chairs , "draft-ietf-stir-rph.all@tools.ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <12906B31-4E2A-4DAA-AF14-27C7C3683790@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153D09@ESESSMB109.ericsson.se> To: Christer Holmberg Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 23:00:23 -0000 --Apple-Mail-3BA3D7FD-F093-477C-A67E-9D2C7C6BE988 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable No it is not always true. Any intermediary can add RPH and we added the tex= t to clarify such a behavior per AD comment.=20 Sent from my iPhone > On Feb 4, 2018, at 10:43 PM, Christer Holmberg wrote: >=20 > =81cand, if RPH is only supposed to be used by the originating network, I t= hink it would be good to say that more explicit. > =20 > Regards, > =20 > Christer > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 04 February 2018 18:34 > To: Subir Das > Cc: stir@ietf.org; Adam Roach ; STIR Chairs ; draft-ietf-stir-rph.all@tools.ietf.org > Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to asser= t the callers identity assumed? > =20 > Hi, > =20 > The text says: > =20 > =81gThe credentials (e.g., authority responsible for authorizing Resour= ce- > Priority) used to create the signature must have authority over the > namespace of the "rph" claim and there is only one authority per > claim.=81h > =20 > If the credentials don=81ft need to have authority of the other claims (e.= g., =81gorig=81h) in the RPH PASSPorT I think you should explicitly say so. > =20 > Regards, > =20 > Christer > =20 > =20 > From: Subir Das [mailto:subirdas21@gmail.com]=20 > Sent: 02 February 2018 01:04 > To: Christer Holmberg > Cc: Adam Roach ; STIR Chairs ; sti= r@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org > Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to asser= t the callers identity assumed? > =20 > Hello Christer, > The signing entity does not have always the authority to assert the caller= identity in rph. We are submitting ver-03 draft and it is clarified as fo= llows: > "The credentials (e.g., authority responsible for authorizing Resource-Pri= ority) used to create the signature must have authority over the namespace o= f the=81grph" claim.." > =20 > -Subir > =20 > On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg wrote: > Hi, > =20 > Another question for clarification. > =20 > Section 3 contains the following example: > =20 > { "orig":{"tn":"12155551212"} > "dest":{["tn":"12125551213"]}, > "iat":1443208345, > "rph":{"auth":["ets.0","wps.0"]} > =20 > =81cand the following text: > =20 > =81gThe credentials (e.g., authority responsible for authorizing Resour= ce- > Priority) used to create the signature must have authority over the > "rph" claim=81c=81h > =20 > Since the claim also contains =81gorig=81h, is the assumption that the sig= ning entity always also has authority to assert the callers identity? I thin= k it would be good to explicitly mention it. > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > =20 > =20 > =20 > From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 20 January 2018 00:15 > To: STIR Chairs ; stir@ietf.org; draft-ietf-stir-rph= .all@tools.ietf.org > Subject: [stir] AD Review: draft-ietf-stir-rph-02 > =20 > I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who h= as worked on this document, and the authors and chairs in particular. >=20 > The technical content here looks generally good to me. I'd like to see a f= ew issues addressed before IETF LC. In short sumary: >=20 > The validation section needs to add a discussion of how to treat calls whe= n the priority values in "rph" passports and SIP "Resource-Priority" header f= ields aren't 100% identical. > The examples need some adjustment. > There is a minor point of ambiguity in the Security Section, but this shou= ld be easy to fix, as long as the WG knows what was intended. > The IANA actions need a little bit of adjustment. > There are a number of minor editorial issues to be cleaned up. > Detailed comments on these points are inline in the document below. I've r= emoved some portions of the document on which I have no comments. >=20 > =20 >=20 >=20 > Abstract >=20 > This document extends the STIR PASSporT specification to allow the > =20 >=20 > "...the Secure Telephone Identity Revisited (STIR) Personal Assertion Toke= n (PASSporT) specification defined in RFC 8122..." >=20 > (See for guida= nce on abbreviations) >=20 > =20 >=20 > inclusion of cryptographically-signed assertions of authorization for > the values populated in the SIP 'Resource-Priority' header field, > which is used for communications resource prioritization. >=20 > ... >=20 > 1. Introduction >=20 > PASSporT [I-D.ietf-stir-passport] is a token format based on JWT > [RFC7519] for conveying cryptographically-signed information about > the identities involved in personal communications; it is used with > STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the > identity of the participants in real-time communications established > via a protocol like SIP. This specification extends PASSporT to > =20 >=20 > "...like SIP [RFC3261]..." >=20 > (We want to cite SIP the first time it is mentioned) >=20 > =20 >=20 > allow cryptographic-signing of the SIP 'Resource-Priority' header > field defined in [RFC4412]. >=20 > [RFC4412] defines the SIP 'Resource-Priority' header field for > communications Resource Priority. As specified in [RFC4412], the > 'Resource-Priority' header field may be used by SIP user agents > [RFC3261], including, Public Switched Telephone Network (PSTN) > =20 >=20 > "...including Public Switched..." >=20 > (remove the comma) >=20 > =20 >=20 > gateways and terminals, and SIP proxy servers to influence > =20 >=20 > "...and by SIP proxy servers, to influence..." >=20 > (add "by" and comma) >=20 > =20 >=20 > prioritization afforded to communication sessions,including PSTN > =20 > "...sessions, including..." >=20 > (space after comma) >=20 > =20 >=20 > calls. However, the SIP 'Resource-Priority' header field could be > spoofed and abused by unauthorized entities. >=20 > The STIR architecture [RFC7340]assumes that an authority on the > =20 >=20 > "...STIR architecture [RFC7340] assumes..." >=20 > (space before "assumes") >=20 > =20 >=20 > originating side of a call provides a cryptographic assurance of the > validity of the calling party number in order to prevent > impersonation attacks. The STIR architecture allows extension that > =20 >=20 > "...allows extensions..." >=20 > =20 >=20 > can be utilized by authorities supporting real-time communication > services using the 'Resource-Priority' header field to > cryptographically sign the SIP 'Resource-Priority' header field and > convey assertion of the authorization for 'Resource-Priority'. For > example, the authority on the originating side verifying the > authorization of a particular communication for Resource-Priority can > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > =20 >=20 > use a PASSPorT claim to cryptographically-sign the SIP 'Resource- > =20 >=20 > "...cryptographically sign..." >=20 > =20 >=20 > Priority' header field and convey an assertion of the authorization > for 'Resource-Priority'. This will allow a receiving entity > (including entities located in different network domains/boundaries) > to verify the validity of assertions authorizing Resource-Priority. > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > =20 >=20 > Cryptographically-signed SIP 'Resource-Priority' headers will allow a > =20 >=20 > "...cryptographically signed SIP 'Resource-Priority' header fields..." >=20 > (remove hyphen, and replace "headers" with "header fields") >=20 > =20 >=20 > receiving entity to verify and act on the information with confidence > that the information have not been spoofed or compromised. > =20 >=20 > "...has not been spoofed or compromised." >=20 > =20 >=20 >=20 > This specification documents an optional extension to PASSporT and > the associated STIR mechanisms to provide a function to sign the SIP > 'Resource-Priority' header field. This PASSporT object is used to > provide attestation of a calling user authorization for priority > communications. This is necessary in addition to the PASSporT object > that is used for calling user telephone number attestation. How the > optional extension to PASSporT is used for real-time communications > supported using SIP 'Resource-Priority' header field is defined in > other documents and is outside the scope of this document. > =20 >=20 > I assume these other documents are under development? If so, they should b= e cited here. >=20 > =20 >=20 >=20 > 2. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > =20 >=20 > This document has several non-normative uses of "must", "should," and "may= ," and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boi= lerplate. >=20 > =20 >=20 >=20 > 3. PASSporT 'rph' Claim >=20 > This specification defines a new JSON Web Token claim for "rph", > which provides an assertion for information in SIP 'Resource- > Priority'header. > =20 >=20 > "...Priority' header field." >=20 > (space after closing quotation mark, "header field" instead of "header") >=20 > =20 >=20 >=20 > The creator of a PASSporT object adds a "ppt" value of "rph" to the > header of a PASSporT object, in which case the PASSporT claims MUST > contain a "rph" claim, and any entities verifying the PASSporT object > will be required to understand the "ppt" extension in order to > process the PASSporT in question. A PASSPorT header with the "ppt" > included will look as follows: >=20 > { "typ":"passport", > "ppt":"rph", > "alg":"ES256", > "x5u":"https://www.example.org/cert.cer"} > =20 >=20 > Ideally, this would be either pretty-printed or canonicalized. Since it's t= oo long to fit on a line in canonical form, I propose: >=20 > { > "typ":"passport", > "ppt":"rph", > "alg":"ES256", > "x5u":"https://www.example.org/cert.cer" > } >=20 > =20 >=20 >=20 > The "rph" claim will provide an assertion of authorization,"auth", > =20 >=20 > "...authorization, "auth", ..." >=20 > (space between comma and opening quotation mark) >=20 > =20 >=20 > for information in the SIP "Resource-Priority" header field (i.e., > Resource-Priority: namespace "." r-priority) based on [RFC4412]. > =20 >=20 > The use of the string 'namespace "." r-priority' here and elsewhere in the= document has a detrimental impact on readability. I strongly suggest replac= ing it with "r-value" (the name of this production in RFC4412) everywhere. >=20 > =20 >=20 > Specifically, the "rph" claim includes assertion of the priority- > level of the user to be used for a given communication session. The > value of the "rph" claim is an array containing one or more of JSON > objects for the content of the SIP 'Resource-Priority' header that is > being asserted of which one of the "rph" object, is mandatory. > =20 >=20 > This last sentence is very hard to parse; and (based on the example) the v= alue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object with= one or more keys. Each key is associated with a JSON Array. These arrays c= ontain Strings that correspond to the r-values indicated in the SIP "Resourc= e-Priority" header field.' (note: "header field", not "header") >=20 > =20 >=20 >=20 > The following is an example "rph" claim for a SIP "Resource-Priority" > header field with a "namespace "." r-priority" value of "ets.0" and > with a "namespace "." r-priority" value of "wps.0". >=20 > { "orig":{"tn":"12155551212"} > "dest":{["tn":"12125551213"]}, > "iat":1443208345, > "rph":{"auth":["ets.0","wps.0"]} > =20 >=20 > As above, I recommend pretty-printing this. It's also missing a comma afte= r the "orig" value, and the top-level structure is missing a closing brace. T= he value for "iat" needs to be enclosed in quotes. >=20 > The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much o= f which remains assignable (cf ). >=20 > Putting all this together, I believe what you want is: >=20 > { > "orig":{"tn":"12155550112"}, > "dest":{["tn":"12125550113"]}, > "iat":"1443208345", > "rph":{"auth":["ets.0","wps.0"]} > } >=20 > =20 >=20 >=20 > After the header and claims PASSporT objects have been constructed, > their signature is generated normally per the guidance in > [I-D.ietf-stir-passport] using the full form of PASSPorT. The > credentials (e.g., authority responsible for authorizing Resource- > Priority) used to create the signature must have authority over the > "rph" claim and there is only one authority per claim. The authority > MUST use its credentials (i.e., CERT) associated with the specific > service supported by the SIP namespace in the claim. >=20 > 4. 'rph' in SIP >=20 > This section specifies SIP-specific usage for the "rph" claim in > PASSporT. >=20 > 4.1. Authentication Service Behavior >=20 > The Authentication Service will create the "rph" claim using the > values discussed in section 3 based on [RFC4412]. The construction > of "rph" claim follows the steps described in Section 4 of > [I-D.ietf-stir-rfc4474bis]. >=20 > The resulting Identity header for "rph" might look as follows: > =20 >=20 > "...header field..." >=20 > =20 >=20 >=20 > "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd > ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO > aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW > EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW > pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR > VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z > aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D > l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ > oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256; > ppt=3D"rph" > =20 >=20 > This example has a number of issues: >=20 > In the Identity header field, the signed-identity-digest shouldn't be quot= ed. > In the Identity header field, info is enclosed in <> rather than "". > In the Identity header field, ppt is a token rather than a quoted string. > The signed-identity-digest header needs to indicate a "typ" of "passport" r= ather than JWT, and it needs to include both a "ppt" and "x5u" field. > The signed-identity-digest body should contain only the passport claim rat= her than a JSON object that itself contains a base64-encoded JWS header conc= atenated with a claim. > I believe that, even when the body is included, values in the header and b= ody need to be be canonicalized (i.e., all on one line, no spaces, in alphab= etical order, etc.) > I would also recommend following the convention of indicating that line-wr= aps are only for readability, and including the header field name in the exa= mple. Putting all this together, I believe what you want is: >=20 > For example, a Identity header field for "rph" might look > as follows (backslashes shown for line folding only): >=20 > Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ > iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ > Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ > 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ > AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ > 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D >;alg=3DES256;ppt=3Drph >=20 > (Note: this example assumes the calling and called party numbers in the pr= evious example are changed to 12155550112 and 12155550113, respectively) >=20 > =20 >=20 >=20 > A SIP authentication service typically will derive the value of "rph" > from the 'Resource-Priority' header field based on policy associated > with service specific use of the "namespace "." r-priority" values > based on [RFC4412]. The authentication service derives the value of > the PASSPorT claim by verifying the authorization for Resource- > Priority (i.e., verifying a calling user privilege for Resource- > Priority based on its identity) which might be derived from customer > profile data or from access to external services. >=20 > [RFC4412] allows multiple "namespace "." r-priority" pairs, either in > a single SIP Resource-Priority header or across multiple SIP > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header field..." >=20 > =20 >=20 > Resource-Priority headers. However, it is not necessary to sign all > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header fields..." >=20 > =20 >=20 > content of a SIP Resource-Priority header or all SIP Resource- > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header field..." >=20 > =20 >=20 > Priority headers in a given SIP message. An authority is only > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header fields..." >=20 > =20 >=20 > responsible for signing the content of a SIP Resource-Priority header > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > "...header field..." >=20 > =20 >=20 > for which it has authority (e.g., a specific "namespace "." > r-priority"). >=20 > 4.2. Verification Service Behavior >=20 > [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that > specifications defining "ppt" values describe any additional verifier > behavior. The behavior specified for the "ppt" values of "rph" is as > follows: >=20 > The verification service MUST extract the value associated with the > "auth" key in a full form PASSPorT with a "ppt" value of "rph". If > the signature validates, then the verification service can use the > value of the "rph" claim as validation that the calling party is > authorized for Resource-Priority, which would in turn be used for > =20 > Single quotes around 'Resource-Priority'. >=20 > This text is ambiguous about whether the validation indicates that the cal= ling party is authorized to use the priorities indicated in the passport obj= ect, or the values in the SIP 'Resource-Priority' header field; and (taken o= n its face) implies the latter, when the intention here should clearly be th= e former. >=20 > "...authorized for 'Resource-Priority' indicated in the claim. This value w= ould in turn be used for..." >=20 > The text also needs to say something about comparing values in the claim t= o values in the 'Resource-Priority' header field, and what a mismatch might m= ean. The document says elsewhere that the signature might only cover some of= the r-values, which makes it entirely possible that the 'Resource-Priority'= field might contain more values than are signed. On the other hand, interme= diaries might reasonably remove r-values as the call is processed. This prob= ably means that those removed priorities should not be used, even if they ar= e present in the passport. It seems reasonable to say that *typical* process= ing by a receiving party would be to take the *union* of all RPH passports t= hat they trust, and *intersect* that with the priorities in 'Resource-Priori= ty' header fields to get the actual priority or priorities to be applied to t= he call (subject to local policy). >=20 > =20 >=20 > priority treatment in accordance with local policy for the associated > communication service. >=20 > In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires > "iat" value in "rph" claim to be verified. >=20 > The behavior of a SIP UAs upon receiving an INVITE containing a > =20 >=20 > "...of a SIP UA upon..." >=20 > or >=20 > "...of SIP UAs upon..." >=20 > =20 >=20 > PASSporT object with a "rph" claim will largely remain a matter of > implementation policy for the specific communication service. In > most cases,implementations would act based on confidence in the > =20 >=20 > "...cases, implementations..." >=20 > (space after comma) >=20 > =20 >=20 > veracity of this information. The use of the compact form of > =20 >=20 > Paragraph break before "The". >=20 > =20 >=20 > PASSporT is not specified in this document. >=20 > 5. Further Information Associated with Resource-Priority > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > =20 >=20 >=20 > There may be additional information about the calling party or the > call that could be relevant to authorization for Resource-Priority. > =20 >=20 > Single quotes around 'Resource-Priority'. >=20 > =20 >=20 > This may include information related to the device subscription of > the caller, or to any institutions that the caller or device is > associated with, or even categories of institutions. All of these > data elements would benefit from the secure attestations provided by > the STIR and PASSporT frameworks. The specification of the "rph" > claim could entail the optional presence of one or more such > additional information fields. >=20 > A new IANA registry has been defined to hold potential values of the > "rph" array; see Section 6.2. The definition of the "rph" claim may > have one or more such additional information field(s). Details of > such "rph" claim to encompass other data elements are left for future > version of this specification. >=20 > 6. IANA Considerations >=20 > 6.1. JSON Web Token Claims Registration > =20 >=20 > I think there's some confusion here. You're registering a PASSporT ppt val= ue, not a new JWT claim. That is to say, you're adding an entry to this tabl= e: >=20 > https://www.iana.org/assignments/passport/passport.xhtml >=20 > Not to this table: >=20 > https://www.iana.org/assignments/jwt/jwt.xhtml >=20 > You would only use the second table if you had a new key to add to the PAS= SporT header -- this specification does not do that. >=20 > This section also needs some introductory text to let the IANA know exactl= y what to do; e.g. "This document registers a new value for the "Personal As= sertion Token (PASSporT) Extensions" table. >=20 >=20 > o ppt value: "rph" >=20 > o Specification Document(s): Section 3 of [RFCThis] >=20 > 6.2. PASSporT 'rph' Types >=20 > This document requests that the IANA add a new entry to the PASSporT > Types registry for the type "rph" which is specified in [RFCThis]. > =20 >=20 > There isn't an IANA table called "PASSporT Types." I presume this is the r= egistration we just discussed in section 6.1, and so the above two lines can= be removed. >=20 > =20 >=20 > This specification also requests that the IANA create a new registry > for PASSporT "rph" types. Registration of new PASSporT "rph" types > shall be under the specification required policy. This registry is > to be initially populated with a single value for "auth" which is > specified in [RFCThis]. > =20 >=20 > This needs to be very clear about the fields to be included in this new re= gistry (e.g., "Registry entries must contain two fields: the name of the 'rp= h' type and the specification in which the type is described"). >=20 > =20 >=20 >=20 > 7. Security Considerations >=20 > The security considerations discussed in [I-D.ietf-stir-rfc4474bis] > in Section 10 are applicable here. >=20 > 7.1. Avoidance of replay and cut and paste attacks >=20 > The PASSporT extension with a "ppt" value of "rph" MUST only be sent > with SIP INVITE when 'Resource-Priority' header is used to convey the > =20 >=20 > "...header field..." >=20 > =20 >=20 > priority of the communication as defined in [RFC4412]. To avoid the > replay, and cut and paste attacks, the procedures described in > Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. >=20 > 7.2. Solution Considerations >=20 > The use of extension to PASSporT tokens with "ppt" value "rph" based > on the validation of the digital signature and the associated > certificate requires consideration of the authentication and > authority or reputation of the signer to attest to the identity being > asserted. The following considerations should be recognized when > using PASSporT extension with "ppt" value of "rph": >=20 > o An authority (signer) is only allowed to sign the content of a SIP > 'Resource-Priority' header for which it has the right authority. > =20 >=20 > "...header field..." >=20 > =20 >=20 > The authority that signs the token MUST have a secure method for > authentication of the end user or the device. >=20 > o The verification of the signature MUST include means of verifying > that the signer is authoritative for the signed content of the SIP > =20 >=20 > It's not clear what authority is being claimed here. Is this supposed to m= ean something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource prio= rity namespace in the PASSporT?" Whatever the server is purportedly authorit= ative for needs to be clearly spelled out. >=20 > =20 >=20 > 'Resource-Priority' header. > =20 >=20 > "...header field." >=20 > =20 >=20 > /a >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >=20 > =20 --Apple-Mail-3BA3D7FD-F093-477C-A67E-9D2C7C6BE988 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
No it is not always true.  Any in= termediary can add RPH and we added the text to clarify such a behavior per A= D comment. 

Sent from my iPhone

On Feb 4, 2018, at= 10:43 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

=E2=80=A6and= , if RPH is only supposed to be used by the originating network, I think it w= ould be good to say that more explicit.

 <= /o:p>

Regards,

 <= /o:p>

Christer

 

From: sti= r [mailto:stir-bounces@ietf.org= ] On Behalf Of Christer Holmberg
Sent: 04 February 2018 18:34
To: Subir Das <subirdas21@= gmail.com>
Cc: stir@ietf.org; Adam Roach &l= t;adam@nostrum.com>; STIR Chairs &= lt;stir-chairs@ietf.org>; draft-ietf-stir-rph.al= l@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to a= ssert the callers identity assumed?

 

Hi,

 <= /o:p>

The text say= s:

 <= /o:p>

  = =E2=80=9CThe credentials (e.g., authority responsible for authorizing Resou= rce-

  = Priority) used to create the signature must have authority over the

  = namespace of the "rph" claim and there is only one authority per=

  = claim.=E2=80=9D

 <= /o:p>

If the crede= ntials don=E2=80=99t need to have authority of the other claims (e.g., =E2=80= =9Corig=E2=80=9D) in the RPH PASSPorT I think you should explicitly say so.

 <= /o:p>

Regards,

 <= /o:p>

Christer

 <= /o:p>

 <= /o:p>

From: Sub= ir Das [mailto:subirdas21@gmail.com<= /a>]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.c= om>; STIR Chairs <stir-cha= irs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to a= ssert the callers identity assumed?

 

Hello Christer,

The signing entity does not have always the authority= to assert the caller identity in rph. We are submitting ver-03 draft  a= nd it is clarified  as follows:

"The credentials (e.g., authority respo= nsible for authorizing Resource-Priority) used to create the signature must h= ave authority over the namespace of the=E2=80=9Crph" claim.."

 

-Subir

 

On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg &l= t;christ= er.holmberg@ericsson.com> wrote:

Hi,

 

Another question for clarification.<= /p>

 

Section 3 contains the following example:<= /o:p>

 

    { "orig":{"tn":"12155551212"= }

     "dest":{["tn":"12125551213"]},

     "iat":1443208345,=

     "rph":{"auth":["ets.0","wps.0= "]}

 

=E2=80=A6and the following text:

=

 

   =E2=80=9CThe credentials (e.g., authority= responsible for authorizing Resource-

   Priority) used to create the signature mu= st have authority over the

   "rph" claim=E2=80=A6=E2=80=9D

&nb= sp;

Since the claim also contains =E2=80=9Corig=E2=80=9D, i= s the assumption that the signing entity always also has authority to assert the callers identity? I think it would be good to explicitly ment= ion it.

 

Regards,

 

Christer

 

 

 

 

 

 

From: stir [mailto:<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri"= ;,sans-serif">stir-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org>; sti= r@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: [stir] AD Review: draft-ietf-stir-rph-02

 

I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who h= as worked on this document, and the authors and chairs in particular.

The technical content here looks generally good to me. I'd like to see a f= ew issues addressed before IETF LC. In short sumary:

  • The validation section needs to add a discussion of how to treat calls when t= he priority values in "rph" passports and SIP "Resource-Priority" header fie= lds aren't 100% identical.
  • The examples need some adjustment.
  • There is a minor point of ambiguity in the Security Section, but this should= be easy to fix, as long as the WG knows what was intended.
    • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-al= t:auto;mso-list:l0 level1 lfo3"> The IANA actions need a little bit of adjustment.
  • There are a number of minor editorial issues to be cleaned up.

Detailed comments on these points are inline in the document below. I've r= emoved some portions of the document on which I have no comments.=

 


Abstract

   This document extends the STIR PASSporT specification to al= low the

 

"...the Secure Telephone Identity Revisited (STIR) Personal Assertion Tok= en (PASSporT) specification defined in RFC 8122..."

(See <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for gu= idance on abbreviations)

 

   inclusion of crypt= ographically-signed assertions of authorization for
   the values populated in the SIP 'Resource-Priority' header f= ield,
   which is used for communications resource prioritization.

...

1.  Introduction

   PASSporT [I-D.ietf-stir-passport] is a token format based o= n JWT
   [RFC7519] for conveying cryptographically-signed informatio= n about
   the identities involved in personal communications; it is u= sed with
   STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertio= n of the
   identity of the participants in real-time communications es= tablished
   via a protocol like SIP.  This specification extends P= ASSporT to

 

"...like SIP [RFC3261]..."

(We want to cite SIP the first time it is mentioned)

 

   allow cryptographi= c-signing of the SIP 'Resource-Priority' header
   field defined in [RFC4412].

   [RFC4412] defines the SIP 'Resource-Priority' header field f= or
   communications Resource Priority.  As specified in [RFC= 4412], the
   'Resource-Priority' header field may be used by SIP user ag= ents
   [RFC3261], including, Public Switched Telephone Network (PS= TN)

 

"...including Public Switched..."

(remove the comma)

 

   gateways and termi= nals, and SIP proxy servers to influence

 

"...and by SIP proxy servers, to influence..."

(add "by" and comma)

 

   prioritization aff= orded to communication sessions,including PSTN

 

"...sessions, including..."

(space after comma)

 

   calls.  Howev= er, the SIP 'Resource-Priority' header field could be
   spoofed and abused by unauthorized entities.

   The STIR architecture [RFC7340]assumes that an authority on= the

 

"...STIR architecture [RFC7340] assumes..."

(space before "assumes")

 

   originating side o= f a call provides a cryptographic assurance of the
   validity of the calling party number in order to prevent
   impersonation attacks.  The STIR architecture allows e= xtension that

 

"...allows extensions..."

 

   can be utilized by= authorities supporting real-time communication
   services using the 'Resource-Priority' header field to=
   cryptographically sign the SIP 'Resource-Priority' header f= ield and
   convey assertion of the authorization for 'Resource-Priorit= y'.  For
   example, the authority on the originating side verifying th= e
   authorization of a particular communication for Resource-Pr= iority can

 

Single quotes around 'Resource-Priority'.

 

   use a PASSPorT cla= im to cryptographically-sign the SIP 'Resource-

 

"...cryptographically sign..."

 

   Priority' header f= ield and convey an assertion of the authorization
   for 'Resource-Priority'.  This will allow a receiving e= ntity
   (including entities located in different network domains/bo= undaries)
   to verify the validity of assertions authorizing Resource-P= riority.

 

Single quotes around 'Resource-Priority'.

 

   Cryptographically-= signed SIP 'Resource-Priority' headers will allow a

 

"...cryptographically signed SIP 'Resource-Priority' header fields..."

(remove hyphen, and replace "headers" with "header fields")

 

   receiving entity t= o verify and act on the information with confidence
   that the information have not been spoofed or compromised.<= /tt>

 

"...has not been spoofed or compromised."

 


   This specification documents an optional extension to PASSp= orT and
   the associated STIR mechanisms to provide a function to sig= n the SIP
   'Resource-Priority' header field.  This PASSporT objec= t is used to
   provide attestation of a calling user authorization for pri= ority
   communications.  This is necessary in addition to the P= ASSporT object
   that is used for calling user telephone number attestation.=   How the
   optional extension to PASSporT is used for real-time commun= ications
   supported using SIP 'Resource-Priority' header field is def= ined in
   other documents and is outside the scope of this document.<= /tt>

 

I assume these other documents are under development? If so, they should b= e cited here.

 


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHA= LL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL= " in this
   document are to be interpreted as described in RFC 2119 [RFC= 2119].

 

This document has several non-normative uses of "must", "should," and "ma= y," and so it needs to use the RFC8174 boilerplate instead of the RFC2119 bo= ilerplate.

 


3.  PASSporT 'rph' Claim

   This specification defines a new JSON Web Token claim for "= rph",
   which provides an assertion for information in SIP 'Resourc= e-
   Priority'header.

 

"...Priority' header field."

(space after closing quotation mark, "header field" instead of "header")<= o:p>

 


   The creator of a PASSporT object adds a "ppt" value of "rph= " to the
   header of a PASSporT object, in which case the PASSporT cla= ims MUST
   contain a "rph" claim, and any entities verifying the PASSp= orT object
   will be required to understand the "ppt" extension in order= to
   process the PASSporT in question.  A PASSPorT header w= ith the "ppt"
   included will look as follows:

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.example.org/cert.cer"= }

 

Ideally, this would be either pretty-printed or canonicalized. Since it's= too long to fit on a line in canonical form, I propose:

{
  "typ":"passport",
  "ppt":"rph",
  "alg":"ES256",
  "x5u":"https://www.example.org/cert.cer"
}

 


   The "rph" claim will provide an assertion of authorization,= "auth",

 

"...authorization, "auth", ..."

(space between comma and opening quotation mark)

 

   for information in= the SIP "Resource-Priority" header field (i.e.,
   Resource-Priority: namespace "." r-priority) based on [RFC4= 412].

 

The use of the string 'namespace "." r-priority' here and elsewhere in th= e document has a detrimental impact on readability. I strongly suggest repla= cing it with "r-value" (the name of this production in RFC4412) everywhere.<= o:p>

 

   Specifically, the "= rph" claim includes assertion of the priority-
   level of the user to be used for a given communication sess= ion.  The
   value of the "rph" claim is an array containing one or more= of JSON
   objects for the content of the SIP 'Resource-Priority' head= er that is
   being asserted of which one of the "rph" object, is mandato= ry.

 

This last sentence is very hard to parse; and (based on the example) the v= alue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object with= one or more keys. Each key is associated with a JSON Array. These arrays contain Strings that correspo= nd to the r-values indicated in the SIP "Resource-Priority" header field.' (= note: "header field", not "header")

 


   The following is an example "rph" claim for a SIP "Resource= -Priority"
   header field with a "namespace "." r-priority" value of "et= s.0" and
   with a "namespace "." r-priority" value of "wps.0".
    { "orig":{"tn":"12155551212"}
     "dest":{["tn":"12125551213"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0","wps.0"]}

 

As above, I recommend pretty-printing this. It's also missing a comma aft= er the "orig" value, and the top-level structure is missing a closing brace.= The value for "iat" needs to be enclosed in quotes.

The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much o= f which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).

Putting all this together, I believe what you want is:

{
  "orig":{"tn":"12155550112"},
=   "dest":{["tn":"12125550113"]},=   "iat":"1443208345",
  "rph":{"auth":["ets.0","wps.0"]}
}

 


   After the header and claims PASSporT objects have been cons= tructed,
   their signature is generated normally per the guidance in
   [I-D.ietf-stir-passport] using the full form of PASSPorT.&n= bsp; The
   credentials (e.g., authority responsible for authorizing Re= source-
   Priority) used to create the signature must have authority o= ver the
   "rph" claim and there is only one authority per claim. = ; The authority
   MUST use its credentials (i.e., CERT) associated with the s= pecific
   service supported by the SIP namespace in the claim.
4.  'rph' in SIP

   This section specifies SIP-specific usage for the "rph" cla= im in
   PASSporT.

4.1.  Authentication Service Behavior

   The Authentication Service will create the "rph" claim usin= g the
   values discussed in section 3 based on [RFC4412].  The= construction
   of "rph" claim follows the steps described in Section 4 of<= /tt>
   [I-D.ietf-stir-rfc4474bis].

   The resulting Identity header for "rph" might look as follo= ws:

 

"...header field..."

 


   "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBa= U9pSnd
   ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRl= V6STFO
   aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJ= TOWpaW
   EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBi= aUk2SW
   pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNV= EkxTlR
   VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2= dpT25z
   aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6V= C8HM6D
   l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs= 3fslM_
   oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256;
   ppt=3D"rph"

 

This example has a number of issues:

  • In the Identity header field, the signed-identity-digest shouldn't be quoted= .
  • In the Identity header field, info is enclosed in <> rather than "".
  • In the Identity header field, ppt is a token rather than a quoted string.
  • The signed-identity-digest header needs to indicate a "typ" of "passport" ra= ther than JWT, and it needs to include both a "ppt" and "x5u" field.
  • The signed-identity-digest body should contain only the passport claim rathe= r than a JSON object that itself contains a base64-encoded JWS header concat= enated with a claim.
  • I believe that, even when the body is included, values in the header and bod= y need to be be canonicalized (i.e., all on one line, no spaces, in alphabet= ical order, etc.)

I would also recommend following the convention of indicating that line-w= raps are only for readability, and including the header field name in the ex= ample. Putting all this together, I believe what you want is:

=

   For example, a Identity= header field for "rph" might look
   as follows (backslashes shown for line folding only):<= /span>

   Identity: eyJhbGciOiJFU= zI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \
   iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.= eyJkZXN0 \
   Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiw= ib3JpZyI \
   6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIi= wid3BzLj \
   AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-= n8MIhoCr \
   18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D<https://www.example.org/cer= t.cer \
   >;alg=3DES256;ppt=3Drph

(Note: this example assumes the calling and called party numbers in the prev= ious example are changed to 12155550112 and 12155550113, respectively)

 


   A SIP authentication service typically will derive the valu= e of "rph"
   from the 'Resource-Priority' header field based on policy a= ssociated
   with service specific use of the "namespace "." r-priority"= values
   based on [RFC4412].  The authentication service derive= s the value of
   the PASSPorT claim by verifying the authorization for Resou= rce-
   Priority (i.e., verifying a calling user privilege for Reso= urce-
   Priority based on its identity) which might be derived from= customer
   profile data or from access to external services.

   [RFC4412] allows multiple "namespace "." r-priority" pairs,= either in
   a single SIP Resource-Priority header or across multiple SI= P

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   Resource-Priority h= eaders.  However, it is not necessary to sign all

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

   content of a SIP R= esource-Priority header or all SIP Resource-

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   Priority headers i= n a given SIP message.  An authority is only

=

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

   responsible for si= gning the content of a SIP Resource-Priority header

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   for which it has a= uthority (e.g., a specific "namespace "."
   r-priority").

4.2.  Verification Service Behavior

   [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that=
   specifications defining "ppt" values describe any additiona= l verifier
   behavior.  The behavior specified for the "ppt" values= of "rph" is as
   follows:

   The verification service MUST extract the value associated w= ith the
   "auth" key in a full form PASSPorT with a "ppt" value of "r= ph".  If
   the signature validates, then the verification service can u= se the
   value of the "rph" claim as validation that the calling par= ty is
   authorized for Resource-Priority, which would in turn be us= ed for

 

Single quotes around 'Resource-Priority'.

This text is ambiguous about whether the validation indicates that the ca= lling party is authorized to use the priorities indicated in the passport ob= ject, or the values in the SIP 'Resource-Priority' header field; and (taken o= n its face) implies the latter, when the intention here should clearly be the former.

"...authorized for 'Resource-Priority' indicated in the claim. This value= would in turn be used for..."

The text also needs to say something about comparing values in the claim t= o values in the 'Resource-Priority' header field, and what a mismatch might m= ean. The document says elsewhere that the signature might only cover some of= the r-values, which makes it entirely possible that the 'Resource-Priority' field might contain more v= alues than are signed. On the other hand, intermediaries might reasonably re= move r-values as the call is processed. This probably means that those remov= ed priorities should not be used, even if they are present in the passport. It seems reasonable to say t= hat *typical* processing by a receiving party would be to take the *union* o= f all RPH passports that they trust, and *intersect* that with the prioritie= s in 'Resource-Priority' header fields to get the actual priority or priorities to be applied to the call (= subject to local policy).

 

   priority treatment= in accordance with local policy for the associated
   communication service.

   In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 r= equires
   "iat" value in "rph" claim to be verified.

   The behavior of a SIP UAs upon receiving an INVITE containi= ng a

 

"...of a SIP UA upon..."

or

"...of SIP UAs upon..."

 

   PASSporT object wi= th a "rph" claim will largely remain a matter of
   implementation policy for the specific communication servic= e.  In
   most cases,implementations would act based on confidence in= the

 

"...cases, implementations..."

(space after comma)

 

   veracity of this i= nformation.  The use of the compact form of

 

Paragraph break before "The".

 

   PASSporT is not sp= ecified in this document.

5.  Further Information Associated with Resource-Priority

 

Single quotes around 'Resource-Priority'.

 


   There may be additional information about the calling party= or the
   call that could be relevant to authorization for Resource-P= riority.

 

Single quotes around 'Resource-Priority'.

 

   This may include i= nformation related to the device subscription of
   the caller, or to any institutions that the caller or devic= e is
   associated with, or even categories of institutions.  A= ll of these
   data elements would benefit from the secure attestations pr= ovided by
   the STIR and PASSporT frameworks.  The specification o= f the "rph"
   claim could entail the optional presence of one or more suc= h
   additional information fields.

   A new IANA registry has been defined to hold potential valu= es of the
   "rph" array; see Section 6.2.  The definition of the "= rph" claim may
   have one or more such additional information field(s). = ; Details of
   such "rph" claim to encompass other data elements are left f= or future
   version of this specification.

6.  IANA Considerations

6.1.  JSON Web Token Claims Registration

=

 

I think there's some confusion here. You're registering a PASSporT ppt va= lue, not a new JWT claim. That is to say, you're adding an entry to this tab= le:

https://www.iana.org/assignments/passport/passport.xhtml

Not to this table:

https://www.iana.org/assignments/jwt/jwt.xhtml

You would only use the second table if you had a new key to add to the PA= SSporT header -- this specification does not do that.

This section also needs some introductory text to let the IANA know exact= ly what to do; e.g. "This document registers a new value for the "Personal A= ssertion Token (PASSporT) Extensions" table.


   o  ppt value: "rph"

   o  Specification Document(s): Section 3 of [RFCThis]

6.2.  PASSporT 'rph' Types

   This document requests that the IANA add a new entry to the= PASSporT
   Types registry for the type "rph" which is specified in [RFC= This].

 

There isn't an IANA table called "PASSporT Types." I presume this is the r= egistration we just discussed in section 6.1, and so the above two lines can= be removed.

 

   This specification= also requests that the IANA create a new registry
   for PASSporT "rph" types.  Registration of new PASSpor= T "rph" types
   shall be under the specification required policy.  Thi= s registry is
   to be initially populated with a single value for "auth" wh= ich is
   specified in [RFCThis].

 

This needs to be very clear about the fields to be included in this new r= egistry (e.g., "Registry entries must contain two fields: the name of the 'r= ph' type and the specification in which the type is described").<= /p>

 


7.  Security Considerations

   The security considerations discussed in [I-D.ietf-stir-rfc= 4474bis]
   in Section 10 are applicable here.

7.1.  Avoidance of replay and cut and paste attacks

   The PASSporT extension with a "ppt" value of "rph" MUST onl= y be sent
   with SIP INVITE when 'Resource-Priority' header is used to c= onvey the

 

"...header field..."

 

   priority of the co= mmunication as defined in [RFC4412].  To avoid the
   replay, and cut and paste attacks, the procedures described= in
   Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed= .

7.2.  Solution Considerations

   The use of extension to PASSporT tokens with "ppt" value "r= ph" based
   on the validation of the digital signature and the associat= ed
   certificate requires consideration of the authentication an= d
   authority or reputation of the signer to attest to the iden= tity being
   asserted.  The following considerations should be reco= gnized when
   using PASSporT extension with "ppt" value of "rph":
   o  An authority (signer) is only allowed to sign the c= ontent of a SIP
      'Resource-Priority' header for which it h= as the right authority.

 

"...header field..."

 

      T= he authority that signs the token MUST have a secure method for<= span style=3D"font-size:10.0pt;font-family:"Courier New"">
      authentication of the end user or the dev= ice.

   o  The verification of the signature MUST include mean= s of verifying
      that the signer is authoritative for the s= igned content of the SIP

 

It's not clear what authority is being claimed here. Is this supposed to m= ean something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource prio= rity namespace in the PASSporT?" Whatever the server is purportedly authoritative for needs to be clearly sp= elled out.

 

      '= Resource-Priority' header.

 

"...header field."

 

/a


_______________________________________________
stir mailing list
stir@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/stir

 

= --Apple-Mail-3BA3D7FD-F093-477C-A67E-9D2C7C6BE988-- From nobody Sun Feb 4 16:07:12 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD15C1243F6; Sun, 4 Feb 2018 16:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 VPlnhcsL8pfq; Sun, 4 Feb 2018 16:07:04 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6649A120725; Sun, 4 Feb 2018 16:07:04 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w1506vXC048255; Sun, 4 Feb 2018 19:06:59 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2fx76cbqf6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Feb 2018 19:06:56 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w1505pI6019445; Sun, 4 Feb 2018 19:05:51 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w1505iqh019407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 Feb 2018 19:05:45 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 5 Feb 2018 00:05:33 GMT Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id D9BD1167F66; Mon, 5 Feb 2018 00:05:33 +0000 (GMT) Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (unknown [130.9.129.147]) by zlp27125.vci.att.com (Service) with ESMTPS id 9E525167F64; Mon, 5 Feb 2018 00:05:33 +0000 (GMT) Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.35]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0361.001; Sun, 4 Feb 2018 19:05:33 -0500 From: "DOLLY, MARTIN C" To: Subir , Christer Holmberg CC: Adam Roach , STIR Chairs , "stir@ietf.org" , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AQHTngtiY/dEf4YfRra4GseuGeXVLKOU7bcQ Date: Mon, 5 Feb 2018 00:05:32 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com> In-Reply-To: <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.245.192] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365668A592A9MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802040319 Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 00:07:10 -0000 --_000_E42CCDDA6722744CB241677169E8365668A592A9MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugb25seSBoYXZlIG9uZSBjbGFpbSBhbmQgdGhhdCBpcyB0aGUgUlBIDQoNCkZyb206IFN1Ymly IFttYWlsdG86c3ViaXJkYXMyMUBnbWFpbC5jb21dDQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDA0 LCAyMDE4IDU6NTYgUE0NClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPg0KQ2M6IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+OyBTVElSIENo YWlycyA8c3Rpci1jaGFpcnNAaWV0Zi5vcmc+OyBzdGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLXN0 aXItcnBoLmFsbEB0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzdGlyXSBBRCBSZXZpZXc6 IGRyYWZ0LWlldGYtc3Rpci1ycGgtMDIgLSBhdXRob3JpdHkgdG8gYXNzZXJ0IHRoZSBjYWxsZXJz IGlkZW50aXR5IGFzc3VtZWQ/DQoNCg0KV2UgY2FuIGFkZCBzb21lIHRleHRzIHRvIGNsYXJpZnkg dGhhdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLiBUaGUgcG9pbnQgaXMgdGhhdCBpbiBzb21lIHVzZSBj YXNlcyBzZXJ2aWNlIHByb3ZpZGVyIG1heSBoYXZlIHRoZSBhdXRob3JpdHkgdG8gIG90aGVyIGNs YWltcyBzdWNoIGFzICdvcmlnJyBhbmQgaW4gb3RoZXIgY2FzZXMgaXQgbWF5IG5vdCBoYXZlLiAg V2UgY2FuIGFkZCBhIG1heSBzdGF0ZW1lbnQgY2xhcmlmeWluZyB0aGlzIG9yIGV4cGxpY2l0bHkg c2F5IHRoYXQgaXQgaXMgbm90IHJlcXVpcmVkIHRvIGhhdmUgYXV0aG9yaXR5IHRvIG90aGVyIGNs YWltcy4NCg0KVGhhbmtzLA0KDQpTdWJpcg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiBGZWIg NCwgMjAxOCwgYXQgMTA6MDMgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KSGksDQoNClRoZSB0ZXh0IHNheXM6DQoNCiAgIOKAnFRoZSBjcmVkZW50aWFscyAoZS5n LiwgYXV0aG9yaXR5IHJlc3BvbnNpYmxlIGZvciBhdXRob3JpemluZyBSZXNvdXJjZS0NCiAgIFBy aW9yaXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlIG11c3QgaGF2ZSBhdXRob3JpdHkg b3ZlciB0aGUNCiAgIG5hbWVzcGFjZSBvZiB0aGUgInJwaCIgY2xhaW0gYW5kIHRoZXJlIGlzIG9u bHkgb25lIGF1dGhvcml0eSBwZXINCiAgIGNsYWltLuKAnQ0KDQpJZiB0aGUgY3JlZGVudGlhbHMg ZG9u4oCZdCBuZWVkIHRvIGhhdmUgYXV0aG9yaXR5IG9mIHRoZSBvdGhlciBjbGFpbXMgKGUuZy4s IOKAnG9yaWfigJ0pIGluIHRoZSBSUEggUEFTU1BvclQgSSB0aGluayB5b3Ugc2hvdWxkIGV4cGxp Y2l0bHkgc2F5IHNvLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IFN1YmlyIERh cyBbbWFpbHRvOnN1YmlyZGFzMjFAZ21haWwuY29tXQ0KU2VudDogMDIgRmVicnVhcnkgMjAxOCAw MTowNA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpDYzogQWRhbSBSb2Fj aCA8YWRhbUBub3N0cnVtLmNvbTxtYWlsdG86YWRhbUBub3N0cnVtLmNvbT4+OyBTVElSIENoYWly cyA8c3Rpci1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnN0aXItY2hhaXJzQGlldGYub3JnPj47IHN0 aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLXN0aXItcnBoLmFs bEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1zdGlyLXJwaC5hbGxAdG9vbHMuaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3N0aXJdIEFEIFJldmlldzogZHJhZnQtaWV0Zi1zdGlyLXJw aC0wMiAtIGF1dGhvcml0eSB0byBhc3NlcnQgdGhlIGNhbGxlcnMgaWRlbnRpdHkgYXNzdW1lZD8N Cg0KSGVsbG8gQ2hyaXN0ZXIsDQpUaGUgc2lnbmluZyBlbnRpdHkgZG9lcyBub3QgaGF2ZSBhbHdh eXMgdGhlIGF1dGhvcml0eSB0byBhc3NlcnQgdGhlIGNhbGxlciBpZGVudGl0eSBpbiBycGguIFdl IGFyZSBzdWJtaXR0aW5nIHZlci0wMyBkcmFmdCAgYW5kIGl0IGlzIGNsYXJpZmllZCAgYXMgZm9s bG93czoNCiJUaGUgY3JlZGVudGlhbHMgKGUuZy4sIGF1dGhvcml0eSByZXNwb25zaWJsZSBmb3Ig YXV0aG9yaXppbmcgUmVzb3VyY2UtUHJpb3JpdHkpIHVzZWQgdG8gY3JlYXRlIHRoZSBzaWduYXR1 cmUgbXVzdCBoYXZlIGF1dGhvcml0eSBvdmVyIHRoZSBuYW1lc3BhY2Ugb2YgdGhl4oCccnBoIiBj bGFpbS4uIg0KDQotU3ViaXINCg0KT24gTW9uLCBKYW4gMjIsIDIwMTggYXQgMzoyNyBQTSwgQ2hy aXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KQW5vdGhlciBxdWVz dGlvbiBmb3IgY2xhcmlmaWNhdGlvbi4NCg0KU2VjdGlvbiAzIGNvbnRhaW5zIHRoZSBmb2xsb3dp bmcgZXhhbXBsZToNCg0KICAgIHsgIm9yaWciOnsidG4iOiIxMjE1NTU1MTIxMjx0ZWw6KDIxNSkl MjA1NTUtMTIxMj4ifQ0KICAgICAiZGVzdCI6e1sidG4iOiIxMjEyNTU1MTIxMzx0ZWw6KDIxMikl MjA1NTUtMTIxMz4iXX0sDQogICAgICJpYXQiOjE0NDMyMDgzNDUsDQogICAgICJycGgiOnsiYXV0 aCI6WyJldHMuMCIsIndwcy4wIl19DQoNCuKApmFuZCB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCiAg IOKAnFRoZSBjcmVkZW50aWFscyAoZS5nLiwgYXV0aG9yaXR5IHJlc3BvbnNpYmxlIGZvciBhdXRo b3JpemluZyBSZXNvdXJjZS0NCiAgIFByaW9yaXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0 dXJlIG11c3QgaGF2ZSBhdXRob3JpdHkgb3ZlciB0aGUNCiAgICJycGgiIGNsYWlt4oCm4oCdDQoN ClNpbmNlIHRoZSBjbGFpbSBhbHNvIGNvbnRhaW5zIOKAnG9yaWfigJ0sIGlzIHRoZSBhc3N1bXB0 aW9uIHRoYXQgdGhlIHNpZ25pbmcgZW50aXR5IGFsd2F5cyBhbHNvIGhhcyBhdXRob3JpdHkgdG8g YXNzZXJ0IHRoZSBjYWxsZXJzIGlkZW50aXR5PyBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8g ZXhwbGljaXRseSBtZW50aW9uIGl0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoN Cg0KRnJvbTogc3RpciBbbWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3Rpci1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNClNlbnQ6IDIwIEphbnVh cnkgMjAxOCAwMDoxNQ0KVG86IFNUSVIgQ2hhaXJzIDxzdGlyLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86c3Rpci1jaGFpcnNAaWV0Zi5vcmc+Pjsgc3RpckBpZXRmLm9yZzxtYWlsdG86c3RpckBpZXRm Lm9yZz47IGRyYWZ0LWlldGYtc3Rpci1ycGguYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFm dC1pZXRmLXN0aXItcnBoLmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFtzdGlyXSBBRCBS ZXZpZXc6IGRyYWZ0LWlldGYtc3Rpci1ycGgtMDINCg0KDQpJJ20gZG9pbmcgbXkgQUQgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtc3Rpci1ycGgtMDIuIFRoYW5rcyB0byBldmVyeW9uZSB3aG8gaGFzIHdv cmtlZCBvbiB0aGlzIGRvY3VtZW50LCBhbmQgdGhlIGF1dGhvcnMgYW5kIGNoYWlycyBpbiBwYXJ0 aWN1bGFyLg0KDQpUaGUgdGVjaG5pY2FsIGNvbnRlbnQgaGVyZSBsb29rcyBnZW5lcmFsbHkgZ29v ZCB0byBtZS4gSSdkIGxpa2UgdG8gc2VlIGEgZmV3IGlzc3VlcyBhZGRyZXNzZWQgYmVmb3JlIElF VEYgTEMuIEluIHNob3J0IHN1bWFyeToNCg0KICAqICAgVGhlIHZhbGlkYXRpb24gc2VjdGlvbiBu ZWVkcyB0byBhZGQgYSBkaXNjdXNzaW9uIG9mIGhvdyB0byB0cmVhdCBjYWxscyB3aGVuIHRoZSBw cmlvcml0eSB2YWx1ZXMgaW4gInJwaCIgcGFzc3BvcnRzIGFuZCBTSVAgIlJlc291cmNlLVByaW9y aXR5IiBoZWFkZXIgZmllbGRzIGFyZW4ndCAxMDAlIGlkZW50aWNhbC4NCiAgKiAgIFRoZSBleGFt cGxlcyBuZWVkIHNvbWUgYWRqdXN0bWVudC4NCiAgKiAgIFRoZXJlIGlzIGEgbWlub3IgcG9pbnQg b2YgYW1iaWd1aXR5IGluIHRoZSBTZWN1cml0eSBTZWN0aW9uLCBidXQgdGhpcyBzaG91bGQgYmUg ZWFzeSB0byBmaXgsIGFzIGxvbmcgYXMgdGhlIFdHIGtub3dzIHdoYXQgd2FzIGludGVuZGVkLg0K ICAqICAgVGhlIElBTkEgYWN0aW9ucyBuZWVkIGEgbGl0dGxlIGJpdCBvZiBhZGp1c3RtZW50Lg0K ICAqICAgVGhlcmUgYXJlIGEgbnVtYmVyIG9mIG1pbm9yIGVkaXRvcmlhbCBpc3N1ZXMgdG8gYmUg Y2xlYW5lZCB1cC4NCg0KRGV0YWlsZWQgY29tbWVudHMgb24gdGhlc2UgcG9pbnRzIGFyZSBpbmxp bmUgaW4gdGhlIGRvY3VtZW50IGJlbG93LiBJJ3ZlIHJlbW92ZWQgc29tZSBwb3J0aW9ucyBvZiB0 aGUgZG9jdW1lbnQgb24gd2hpY2ggSSBoYXZlIG5vIGNvbW1lbnRzLg0KDQoNCg0KQWJzdHJhY3QN Cg0KICAgVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBTVElSIFBBU1Nwb3JUIHNwZWNpZmljYXRp b24gdG8gYWxsb3cgdGhlDQoNCg0KDQoiLi4udGhlIFNlY3VyZSBUZWxlcGhvbmUgSWRlbnRpdHkg UmV2aXNpdGVkIChTVElSKSBQZXJzb25hbCBBc3NlcnRpb24gVG9rZW4gKFBBU1Nwb3JUKSBzcGVj aWZpY2F0aW9uIGRlZmluZWQgaW4gUkZDIDgxMjIuLi4iDQoNCihTZWUgPGh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dD48aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cucmZjLTJEZWRpdG9y Lm9yZ19tYXRlcmlhbHNfYWJicmV2LmV4cGFuc2lvbi50eHQmZD1Ed01GYVEmYz1MRllaLW85X0hV TWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZtPXNsS0lCWTM3eThwNGlDM0pn anV3RDFUSTlPZ1c3UVRIV3ptSlZ5cXlKTmcmcz1pQlRBaHdONTE3Qk5Bcm1qOGJiOFVhdDNMQUlm U3FFYjNPenVxSE9sNmtvJmU9PiBmb3IgZ3VpZGFuY2Ugb24gYWJicmV2aWF0aW9ucykNCg0KDQog ICBpbmNsdXNpb24gb2YgY3J5cHRvZ3JhcGhpY2FsbHktc2lnbmVkIGFzc2VydGlvbnMgb2YgYXV0 aG9yaXphdGlvbiBmb3INCiAgIHRoZSB2YWx1ZXMgcG9wdWxhdGVkIGluIHRoZSBTSVAgJ1Jlc291 cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQsDQogICB3aGljaCBpcyB1c2VkIGZvciBjb21tdW5p Y2F0aW9ucyByZXNvdXJjZSBwcmlvcml0aXphdGlvbi4NCg0KLi4uDQoNCjEuICBJbnRyb2R1Y3Rp b24NCg0KICAgUEFTU3BvclQgW0ktRC5pZXRmLXN0aXItcGFzc3BvcnRdIGlzIGEgdG9rZW4gZm9y bWF0IGJhc2VkIG9uIEpXVA0KICAgW1JGQzc1MTldIGZvciBjb252ZXlpbmcgY3J5cHRvZ3JhcGhp Y2FsbHktc2lnbmVkIGluZm9ybWF0aW9uIGFib3V0DQogICB0aGUgaWRlbnRpdGllcyBpbnZvbHZl ZCBpbiBwZXJzb25hbCBjb21tdW5pY2F0aW9uczsgaXQgaXMgdXNlZCB3aXRoDQogICBTVElSIFtJ LUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNdIHRvIGNvbnZleSBhIHNpZ25lZCBhc3NlcnRpb24gb2Yg dGhlDQogICBpZGVudGl0eSBvZiB0aGUgcGFydGljaXBhbnRzIGluIHJlYWwtdGltZSBjb21tdW5p Y2F0aW9ucyBlc3RhYmxpc2hlZA0KICAgdmlhIGEgcHJvdG9jb2wgbGlrZSBTSVAuICBUaGlzIHNw ZWNpZmljYXRpb24gZXh0ZW5kcyBQQVNTcG9yVCB0bw0KDQoNCg0KIi4uLmxpa2UgU0lQIFtSRkMz MjYxXS4uLiINCg0KKFdlIHdhbnQgdG8gY2l0ZSBTSVAgdGhlIGZpcnN0IHRpbWUgaXQgaXMgbWVu dGlvbmVkKQ0KDQoNCiAgIGFsbG93IGNyeXB0b2dyYXBoaWMtc2lnbmluZyBvZiB0aGUgU0lQICdS ZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyDQogICBmaWVsZCBkZWZpbmVkIGluIFtSRkM0NDEyXS4N Cg0KICAgW1JGQzQ0MTJdIGRlZmluZXMgdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRl ciBmaWVsZCBmb3INCiAgIGNvbW11bmljYXRpb25zIFJlc291cmNlIFByaW9yaXR5LiAgQXMgc3Bl Y2lmaWVkIGluIFtSRkM0NDEyXSwgdGhlDQogICAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBm aWVsZCBtYXkgYmUgdXNlZCBieSBTSVAgdXNlciBhZ2VudHMNCiAgIFtSRkMzMjYxXSwgaW5jbHVk aW5nLCBQdWJsaWMgU3dpdGNoZWQgVGVsZXBob25lIE5ldHdvcmsgKFBTVE4pDQoNCg0KDQoiLi4u aW5jbHVkaW5nIFB1YmxpYyBTd2l0Y2hlZC4uLiINCg0KKHJlbW92ZSB0aGUgY29tbWEpDQoNCg0K ICAgZ2F0ZXdheXMgYW5kIHRlcm1pbmFscywgYW5kIFNJUCBwcm94eSBzZXJ2ZXJzIHRvIGluZmx1 ZW5jZQ0KDQoNCg0KIi4uLmFuZCBieSBTSVAgcHJveHkgc2VydmVycywgdG8gaW5mbHVlbmNlLi4u Ig0KDQooYWRkICJieSIgYW5kIGNvbW1hKQ0KDQoNCiAgIHByaW9yaXRpemF0aW9uIGFmZm9yZGVk IHRvIGNvbW11bmljYXRpb24gc2Vzc2lvbnMsaW5jbHVkaW5nIFBTVE4NCg0KDQoiLi4uc2Vzc2lv bnMsIGluY2x1ZGluZy4uLiINCg0KKHNwYWNlIGFmdGVyIGNvbW1hKQ0KDQoNCiAgIGNhbGxzLiAg SG93ZXZlciwgdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBjb3VsZCBi ZQ0KICAgc3Bvb2ZlZCBhbmQgYWJ1c2VkIGJ5IHVuYXV0aG9yaXplZCBlbnRpdGllcy4NCg0KICAg VGhlIFNUSVIgYXJjaGl0ZWN0dXJlIFtSRkM3MzQwXWFzc3VtZXMgdGhhdCBhbiBhdXRob3JpdHkg b24gdGhlDQoNCg0KDQoiLi4uU1RJUiBhcmNoaXRlY3R1cmUgW1JGQzczNDBdIGFzc3VtZXMuLi4i DQoNCihzcGFjZSBiZWZvcmUgImFzc3VtZXMiKQ0KDQoNCiAgIG9yaWdpbmF0aW5nIHNpZGUgb2Yg YSBjYWxsIHByb3ZpZGVzIGEgY3J5cHRvZ3JhcGhpYyBhc3N1cmFuY2Ugb2YgdGhlDQogICB2YWxp ZGl0eSBvZiB0aGUgY2FsbGluZyBwYXJ0eSBudW1iZXIgaW4gb3JkZXIgdG8gcHJldmVudA0KICAg aW1wZXJzb25hdGlvbiBhdHRhY2tzLiAgVGhlIFNUSVIgYXJjaGl0ZWN0dXJlIGFsbG93cyBleHRl bnNpb24gdGhhdA0KDQoNCg0KIi4uLmFsbG93cyBleHRlbnNpb25zLi4uIg0KDQoNCiAgIGNhbiBi ZSB1dGlsaXplZCBieSBhdXRob3JpdGllcyBzdXBwb3J0aW5nIHJlYWwtdGltZSBjb21tdW5pY2F0 aW9uDQogICBzZXJ2aWNlcyB1c2luZyB0aGUgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmll bGQgdG8NCiAgIGNyeXB0b2dyYXBoaWNhbGx5IHNpZ24gdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3Jp dHknIGhlYWRlciBmaWVsZCBhbmQNCiAgIGNvbnZleSBhc3NlcnRpb24gb2YgdGhlIGF1dGhvcml6 YXRpb24gZm9yICdSZXNvdXJjZS1Qcmlvcml0eScuICBGb3INCiAgIGV4YW1wbGUsIHRoZSBhdXRo b3JpdHkgb24gdGhlIG9yaWdpbmF0aW5nIHNpZGUgdmVyaWZ5aW5nIHRoZQ0KICAgYXV0aG9yaXph dGlvbiBvZiBhIHBhcnRpY3VsYXIgY29tbXVuaWNhdGlvbiBmb3IgUmVzb3VyY2UtUHJpb3JpdHkg Y2FuDQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQoN CiAgIHVzZSBhIFBBU1NQb3JUIGNsYWltIHRvIGNyeXB0b2dyYXBoaWNhbGx5LXNpZ24gdGhlIFNJ UCAnUmVzb3VyY2UtDQoNCg0KDQoiLi4uY3J5cHRvZ3JhcGhpY2FsbHkgc2lnbi4uLiINCg0KDQog ICBQcmlvcml0eScgaGVhZGVyIGZpZWxkIGFuZCBjb252ZXkgYW4gYXNzZXJ0aW9uIG9mIHRoZSBh dXRob3JpemF0aW9uDQogICBmb3IgJ1Jlc291cmNlLVByaW9yaXR5Jy4gIFRoaXMgd2lsbCBhbGxv dyBhIHJlY2VpdmluZyBlbnRpdHkNCiAgIChpbmNsdWRpbmcgZW50aXRpZXMgbG9jYXRlZCBpbiBk aWZmZXJlbnQgbmV0d29yayBkb21haW5zL2JvdW5kYXJpZXMpDQogICB0byB2ZXJpZnkgdGhlIHZh bGlkaXR5IG9mIGFzc2VydGlvbnMgYXV0aG9yaXppbmcgUmVzb3VyY2UtUHJpb3JpdHkuDQoNCg0K DQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQoNCiAgIENyeXB0 b2dyYXBoaWNhbGx5LXNpZ25lZCBTSVAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXJzIHdpbGwg YWxsb3cgYQ0KDQoNCg0KIi4uLmNyeXB0b2dyYXBoaWNhbGx5IHNpZ25lZCBTSVAgJ1Jlc291cmNl LVByaW9yaXR5JyBoZWFkZXIgZmllbGRzLi4uIg0KDQoocmVtb3ZlIGh5cGhlbiwgYW5kIHJlcGxh Y2UgImhlYWRlcnMiIHdpdGggImhlYWRlciBmaWVsZHMiKQ0KDQoNCiAgIHJlY2VpdmluZyBlbnRp dHkgdG8gdmVyaWZ5IGFuZCBhY3Qgb24gdGhlIGluZm9ybWF0aW9uIHdpdGggY29uZmlkZW5jZQ0K ICAgdGhhdCB0aGUgaW5mb3JtYXRpb24gaGF2ZSBub3QgYmVlbiBzcG9vZmVkIG9yIGNvbXByb21p c2VkLg0KDQoNCg0KIi4uLmhhcyBub3QgYmVlbiBzcG9vZmVkIG9yIGNvbXByb21pc2VkLiINCg0K DQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2N1bWVudHMgYW4gb3B0aW9uYWwgZXh0ZW5zaW9u IHRvIFBBU1Nwb3JUIGFuZA0KICAgdGhlIGFzc29jaWF0ZWQgU1RJUiBtZWNoYW5pc21zIHRvIHBy b3ZpZGUgYSBmdW5jdGlvbiB0byBzaWduIHRoZSBTSVANCiAgICdSZXNvdXJjZS1Qcmlvcml0eScg aGVhZGVyIGZpZWxkLiAgVGhpcyBQQVNTcG9yVCBvYmplY3QgaXMgdXNlZCB0bw0KICAgcHJvdmlk ZSBhdHRlc3RhdGlvbiBvZiBhIGNhbGxpbmcgdXNlciBhdXRob3JpemF0aW9uIGZvciBwcmlvcml0 eQ0KICAgY29tbXVuaWNhdGlvbnMuICBUaGlzIGlzIG5lY2Vzc2FyeSBpbiBhZGRpdGlvbiB0byB0 aGUgUEFTU3BvclQgb2JqZWN0DQogICB0aGF0IGlzIHVzZWQgZm9yIGNhbGxpbmcgdXNlciB0ZWxl cGhvbmUgbnVtYmVyIGF0dGVzdGF0aW9uLiAgSG93IHRoZQ0KICAgb3B0aW9uYWwgZXh0ZW5zaW9u IHRvIFBBU1Nwb3JUIGlzIHVzZWQgZm9yIHJlYWwtdGltZSBjb21tdW5pY2F0aW9ucw0KICAgc3Vw cG9ydGVkIHVzaW5nIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBpcyBkZWZp bmVkIGluDQogICBvdGhlciBkb2N1bWVudHMgYW5kIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuDQoNCg0KDQpJIGFzc3VtZSB0aGVzZSBvdGhlciBkb2N1bWVudHMgYXJlIHVu ZGVyIGRldmVsb3BtZW50PyBJZiBzbywgdGhleSBzaG91bGQgYmUgY2l0ZWQgaGVyZS4NCg0KDQoN CjIuICBUZXJtaW5vbG9neQ0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwg IlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBO T1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9j dW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZD MjExOV0uDQoNCg0KDQpUaGlzIGRvY3VtZW50IGhhcyBzZXZlcmFsIG5vbi1ub3JtYXRpdmUgdXNl cyBvZiAibXVzdCIsICJzaG91bGQsIiBhbmQgIm1heSwiIGFuZCBzbyBpdCBuZWVkcyB0byB1c2Ug dGhlIFJGQzgxNzQgYm9pbGVycGxhdGUgaW5zdGVhZCBvZiB0aGUgUkZDMjExOSBib2lsZXJwbGF0 ZS4NCg0KDQoNCjMuICBQQVNTcG9yVCAncnBoJyBDbGFpbQ0KDQogICBUaGlzIHNwZWNpZmljYXRp b24gZGVmaW5lcyBhIG5ldyBKU09OIFdlYiBUb2tlbiBjbGFpbSBmb3IgInJwaCIsDQogICB3aGlj aCBwcm92aWRlcyBhbiBhc3NlcnRpb24gZm9yIGluZm9ybWF0aW9uIGluIFNJUCAnUmVzb3VyY2Ut DQogICBQcmlvcml0eSdoZWFkZXIuDQoNCg0KDQoiLi4uUHJpb3JpdHknIGhlYWRlciBmaWVsZC4i DQoNCihzcGFjZSBhZnRlciBjbG9zaW5nIHF1b3RhdGlvbiBtYXJrLCAiaGVhZGVyIGZpZWxkIiBp bnN0ZWFkIG9mICJoZWFkZXIiKQ0KDQoNCg0KICAgVGhlIGNyZWF0b3Igb2YgYSBQQVNTcG9yVCBv YmplY3QgYWRkcyBhICJwcHQiIHZhbHVlIG9mICJycGgiIHRvIHRoZQ0KICAgaGVhZGVyIG9mIGEg UEFTU3BvclQgb2JqZWN0LCBpbiB3aGljaCBjYXNlIHRoZSBQQVNTcG9yVCBjbGFpbXMgTVVTVA0K ICAgY29udGFpbiBhICJycGgiIGNsYWltLCBhbmQgYW55IGVudGl0aWVzIHZlcmlmeWluZyB0aGUg UEFTU3BvclQgb2JqZWN0DQogICB3aWxsIGJlIHJlcXVpcmVkIHRvIHVuZGVyc3RhbmQgdGhlICJw cHQiIGV4dGVuc2lvbiBpbiBvcmRlciB0bw0KICAgcHJvY2VzcyB0aGUgUEFTU3BvclQgaW4gcXVl c3Rpb24uICBBIFBBU1NQb3JUIGhlYWRlciB3aXRoIHRoZSAicHB0Ig0KICAgaW5jbHVkZWQgd2ls bCBsb29rIGFzIGZvbGxvd3M6DQoNCiAgIHsgICJ0eXAiOiJwYXNzcG9ydCIsDQogICAgICJwcHQi OiJycGgiLA0KICAgICAiYWxnIjoiRVMyNTYiLA0KICAgICAieDV1IjoiaHR0cHM6Ly93d3cuZXhh bXBsZS5vcmcvY2VydC5jZXIiPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmV4YW1wbGUub3JnX2NlcnQuY2VyJmQ9RHdNRmFRJmM9TEZZWi1v OV9IVU1lTVRTUWljdmpJZyZyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcmbT1zbEtJQlkzN3k4cDRp QzNKZ2p1d0QxVEk5T2dXN1FUSFd6bUpWeXF5Sk5nJnM9V1RUdURteTM5aTJ6STNpY01IbzgyY3FS R2FYanpIeXdJZ0JBSUsxb3FDVSZlPT59DQoNCg0KDQpJZGVhbGx5LCB0aGlzIHdvdWxkIGJlIGVp dGhlciBwcmV0dHktcHJpbnRlZCBvciBjYW5vbmljYWxpemVkLiBTaW5jZSBpdCdzIHRvbyBsb25n IHRvIGZpdCBvbiBhIGxpbmUgaW4gY2Fub25pY2FsIGZvcm0sIEkgcHJvcG9zZToNCg0Kew0KICAi dHlwIjoicGFzc3BvcnQiLA0KICAicHB0IjoicnBoIiwNCiAgImFsZyI6IkVTMjU2IiwNCiAgIng1 dSI6Imh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyIjxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5leGFtcGxlLm9yZ19jZXJ0LmNl ciZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1HOXY4dUNTU1FoQ21wdzdJdEcw cjJnJm09c2xLSUJZMzd5OHA0aUMzSmdqdXdEMVRJOU9nVzdRVEhXem1KVnlxeUpOZyZzPVdUVHVE bXkzOWkyekkzaWNNSG84MmNxUkdhWGp6SHl3SWdCQUlLMW9xQ1UmZT0+DQp9DQoNCg0KDQogICBU aGUgInJwaCIgY2xhaW0gd2lsbCBwcm92aWRlIGFuIGFzc2VydGlvbiBvZiBhdXRob3JpemF0aW9u LCJhdXRoIiwNCg0KDQoNCiIuLi5hdXRob3JpemF0aW9uLCAiYXV0aCIsIC4uLiINCg0KKHNwYWNl IGJldHdlZW4gY29tbWEgYW5kIG9wZW5pbmcgcXVvdGF0aW9uIG1hcmspDQoNCg0KICAgZm9yIGlu Zm9ybWF0aW9uIGluIHRoZSBTSVAgIlJlc291cmNlLVByaW9yaXR5IiBoZWFkZXIgZmllbGQgKGku ZS4sDQogICBSZXNvdXJjZS1Qcmlvcml0eTogbmFtZXNwYWNlICIuIiByLXByaW9yaXR5KSBiYXNl ZCBvbiBbUkZDNDQxMl0uDQoNCg0KDQpUaGUgdXNlIG9mIHRoZSBzdHJpbmcgJ25hbWVzcGFjZSAi LiIgci1wcmlvcml0eScgaGVyZSBhbmQgZWxzZXdoZXJlIGluIHRoZSBkb2N1bWVudCBoYXMgYSBk ZXRyaW1lbnRhbCBpbXBhY3Qgb24gcmVhZGFiaWxpdHkuIEkgc3Ryb25nbHkgc3VnZ2VzdCByZXBs YWNpbmcgaXQgd2l0aCAici12YWx1ZSIgKHRoZSBuYW1lIG9mIHRoaXMgcHJvZHVjdGlvbiBpbiBS RkM0NDEyKSBldmVyeXdoZXJlLg0KDQoNCiAgIFNwZWNpZmljYWxseSwgdGhlICJycGgiIGNsYWlt IGluY2x1ZGVzIGFzc2VydGlvbiBvZiB0aGUgcHJpb3JpdHktDQogICBsZXZlbCBvZiB0aGUgdXNl ciB0byBiZSB1c2VkIGZvciBhIGdpdmVuIGNvbW11bmljYXRpb24gc2Vzc2lvbi4gIFRoZQ0KICAg dmFsdWUgb2YgdGhlICJycGgiIGNsYWltIGlzIGFuIGFycmF5IGNvbnRhaW5pbmcgb25lIG9yIG1v cmUgb2YgSlNPTg0KICAgb2JqZWN0cyBmb3IgdGhlIGNvbnRlbnQgb2YgdGhlIFNJUCAnUmVzb3Vy Y2UtUHJpb3JpdHknIGhlYWRlciB0aGF0IGlzDQogICBiZWluZyBhc3NlcnRlZCBvZiB3aGljaCBv bmUgb2YgdGhlICJycGgiIG9iamVjdCwgaXMgbWFuZGF0b3J5Lg0KDQoNCg0KVGhpcyBsYXN0IHNl bnRlbmNlIGlzIHZlcnkgaGFyZCB0byBwYXJzZTsgYW5kIChiYXNlZCBvbiB0aGUgZXhhbXBsZSkg dGhlIHZhbHVlIGlzIGludGVuZGVkIHRvIGJlIGEgSlNPTiBPYmplY3QgKGN1cmx5IGJyYWNlcykg cmF0aGVyIHRoYW4gYSBKU09OIEFycmF5IChzcXVhcmUgYnJhY2VzKS4gSSBzdWdnZXN0OiAnVGhl IHZhbHVlIG9mIHRoZSAicnBoIiBjbGFpbSBpcyBhbiBPYmplY3Qgd2l0aCBvbmUgb3IgbW9yZSBr ZXlzLiBFYWNoIGtleSBpcyBhc3NvY2lhdGVkIHdpdGggYSBKU09OIEFycmF5LiBUaGVzZSBhcnJh eXMgY29udGFpbiBTdHJpbmdzIHRoYXQgY29ycmVzcG9uZCB0byB0aGUgci12YWx1ZXMgaW5kaWNh dGVkIGluIHRoZSBTSVAgIlJlc291cmNlLVByaW9yaXR5IiBoZWFkZXIgZmllbGQuJyAobm90ZTog ImhlYWRlciBmaWVsZCIsIG5vdCAiaGVhZGVyIikNCg0KDQoNCiAgIFRoZSBmb2xsb3dpbmcgaXMg YW4gZXhhbXBsZSAicnBoIiBjbGFpbSBmb3IgYSBTSVAgIlJlc291cmNlLVByaW9yaXR5Ig0KICAg aGVhZGVyIGZpZWxkIHdpdGggYSAibmFtZXNwYWNlICIuIiByLXByaW9yaXR5IiB2YWx1ZSBvZiAi ZXRzLjAiIGFuZA0KICAgd2l0aCBhICJuYW1lc3BhY2UgIi4iIHItcHJpb3JpdHkiIHZhbHVlIG9m ICJ3cHMuMCIuDQoNCiAgICB7ICJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTI8dGVsOigyMTUpJTIw NTU1LTEyMTI+In0NCiAgICAgImRlc3QiOntbInRuIjoiMTIxMjU1NTEyMTM8dGVsOigyMTIpJTIw NTU1LTEyMTM+Il19LA0KICAgICAiaWF0IjoxNDQzMjA4MzQ1LA0KICAgICAicnBoIjp7ImF1dGgi OlsiZXRzLjAiLCJ3cHMuMCJdfQ0KDQoNCg0KQXMgYWJvdmUsIEkgcmVjb21tZW5kIHByZXR0eS1w cmludGluZyB0aGlzLiBJdCdzIGFsc28gbWlzc2luZyBhIGNvbW1hIGFmdGVyIHRoZSAib3JpZyIg dmFsdWUsIGFuZCB0aGUgdG9wLWxldmVsIHN0cnVjdHVyZSBpcyBtaXNzaW5nIGEgY2xvc2luZyBi cmFjZS4gVGhlIHZhbHVlIGZvciAiaWF0IiBuZWVkcyB0byBiZSBlbmNsb3NlZCBpbiBxdW90ZXMu DQoNClRoZSBOQU5QQSBoYXMgYWxsb2NhdGVkIE5QQTU1NTAxeHggZm9yIGV4YW1wbGUgdXNlLCBu b3QgTlBBNTU1eHh4eCwgbXVjaCBvZiB3aGljaCByZW1haW5zIGFzc2lnbmFibGUgKGNmIDxodHRw czovL3d3dy5uYXRpb25hbG5hbnBhLmNvbS9wZGYvTlJVRi9BVElTLTAzMDAxMTUucGRmPjxodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5uYXRp b25hbG5hbnBhLmNvbV9wZGZfTlJVRl9BVElTLTJEMDMwMDExNS5wZGYmZD1Ed01GYVEmYz1MRlla LW85X0hVTWVNVFNRaWN2aklnJnI9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZtPXNsS0lCWTM3eThw NGlDM0pnanV3RDFUSTlPZ1c3UVRIV3ptSlZ5cXlKTmcmcz1qNXFCanN3U1FBMHlzb09fcExLVFVk Q2tLUExid1I2US1nZzhBYmFCY0ZNJmU9PikuDQoNClB1dHRpbmcgYWxsIHRoaXMgdG9nZXRoZXIs IEkgYmVsaWV2ZSB3aGF0IHlvdSB3YW50IGlzOg0KDQp7DQogICJvcmlnIjp7InRuIjoiMTIxNTU1 NTAxMTI8dGVsOigyMTUpJTIwNTU1LTAxMTI+In0sDQogICJkZXN0Ijp7WyJ0biI6IjEyMTI1NTUw MTEzPHRlbDooMjEyKSUyMDU1NS0wMTEzPiJdfSwNCiAgImlhdCI6IjE0NDMyMDgzNDUiLA0KICAi cnBoIjp7ImF1dGgiOlsiZXRzLjAiLCJ3cHMuMCJdfQ0KfQ0KDQoNCg0KICAgQWZ0ZXIgdGhlIGhl YWRlciBhbmQgY2xhaW1zIFBBU1Nwb3JUIG9iamVjdHMgaGF2ZSBiZWVuIGNvbnN0cnVjdGVkLA0K ICAgdGhlaXIgc2lnbmF0dXJlIGlzIGdlbmVyYXRlZCBub3JtYWxseSBwZXIgdGhlIGd1aWRhbmNl IGluDQogICBbSS1ELmlldGYtc3Rpci1wYXNzcG9ydF0gdXNpbmcgdGhlIGZ1bGwgZm9ybSBvZiBQ QVNTUG9yVC4gIFRoZQ0KICAgY3JlZGVudGlhbHMgKGUuZy4sIGF1dGhvcml0eSByZXNwb25zaWJs ZSBmb3IgYXV0aG9yaXppbmcgUmVzb3VyY2UtDQogICBQcmlvcml0eSkgdXNlZCB0byBjcmVhdGUg dGhlIHNpZ25hdHVyZSBtdXN0IGhhdmUgYXV0aG9yaXR5IG92ZXIgdGhlDQogICAicnBoIiBjbGFp bSBhbmQgdGhlcmUgaXMgb25seSBvbmUgYXV0aG9yaXR5IHBlciBjbGFpbS4gIFRoZSBhdXRob3Jp dHkNCiAgIE1VU1QgdXNlIGl0cyBjcmVkZW50aWFscyAoaS5lLiwgQ0VSVCkgYXNzb2NpYXRlZCB3 aXRoIHRoZSBzcGVjaWZpYw0KICAgc2VydmljZSBzdXBwb3J0ZWQgYnkgdGhlIFNJUCBuYW1lc3Bh Y2UgaW4gdGhlIGNsYWltLg0KDQo0LiAgJ3JwaCcgaW4gU0lQDQoNCiAgIFRoaXMgc2VjdGlvbiBz cGVjaWZpZXMgU0lQLXNwZWNpZmljIHVzYWdlIGZvciB0aGUgInJwaCIgY2xhaW0gaW4NCiAgIFBB U1Nwb3JULg0KDQo0LjEuICBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIEJlaGF2aW9yDQoNCiAgIFRo ZSBBdXRoZW50aWNhdGlvbiBTZXJ2aWNlIHdpbGwgY3JlYXRlIHRoZSAicnBoIiBjbGFpbSB1c2lu ZyB0aGUNCiAgIHZhbHVlcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiAzIGJhc2VkIG9uIFtSRkM0NDEy XS4gIFRoZSBjb25zdHJ1Y3Rpb24NCiAgIG9mICJycGgiIGNsYWltIGZvbGxvd3MgdGhlIHN0ZXBz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQgb2YNCiAgIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNd Lg0KDQogICBUaGUgcmVzdWx0aW5nIElkZW50aXR5IGhlYWRlciBmb3IgInJwaCIgbWlnaHQgbG9v ayBhcyBmb2xsb3dzOg0KDQoNCg0KIi4uLmhlYWRlciBmaWVsZC4uLiINCg0KDQoNCiAgICJleUpo YkdjaU9pSkZVekkxTmlJc0luUjVjQ0k2SWtwWFZDSjkuZXlKcGMzTWlPaUpsZVVvd1pWaEJhVTlw U25kDQogICBaV0U1NlkwYzVlV1JEU1hORVVXOXBZMGhDTUVscWIybGpia0p2U1dsM1RrTnBTbWhp UjJOcFQybEtSbFY2U1RGTw0KICAgYVVselJGRnZhV1ZFVmpGSmFuQnZaRWhTZDJONmIzWk1NMlF6 WkhrMWJHVkhSblJqUjNoc1RHMU9kbUpUT1dwYVcNCiAgIEVvd1RHMU9iR051TUU1RFp6QkxJSHg4 NG9DWkx1S0FtWHg4SUdWNVFXbGlNMHB3V25sSk5tVjVTakJpYVVrMlNXDQogICBwRmVVMVVWVEZP VkZWNFRXcEZlVWx1TUU1RGFVcHJXbGhPTUVscWNEZFhlVW93WW1sSk5rbHFSWGxOVkVreFRsUg0K ICAgVmVFMXFSWHBKYkRFNVRFRXdTMGx0Ykdoa1EwazJUVlJSTUUxNlNYZFBSRTB3VGxOM1RrTnBT bmxqUjJkcFQyNXoNCiAgIGFWbFlWakJoUTBrMlYzbEtiR1JJVFhWTlEwbHpTVzVrZDJONU5IZEpi REU1UkZGdlBTSjkuczM3UzZWQzhITTZEDQogICBsNll6SmVRRHNyWmN3SjBsaXp4aFVyQTdmXzk4 b1dCSHZvLWNsLW44TUlob0NyMTh2WVlGeTNibFh2czNmc2xNXw0KICAgb29zMlAyRHl3IjsgaW5m bz0gImh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyIjxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5leGFtcGxlLm9yZ19jZXJ0LmNl ciZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1HOXY4dUNTU1FoQ21wdzdJdEcw cjJnJm09c2xLSUJZMzd5OHA0aUMzSmdqdXdEMVRJOU9nVzdRVEhXem1KVnlxeUpOZyZzPVdUVHVE bXkzOWkyekkzaWNNSG84MmNxUkdhWGp6SHl3SWdCQUlLMW9xQ1UmZT0+O2FsZz1FUzI1NjsNCiAg IHBwdD0icnBoIg0KDQoNCg0KVGhpcyBleGFtcGxlIGhhcyBhIG51bWJlciBvZiBpc3N1ZXM6DQoN CiAgKiAgIEluIHRoZSBJZGVudGl0eSBoZWFkZXIgZmllbGQsIHRoZSBzaWduZWQtaWRlbnRpdHkt ZGlnZXN0IHNob3VsZG4ndCBiZSBxdW90ZWQuDQogICogICBJbiB0aGUgSWRlbnRpdHkgaGVhZGVy IGZpZWxkLCBpbmZvIGlzIGVuY2xvc2VkIGluIDw+IHJhdGhlciB0aGFuICIiLg0KICAqICAgSW4g dGhlIElkZW50aXR5IGhlYWRlciBmaWVsZCwgcHB0IGlzIGEgdG9rZW4gcmF0aGVyIHRoYW4gYSBx dW90ZWQgc3RyaW5nLg0KICAqICAgVGhlIHNpZ25lZC1pZGVudGl0eS1kaWdlc3QgaGVhZGVyIG5l ZWRzIHRvIGluZGljYXRlIGEgInR5cCIgb2YgInBhc3Nwb3J0IiByYXRoZXIgdGhhbiBKV1QsIGFu ZCBpdCBuZWVkcyB0byBpbmNsdWRlIGJvdGggYSAicHB0IiBhbmQgIng1dSIgZmllbGQuDQogICog ICBUaGUgc2lnbmVkLWlkZW50aXR5LWRpZ2VzdCBib2R5IHNob3VsZCBjb250YWluIG9ubHkgdGhl IHBhc3Nwb3J0IGNsYWltIHJhdGhlciB0aGFuIGEgSlNPTiBvYmplY3QgdGhhdCBpdHNlbGYgY29u dGFpbnMgYSBiYXNlNjQtZW5jb2RlZCBKV1MgaGVhZGVyIGNvbmNhdGVuYXRlZCB3aXRoIGEgY2xh aW0uDQogICogICBJIGJlbGlldmUgdGhhdCwgZXZlbiB3aGVuIHRoZSBib2R5IGlzIGluY2x1ZGVk LCB2YWx1ZXMgaW4gdGhlIGhlYWRlciBhbmQgYm9keSBuZWVkIHRvIGJlIGJlIGNhbm9uaWNhbGl6 ZWQgKGkuZS4sIGFsbCBvbiBvbmUgbGluZSwgbm8gc3BhY2VzLCBpbiBhbHBoYWJldGljYWwgb3Jk ZXIsIGV0Yy4pDQoNCkkgd291bGQgYWxzbyByZWNvbW1lbmQgZm9sbG93aW5nIHRoZSBjb252ZW50 aW9uIG9mIGluZGljYXRpbmcgdGhhdCBsaW5lLXdyYXBzIGFyZSBvbmx5IGZvciByZWFkYWJpbGl0 eSwgYW5kIGluY2x1ZGluZyB0aGUgaGVhZGVyIGZpZWxkIG5hbWUgaW4gdGhlIGV4YW1wbGUuIFB1 dHRpbmcgYWxsIHRoaXMgdG9nZXRoZXIsIEkgYmVsaWV2ZSB3aGF0IHlvdSB3YW50IGlzOg0KDQog ICBGb3IgZXhhbXBsZSwgYSBJZGVudGl0eSBoZWFkZXIgZmllbGQgZm9yICJycGgiIG1pZ2h0IGxv b2sNCiAgIGFzIGZvbGxvd3MgKGJhY2tzbGFzaGVzIHNob3duIGZvciBsaW5lIGZvbGRpbmcgb25s eSk6DQoNCiAgIElkZW50aXR5OiBleUpoYkdjaU9pSkZVekkxTmlJc0luQndkQ0k2SW5Kd2FDSXNJ blI1Y0NJNkluQmhjM053YjNKMEkgXA0KICAgaXdpZURWMUlqb2lhSFIwY0hNNkx5OTNkM2N1Wlho aGJYQnNaUzVqYjIwdlkyVnlkQzVqWlhJaWZRby5leUprWlhOMCBcDQogICBJanA3V3lKMGJpSTZJ akV5TVRJMU5UVXdNVEV6SWwxOUxDSnBZWFFpT2lJeE5EUXpNakE0TXpRMUlpd2liM0pwWnlJIFwN CiAgIDZleUowYmlJNklqRXlNVFUxTlRVd01URXlJbjBzSW5Kd2FDSTZleUpoZFhSb0lqcGJJbVYw Y3k0d0lpd2lkM0J6TGogXA0KICAgQWlYWDE5Q2cuczM3UzZWQzhITTZEbDZZekplUURzclpjd0ow bGl6eGhVckE3Zl85OG9XQkh2by1jbC1uOE1JaG9DciBcDQogICAxOHZZWUZ5M2JsWHZzM2ZzbE1f b29zMlAyRHl3O2luZm89PGh0dHBzOi8vd3d3LmV4YW1wbGUub3JnL2NlcnQuY2VyPGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmV4YW1wbGUu b3JnX2NlcnQuY2VyJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUc5djh1Q1NT UWhDbXB3N0l0RzByMmcmbT1zbEtJQlkzN3k4cDRpQzNKZ2p1d0QxVEk5T2dXN1FUSFd6bUpWeXF5 Sk5nJnM9V1RUdURteTM5aTJ6STNpY01IbzgyY3FSR2FYanpIeXdJZ0JBSUsxb3FDVSZlPT4gXA0K ICAgPjthbGc9RVMyNTY7cHB0PXJwaA0KDQooTm90ZTogdGhpcyBleGFtcGxlIGFzc3VtZXMgdGhl IGNhbGxpbmcgYW5kIGNhbGxlZCBwYXJ0eSBudW1iZXJzIGluIHRoZSBwcmV2aW91cyBleGFtcGxl IGFyZSBjaGFuZ2VkIHRvIDEyMTU1NTUwMTEyPHRlbDooMjE1KSUyMDU1NS0wMTEyPiBhbmQgMTIx NTU1NTAxMTM8dGVsOigyMTUpJTIwNTU1LTAxMTM+LCByZXNwZWN0aXZlbHkpDQoNCg0KDQogICBB IFNJUCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIHR5cGljYWxseSB3aWxsIGRlcml2ZSB0aGUgdmFs dWUgb2YgInJwaCINCiAgIGZyb20gdGhlICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxk IGJhc2VkIG9uIHBvbGljeSBhc3NvY2lhdGVkDQogICB3aXRoIHNlcnZpY2Ugc3BlY2lmaWMgdXNl IG9mIHRoZSAibmFtZXNwYWNlICIuIiByLXByaW9yaXR5IiB2YWx1ZXMNCiAgIGJhc2VkIG9uIFtS RkM0NDEyXS4gIFRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlIGRlcml2ZXMgdGhlIHZhbHVlIG9m DQogICB0aGUgUEFTU1BvclQgY2xhaW0gYnkgdmVyaWZ5aW5nIHRoZSBhdXRob3JpemF0aW9uIGZv ciBSZXNvdXJjZS0NCiAgIFByaW9yaXR5IChpLmUuLCB2ZXJpZnlpbmcgYSBjYWxsaW5nIHVzZXIg cHJpdmlsZWdlIGZvciBSZXNvdXJjZS0NCiAgIFByaW9yaXR5IGJhc2VkIG9uIGl0cyBpZGVudGl0 eSkgd2hpY2ggbWlnaHQgYmUgZGVyaXZlZCBmcm9tIGN1c3RvbWVyDQogICBwcm9maWxlIGRhdGEg b3IgZnJvbSBhY2Nlc3MgdG8gZXh0ZXJuYWwgc2VydmljZXMuDQoNCiAgIFtSRkM0NDEyXSBhbGxv d3MgbXVsdGlwbGUgIm5hbWVzcGFjZSAiLiIgci1wcmlvcml0eSIgcGFpcnMsIGVpdGhlciBpbg0K ICAgYSBzaW5nbGUgU0lQIFJlc291cmNlLVByaW9yaXR5IGhlYWRlciBvciBhY3Jvc3MgbXVsdGlw bGUgU0lQDQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0K DQoiLi4uaGVhZGVyIGZpZWxkLi4uIg0KDQoNCiAgIFJlc291cmNlLVByaW9yaXR5IGhlYWRlcnMu ICBIb3dldmVyLCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIHNpZ24gYWxsDQoNCg0KDQpTaW5nbGUg cXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQoiLi4uaGVhZGVyIGZpZWxkcy4u LiINCg0KDQogICBjb250ZW50IG9mIGEgU0lQIFJlc291cmNlLVByaW9yaXR5IGhlYWRlciBvciBh bGwgU0lQIFJlc291cmNlLQ0KDQoNCg0KU2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVBy aW9yaXR5Jy4NCg0KIi4uLmhlYWRlciBmaWVsZC4uLiINCg0KDQogICBQcmlvcml0eSBoZWFkZXJz IGluIGEgZ2l2ZW4gU0lQIG1lc3NhZ2UuICBBbiBhdXRob3JpdHkgaXMgb25seQ0KDQoNCg0KU2lu Z2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy4NCg0KIi4uLmhlYWRlciBmaWVs ZHMuLi4iDQoNCg0KICAgcmVzcG9uc2libGUgZm9yIHNpZ25pbmcgdGhlIGNvbnRlbnQgb2YgYSBT SVAgUmVzb3VyY2UtUHJpb3JpdHkgaGVhZGVyDQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAn UmVzb3VyY2UtUHJpb3JpdHknLg0KDQoiLi4uaGVhZGVyIGZpZWxkLi4uIg0KDQoNCiAgIGZvciB3 aGljaCBpdCBoYXMgYXV0aG9yaXR5IChlLmcuLCBhIHNwZWNpZmljICJuYW1lc3BhY2UgIi4iDQog ICByLXByaW9yaXR5IikuDQoNCjQuMi4gIFZlcmlmaWNhdGlvbiBTZXJ2aWNlIEJlaGF2aW9yDQoN CiAgIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNdIFNlY3Rpb24gNi4yIFN0ZXAgNSByZXF1aXJl cyB0aGF0DQogICBzcGVjaWZpY2F0aW9ucyBkZWZpbmluZyAicHB0IiB2YWx1ZXMgZGVzY3JpYmUg YW55IGFkZGl0aW9uYWwgdmVyaWZpZXINCiAgIGJlaGF2aW9yLiAgVGhlIGJlaGF2aW9yIHNwZWNp ZmllZCBmb3IgdGhlICJwcHQiIHZhbHVlcyBvZiAicnBoIiBpcyBhcw0KICAgZm9sbG93czoNCg0K ICAgVGhlIHZlcmlmaWNhdGlvbiBzZXJ2aWNlIE1VU1QgZXh0cmFjdCB0aGUgdmFsdWUgYXNzb2Np YXRlZCB3aXRoIHRoZQ0KICAgImF1dGgiIGtleSBpbiBhIGZ1bGwgZm9ybSBQQVNTUG9yVCB3aXRo IGEgInBwdCIgdmFsdWUgb2YgInJwaCIuICBJZg0KICAgdGhlIHNpZ25hdHVyZSB2YWxpZGF0ZXMs IHRoZW4gdGhlIHZlcmlmaWNhdGlvbiBzZXJ2aWNlIGNhbiB1c2UgdGhlDQogICB2YWx1ZSBvZiB0 aGUgInJwaCIgY2xhaW0gYXMgdmFsaWRhdGlvbiB0aGF0IHRoZSBjYWxsaW5nIHBhcnR5IGlzDQog ICBhdXRob3JpemVkIGZvciBSZXNvdXJjZS1Qcmlvcml0eSwgd2hpY2ggd291bGQgaW4gdHVybiBi ZSB1c2VkIGZvcg0KDQoNClNpbmdsZSBxdW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScu DQoNClRoaXMgdGV4dCBpcyBhbWJpZ3VvdXMgYWJvdXQgd2hldGhlciB0aGUgdmFsaWRhdGlvbiBp bmRpY2F0ZXMgdGhhdCB0aGUgY2FsbGluZyBwYXJ0eSBpcyBhdXRob3JpemVkIHRvIHVzZSB0aGUg cHJpb3JpdGllcyBpbmRpY2F0ZWQgaW4gdGhlIHBhc3Nwb3J0IG9iamVjdCwgb3IgdGhlIHZhbHVl cyBpbiB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkOyBhbmQgKHRha2Vu IG9uIGl0cyBmYWNlKSBpbXBsaWVzIHRoZSBsYXR0ZXIsIHdoZW4gdGhlIGludGVudGlvbiBoZXJl IHNob3VsZCBjbGVhcmx5IGJlIHRoZSBmb3JtZXIuDQoNCiIuLi5hdXRob3JpemVkIGZvciAnUmVz b3VyY2UtUHJpb3JpdHknIGluZGljYXRlZCBpbiB0aGUgY2xhaW0uIFRoaXMgdmFsdWUgd291bGQg aW4gdHVybiBiZSB1c2VkIGZvci4uLiINCg0KVGhlIHRleHQgYWxzbyBuZWVkcyB0byBzYXkgc29t ZXRoaW5nIGFib3V0IGNvbXBhcmluZyB2YWx1ZXMgaW4gdGhlIGNsYWltIHRvIHZhbHVlcyBpbiB0 aGUgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQsIGFuZCB3aGF0IGEgbWlzbWF0Y2gg bWlnaHQgbWVhbi4gVGhlIGRvY3VtZW50IHNheXMgZWxzZXdoZXJlIHRoYXQgdGhlIHNpZ25hdHVy ZSBtaWdodCBvbmx5IGNvdmVyIHNvbWUgb2YgdGhlIHItdmFsdWVzLCB3aGljaCBtYWtlcyBpdCBl bnRpcmVseSBwb3NzaWJsZSB0aGF0IHRoZSAnUmVzb3VyY2UtUHJpb3JpdHknIGZpZWxkIG1pZ2h0 IGNvbnRhaW4gbW9yZSB2YWx1ZXMgdGhhbiBhcmUgc2lnbmVkLiBPbiB0aGUgb3RoZXIgaGFuZCwg aW50ZXJtZWRpYXJpZXMgbWlnaHQgcmVhc29uYWJseSByZW1vdmUgci12YWx1ZXMgYXMgdGhlIGNh bGwgaXMgcHJvY2Vzc2VkLiBUaGlzIHByb2JhYmx5IG1lYW5zIHRoYXQgdGhvc2UgcmVtb3ZlZCBw cmlvcml0aWVzIHNob3VsZCBub3QgYmUgdXNlZCwgZXZlbiBpZiB0aGV5IGFyZSBwcmVzZW50IGlu IHRoZSBwYXNzcG9ydC4gSXQgc2VlbXMgcmVhc29uYWJsZSB0byBzYXkgdGhhdCAqdHlwaWNhbCog cHJvY2Vzc2luZyBieSBhIHJlY2VpdmluZyBwYXJ0eSB3b3VsZCBiZSB0byB0YWtlIHRoZSAqdW5p b24qIG9mIGFsbCBSUEggcGFzc3BvcnRzIHRoYXQgdGhleSB0cnVzdCwgYW5kICppbnRlcnNlY3Qq IHRoYXQgd2l0aCB0aGUgcHJpb3JpdGllcyBpbiAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBm aWVsZHMgdG8gZ2V0IHRoZSBhY3R1YWwgcHJpb3JpdHkgb3IgcHJpb3JpdGllcyB0byBiZSBhcHBs aWVkIHRvIHRoZSBjYWxsIChzdWJqZWN0IHRvIGxvY2FsIHBvbGljeSkuDQoNCg0KICAgcHJpb3Jp dHkgdHJlYXRtZW50IGluIGFjY29yZGFuY2Ugd2l0aCBsb2NhbCBwb2xpY3kgZm9yIHRoZSBhc3Nv Y2lhdGVkDQogICBjb21tdW5pY2F0aW9uIHNlcnZpY2UuDQoNCiAgIEluIGFkZGl0aW9uLCBbSS1E LmlldGYtc3Rpci1yZmM0NDc0YmlzXSBTZWN0aW9uIDYuMiBTdGVwIDQgcmVxdWlyZXMNCiAgICJp YXQiIHZhbHVlIGluICJycGgiIGNsYWltIHRvIGJlIHZlcmlmaWVkLg0KDQogICBUaGUgYmVoYXZp b3Igb2YgYSBTSVAgVUFzIHVwb24gcmVjZWl2aW5nIGFuIElOVklURSBjb250YWluaW5nIGENCg0K DQoNCiIuLi5vZiBhIFNJUCBVQSB1cG9uLi4uIg0KDQpvcg0KDQoiLi4ub2YgU0lQIFVBcyB1cG9u Li4uIg0KDQoNCiAgIFBBU1Nwb3JUIG9iamVjdCB3aXRoIGEgInJwaCIgY2xhaW0gd2lsbCBsYXJn ZWx5IHJlbWFpbiBhIG1hdHRlciBvZg0KICAgaW1wbGVtZW50YXRpb24gcG9saWN5IGZvciB0aGUg c3BlY2lmaWMgY29tbXVuaWNhdGlvbiBzZXJ2aWNlLiAgSW4NCiAgIG1vc3QgY2FzZXMsaW1wbGVt ZW50YXRpb25zIHdvdWxkIGFjdCBiYXNlZCBvbiBjb25maWRlbmNlIGluIHRoZQ0KDQoNCg0KIi4u LmNhc2VzLCBpbXBsZW1lbnRhdGlvbnMuLi4iDQoNCihzcGFjZSBhZnRlciBjb21tYSkNCg0KDQog ICB2ZXJhY2l0eSBvZiB0aGlzIGluZm9ybWF0aW9uLiAgVGhlIHVzZSBvZiB0aGUgY29tcGFjdCBm b3JtIG9mDQoNCg0KDQpQYXJhZ3JhcGggYnJlYWsgYmVmb3JlICJUaGUiLg0KDQoNCiAgIFBBU1Nw b3JUIGlzIG5vdCBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudC4NCg0KNS4gIEZ1cnRoZXIgSW5m b3JtYXRpb24gQXNzb2NpYXRlZCB3aXRoIFJlc291cmNlLVByaW9yaXR5DQoNCg0KDQpTaW5nbGUg cXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLg0KDQoNCg0KICAgVGhlcmUgbWF5IGJl IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNhbGxpbmcgcGFydHkgb3IgdGhlDQog ICBjYWxsIHRoYXQgY291bGQgYmUgcmVsZXZhbnQgdG8gYXV0aG9yaXphdGlvbiBmb3IgUmVzb3Vy Y2UtUHJpb3JpdHkuDQoNCg0KDQpTaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3Jp dHknLg0KDQoNCiAgIFRoaXMgbWF5IGluY2x1ZGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUg ZGV2aWNlIHN1YnNjcmlwdGlvbiBvZg0KICAgdGhlIGNhbGxlciwgb3IgdG8gYW55IGluc3RpdHV0 aW9ucyB0aGF0IHRoZSBjYWxsZXIgb3IgZGV2aWNlIGlzDQogICBhc3NvY2lhdGVkIHdpdGgsIG9y IGV2ZW4gY2F0ZWdvcmllcyBvZiBpbnN0aXR1dGlvbnMuICBBbGwgb2YgdGhlc2UNCiAgIGRhdGEg ZWxlbWVudHMgd291bGQgYmVuZWZpdCBmcm9tIHRoZSBzZWN1cmUgYXR0ZXN0YXRpb25zIHByb3Zp ZGVkIGJ5DQogICB0aGUgU1RJUiBhbmQgUEFTU3BvclQgZnJhbWV3b3Jrcy4gIFRoZSBzcGVjaWZp Y2F0aW9uIG9mIHRoZSAicnBoIg0KICAgY2xhaW0gY291bGQgZW50YWlsIHRoZSBvcHRpb25hbCBw cmVzZW5jZSBvZiBvbmUgb3IgbW9yZSBzdWNoDQogICBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGZp ZWxkcy4NCg0KICAgQSBuZXcgSUFOQSByZWdpc3RyeSBoYXMgYmVlbiBkZWZpbmVkIHRvIGhvbGQg cG90ZW50aWFsIHZhbHVlcyBvZiB0aGUNCiAgICJycGgiIGFycmF5OyBzZWUgU2VjdGlvbiA2LjIu ICBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgInJwaCIgY2xhaW0gbWF5DQogICBoYXZlIG9uZSBvciBt b3JlIHN1Y2ggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBmaWVsZChzKS4gIERldGFpbHMgb2YNCiAg IHN1Y2ggInJwaCIgY2xhaW0gdG8gZW5jb21wYXNzIG90aGVyIGRhdGEgZWxlbWVudHMgYXJlIGxl ZnQgZm9yIGZ1dHVyZQ0KICAgdmVyc2lvbiBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNCjYuICBJ QU5BIENvbnNpZGVyYXRpb25zDQoNCjYuMS4gIEpTT04gV2ViIFRva2VuIENsYWltcyBSZWdpc3Ry YXRpb24NCg0KDQoNCkkgdGhpbmsgdGhlcmUncyBzb21lIGNvbmZ1c2lvbiBoZXJlLiBZb3UncmUg cmVnaXN0ZXJpbmcgYSBQQVNTcG9yVCBwcHQgdmFsdWUsIG5vdCBhIG5ldyBKV1QgY2xhaW0uIFRo YXQgaXMgdG8gc2F5LCB5b3UncmUgYWRkaW5nIGFuIGVudHJ5IHRvIHRoaXMgdGFibGU6DQoNCmh0 dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Bhc3Nwb3J0L3Bhc3Nwb3J0LnhodG1sPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmlh bmEub3JnX2Fzc2lnbm1lbnRzX3Bhc3Nwb3J0X3Bhc3Nwb3J0LnhodG1sJmQ9RHdNRmFRJmM9TEZZ Wi1vOV9IVU1lTVRTUWljdmpJZyZyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcmbT1zbEtJQlkzN3k4 cDRpQzNKZ2p1d0QxVEk5T2dXN1FUSFd6bUpWeXF5Sk5nJnM9WEhJc1dNdXl0QTZNanU2bWlFelZw bnQwRDRaeGtBQlRTdkotamZjWXVUVSZlPT4NCg0KTm90IHRvIHRoaXMgdGFibGU6DQoNCmh0dHBz Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2p3dC9qd3QueGh0bWw8aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWFuYS5vcmdfYXNzaWdu bWVudHNfand0X2p3dC54aHRtbCZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1H OXY4dUNTU1FoQ21wdzdJdEcwcjJnJm09c2xLSUJZMzd5OHA0aUMzSmdqdXdEMVRJOU9nVzdRVEhX em1KVnlxeUpOZyZzPUF6bWpmbzU0NllIV2s5cjRIUVdkRUI1UGpZOU54QVA4bGx1V2ZhNmZfQjQm ZT0+DQoNCllvdSB3b3VsZCBvbmx5IHVzZSB0aGUgc2Vjb25kIHRhYmxlIGlmIHlvdSBoYWQgYSBu ZXcga2V5IHRvIGFkZCB0byB0aGUgUEFTU3BvclQgaGVhZGVyIC0tIHRoaXMgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBkbyB0aGF0Lg0KDQpUaGlzIHNlY3Rpb24gYWxzbyBuZWVkcyBzb21lIGludHJv ZHVjdG9yeSB0ZXh0IHRvIGxldCB0aGUgSUFOQSBrbm93IGV4YWN0bHkgd2hhdCB0byBkbzsgZS5n LiAiVGhpcyBkb2N1bWVudCByZWdpc3RlcnMgYSBuZXcgdmFsdWUgZm9yIHRoZSAiUGVyc29uYWwg QXNzZXJ0aW9uIFRva2VuIChQQVNTcG9yVCkgRXh0ZW5zaW9ucyIgdGFibGUuDQoNCiAgIG8gIHBw dCB2YWx1ZTogInJwaCINCg0KICAgbyAgU3BlY2lmaWNhdGlvbiBEb2N1bWVudChzKTogU2VjdGlv biAzIG9mIFtSRkNUaGlzXQ0KDQo2LjIuICBQQVNTcG9yVCAncnBoJyBUeXBlcw0KDQogICBUaGlz IGRvY3VtZW50IHJlcXVlc3RzIHRoYXQgdGhlIElBTkEgYWRkIGEgbmV3IGVudHJ5IHRvIHRoZSBQ QVNTcG9yVA0KICAgVHlwZXMgcmVnaXN0cnkgZm9yIHRoZSB0eXBlICJycGgiIHdoaWNoIGlzIHNw ZWNpZmllZCBpbiBbUkZDVGhpc10uDQoNCg0KDQpUaGVyZSBpc24ndCBhbiBJQU5BIHRhYmxlIGNh bGxlZCAiUEFTU3BvclQgVHlwZXMuIiBJIHByZXN1bWUgdGhpcyBpcyB0aGUgcmVnaXN0cmF0aW9u IHdlIGp1c3QgZGlzY3Vzc2VkIGluIHNlY3Rpb24gNi4xLCBhbmQgc28gdGhlIGFib3ZlIHR3byBs aW5lcyBjYW4gYmUgcmVtb3ZlZC4NCg0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gYWxzbyByZXF1 ZXN0cyB0aGF0IHRoZSBJQU5BIGNyZWF0ZSBhIG5ldyByZWdpc3RyeQ0KICAgZm9yIFBBU1Nwb3JU ICJycGgiIHR5cGVzLiAgUmVnaXN0cmF0aW9uIG9mIG5ldyBQQVNTcG9yVCAicnBoIiB0eXBlcw0K ICAgc2hhbGwgYmUgdW5kZXIgdGhlIHNwZWNpZmljYXRpb24gcmVxdWlyZWQgcG9saWN5LiAgVGhp cyByZWdpc3RyeSBpcw0KICAgdG8gYmUgaW5pdGlhbGx5IHBvcHVsYXRlZCB3aXRoIGEgc2luZ2xl IHZhbHVlIGZvciAiYXV0aCIgd2hpY2ggaXMNCiAgIHNwZWNpZmllZCBpbiBbUkZDVGhpc10uDQoN Cg0KDQpUaGlzIG5lZWRzIHRvIGJlIHZlcnkgY2xlYXIgYWJvdXQgdGhlIGZpZWxkcyB0byBiZSBp bmNsdWRlZCBpbiB0aGlzIG5ldyByZWdpc3RyeSAoZS5nLiwgIlJlZ2lzdHJ5IGVudHJpZXMgbXVz dCBjb250YWluIHR3byBmaWVsZHM6IHRoZSBuYW1lIG9mIHRoZSAncnBoJyB0eXBlIGFuZCB0aGUg c3BlY2lmaWNhdGlvbiBpbiB3aGljaCB0aGUgdHlwZSBpcyBkZXNjcmliZWQiKS4NCg0KDQoNCjcu ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgZGlzY3Vzc2VkIGluIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNdDQogICBpbiBTZWN0aW9u IDEwIGFyZSBhcHBsaWNhYmxlIGhlcmUuDQoNCjcuMS4gIEF2b2lkYW5jZSBvZiByZXBsYXkgYW5k IGN1dCBhbmQgcGFzdGUgYXR0YWNrcw0KDQogICBUaGUgUEFTU3BvclQgZXh0ZW5zaW9uIHdpdGgg YSAicHB0IiB2YWx1ZSBvZiAicnBoIiBNVVNUIG9ubHkgYmUgc2VudA0KICAgd2l0aCBTSVAgSU5W SVRFIHdoZW4gJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgaXMgdXNlZCB0byBjb252ZXkgdGhl DQoNCg0KDQoiLi4uaGVhZGVyIGZpZWxkLi4uIg0KDQoNCiAgIHByaW9yaXR5IG9mIHRoZSBjb21t dW5pY2F0aW9uIGFzIGRlZmluZWQgaW4gW1JGQzQ0MTJdLiAgVG8gYXZvaWQgdGhlDQogICByZXBs YXksIGFuZCBjdXQgYW5kIHBhc3RlIGF0dGFja3MsIHRoZSBwcm9jZWR1cmVzIGRlc2NyaWJlZCBp bg0KICAgU2VjdGlvbiAxMC4xIG9mIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0NzRiaXNdIE1VU1QgYmUg Zm9sbG93ZWQuDQoNCjcuMi4gIFNvbHV0aW9uIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSB1c2Ug b2YgZXh0ZW5zaW9uIHRvIFBBU1Nwb3JUIHRva2VucyB3aXRoICJwcHQiIHZhbHVlICJycGgiIGJh c2VkDQogICBvbiB0aGUgdmFsaWRhdGlvbiBvZiB0aGUgZGlnaXRhbCBzaWduYXR1cmUgYW5kIHRo ZSBhc3NvY2lhdGVkDQogICBjZXJ0aWZpY2F0ZSByZXF1aXJlcyBjb25zaWRlcmF0aW9uIG9mIHRo ZSBhdXRoZW50aWNhdGlvbiBhbmQNCiAgIGF1dGhvcml0eSBvciByZXB1dGF0aW9uIG9mIHRoZSBz aWduZXIgdG8gYXR0ZXN0IHRvIHRoZSBpZGVudGl0eSBiZWluZw0KICAgYXNzZXJ0ZWQuICBUaGUg Zm9sbG93aW5nIGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZSByZWNvZ25pemVkIHdoZW4NCiAgIHVz aW5nIFBBU1Nwb3JUIGV4dGVuc2lvbiB3aXRoICJwcHQiIHZhbHVlIG9mICJycGgiOg0KDQogICBv ICBBbiBhdXRob3JpdHkgKHNpZ25lcikgaXMgb25seSBhbGxvd2VkIHRvIHNpZ24gdGhlIGNvbnRl bnQgb2YgYSBTSVANCiAgICAgICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZvciB3aGljaCBp dCBoYXMgdGhlIHJpZ2h0IGF1dGhvcml0eS4NCg0KDQoNCiIuLi5oZWFkZXIgZmllbGQuLi4iDQoN Cg0KICAgICAgVGhlIGF1dGhvcml0eSB0aGF0IHNpZ25zIHRoZSB0b2tlbiBNVVNUIGhhdmUgYSBz ZWN1cmUgbWV0aG9kIGZvcg0KICAgICAgYXV0aGVudGljYXRpb24gb2YgdGhlIGVuZCB1c2VyIG9y IHRoZSBkZXZpY2UuDQoNCiAgIG8gIFRoZSB2ZXJpZmljYXRpb24gb2YgdGhlIHNpZ25hdHVyZSBN VVNUIGluY2x1ZGUgbWVhbnMgb2YgdmVyaWZ5aW5nDQogICAgICB0aGF0IHRoZSBzaWduZXIgaXMg YXV0aG9yaXRhdGl2ZSBmb3IgdGhlIHNpZ25lZCBjb250ZW50IG9mIHRoZSBTSVANCg0KDQoNCkl0 J3Mgbm90IGNsZWFyIHdoYXQgYXV0aG9yaXR5IGlzIGJlaW5nIGNsYWltZWQgaGVyZS4gSXMgdGhp cyBzdXBwb3NlZCB0byBtZWFuIHNvbWV0aGluZyBsaWtlICIuLi52ZXJpZnlpbmcgdGhhdCB0aGUg c2lnbmVyIGlzIGF1dGhvcml0YXRpdmUgZm9yIHRoZSBvcmlnaW5hdGluZyB0biBpbiB0aGUgUEFT U3BvclQuLi4iPyBPciAiLi4uYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIHJlc291cmNlIHByaW9yaXR5 IG5hbWVzcGFjZSBpbiB0aGUgUEFTU3BvclQ/IiBXaGF0ZXZlciB0aGUgc2VydmVyIGlzIHB1cnBv cnRlZGx5IGF1dGhvcml0YXRpdmUgZm9yIG5lZWRzIHRvIGJlIGNsZWFybHkgc3BlbGxlZCBvdXQu DQoNCg0KICAgICAgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIuDQoNCg0KDQoiLi4uaGVhZGVy IGZpZWxkLiINCg0KDQovYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc3RpciBtYWlsaW5nIGxpc3QNCnN0aXJAaWV0Zi5vcmc8bWFpbHRvOnN0aXJA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0aXI8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zdGlyJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWlj dmpJZyZyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcmbT1zbEtJQlkzN3k4cDRpQzNKZ2p1d0QxVEk5 T2dXN1FUSFd6bUpWeXF5Sk5nJnM9dTZRQ3JubWtqenF4dTZRM1pUTTZNQ1VQUGp3WEZiaVluUlJ0 TXBaVFg2SSZlPT4NCg0K --_000_E42CCDDA6722744CB241677169E8365668A592A9MISOUT7MSGUSRDB_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQp0dA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2NzQ1Nzk0NTk7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02NjA4MzA3MDY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0K CXttc28tbGlzdC1pZDoxMDMyNzMxMjQ2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTEwNjMy Nzc4ODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjExODU4OTczMDI7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0yMDA2NjU1Njc2O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNv LWxpc3QtaWQ6MjAyMjU4MjMzMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMxNDAwMzQwO30N CkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+V2Ugb25seSBoYXZlIG9uZSBjbGFpbSBhbmQgdGhhdCBpcyB0aGUg UlBIPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gU3ViaXIgW21haWx0bzpzdWJpcmRhczIx QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEZlYnJ1YXJ5IDA0LCAyMDE4 IDU6NTYgUE08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBZGFtIFJvYWNoICZsdDth ZGFtQG5vc3RydW0uY29tJmd0OzsgU1RJUiBDaGFpcnMgJmx0O3N0aXItY2hhaXJzQGlldGYub3Jn Jmd0Ozsgc3RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zdGlyLXJwaC5hbGxAdG9vbHMuaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzdGlyXSBBRCBSZXZpZXc6IGRyYWZ0LWlldGYt c3Rpci1ycGgtMDIgLSBhdXRob3JpdHkgdG8gYXNzZXJ0IHRoZSBjYWxsZXJzIGlkZW50aXR5IGFz c3VtZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCldlIGNhbiBhZGQgc29tZSB0ZXh0cyB0byBjbGFyaWZ5IHRoYXQgaW4gdGhlIG5l eHQgdmVyc2lvbi4gVGhlIHBvaW50IGlzIHRoYXQgaW4gc29tZSB1c2UgY2FzZXMgc2VydmljZSBw cm92aWRlciBtYXkgaGF2ZSB0aGUgYXV0aG9yaXR5IHRvICZuYnNwO290aGVyIGNsYWltcyBzdWNo IGFzICdvcmlnJyBhbmQgaW4gb3RoZXIgY2FzZXMgaXQgbWF5IG5vdCBoYXZlLiAmbmJzcDtXZSBj YW4gYWRkIGEgbWF5IHN0YXRlbWVudCBjbGFyaWZ5aW5nIHRoaXMgb3IgZXhwbGljaXRseQ0KIHNh eSB0aGF0IGl0IGlzIG5vdCByZXF1aXJlZCB0byBoYXZlIGF1dGhvcml0eSB0byBvdGhlciBjbGFp bXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3ViaXImbmJzcDs8 YnI+DQpTZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9u IEZlYiA0LCAyMDE4LCBhdCAxMDowMyBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgdGV4dCBz YXlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IOKAnFRoZSBjcmVkZW50aWFscyAoZS5nLiwgYXV0aG9yaXR5IHJlc3BvbnNpYmxlIGZvciBh dXRob3JpemluZyBSZXNvdXJjZS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IFByaW9y aXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlIG11c3QgaGF2ZSBhdXRob3JpdHkgb3Zl ciB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG5hbWVzcGFjZSBvZiB0aGUgJnF1 b3Q7cnBoJnF1b3Q7IGNsYWltIGFuZCB0aGVyZSBpcyBvbmx5IG9uZSBhdXRob3JpdHkgcGVyPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBjbGFpbS7igJ08L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZSBjcmVkZW50aWFscyBkb27igJl0IG5lZWQg dG8gaGF2ZSBhdXRob3JpdHkgb2YgdGhlIG90aGVyIGNsYWltcyAoZS5nLiwg4oCcb3JpZ+KAnSkg aW4gdGhlIFJQSCBQQVNTUG9yVCBJIHRoaW5rIHlvdSBzaG91bGQgZXhwbGljaXRseSBzYXkgc28u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFN1YmlyIERhcyBbPGEgaHJlZj0ibWFpbHRvOnN1Ymly ZGFzMjFAZ21haWwuY29tIj5tYWlsdG86c3ViaXJkYXMyMUBnbWFpbC5jb208L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IDAyIEZlYnJ1YXJ5IDIwMTggMDE6MDQ8YnI+DQo8Yj5Ubzo8L2I+IENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNj OjwvYj4gQWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20iPmFk YW1Abm9zdHJ1bS5jb208L2E+Jmd0OzsgU1RJUiBDaGFpcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpz dGlyLWNoYWlyc0BpZXRmLm9yZyI+c3Rpci1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhy ZWY9Im1haWx0bzpzdGlyQGlldGYub3JnIj5zdGlyQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtc3Rpci1ycGguYWxsQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYt c3Rpci1ycGguYWxsQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3N0aXJdIEFEIFJldmlldzogZHJhZnQtaWV0Zi1zdGlyLXJwaC0wMiAtIGF1dGhvcml0eSB0byBh c3NlcnQgdGhlIGNhbGxlcnMgaWRlbnRpdHkgYXNzdW1lZD88L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8gQ2hyaXN0ZXIsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2lnbmluZyBlbnRpdHkgZG9l cyBub3QgaGF2ZSBhbHdheXMgdGhlIGF1dGhvcml0eSB0byBhc3NlcnQgdGhlIGNhbGxlciBpZGVu dGl0eSBpbiBycGguIFdlIGFyZSBzdWJtaXR0aW5nIHZlci0wMyBkcmFmdCZuYnNwOyBhbmQgaXQg aXMgY2xhcmlmaWVkJm5ic3A7IGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ JnF1b3Q7VGhlIGNyZWRlbnRpYWxzIChlLmcuLCBhdXRob3JpdHkgcmVzcG9uc2libGUgZm9yIGF1 dGhvcml6aW5nIFJlc291cmNlLVByaW9yaXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJl IG11c3QgaGF2ZSBhdXRob3JpdHkgb3ZlciB0aGUgbmFtZXNwYWNlIG9mIHRoZeKAnHJwaCZxdW90 Ow0KIGNsYWltLi4mcXVvdDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LVN1 YmlyDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIE1vbiwgSmFuIDIyLCAyMDE4IGF0IDM6MjcgUE0sIENocmlzdGVyIEhvbG1i ZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0 YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QW5vdGhlciBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDMgY29u dGFpbnMgdGhlIGZvbGxvd2luZyBleGFtcGxlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyB7ICZxdW90O29yaWcmcXVvdDs6 eyZxdW90O3RuJnF1b3Q7OiZxdW90Ozwvc3Bhbj48YSBocmVmPSJ0ZWw6KDIxNSklMjA1NTUtMTIx MiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MTIxNTU1NTEyMTI8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mcXVvdDt9PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2Rlc3QmcXVvdDs6e1smcXVvdDt0biZx dW90OzomcXVvdDs8L3NwYW4+PGEgaHJlZj0idGVsOigyMTIpJTIwNTU1LTEyMTMiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEyMTI1NTUxMjEzPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+JnF1b3Q7XX0sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2lhdCZxdW90OzoxNDQzMjA4MzQ1LDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtycGgmcXVvdDs6eyZxdW90 O2F1dGgmcXVvdDs6WyZxdW90O2V0cy4wJnF1b3Q7LCZxdW90O3dwcy4wJnF1b3Q7XX08L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igKZhbmQgdGhlIGZvbGxv d2luZyB0ZXh0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyDigJxUaGUgY3JlZGVudGlhbHMgKGUuZy4sIGF1dGhvcml0eSByZXNwb25z aWJsZSBmb3IgYXV0aG9yaXppbmcgUmVzb3VyY2UtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IFByaW9yaXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlIG11c3QgaGF2ZSBh dXRob3JpdHkgb3ZlciB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgJnF1b3Q7 cnBoJnF1b3Q7IGNsYWlt4oCm4oCdDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fLTI5Mzg3NDc5MDYxMjMyMDM0OTRfX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlNpbmNlIHRoZSBjbGFpbSBhbHNvIGNvbnRhaW5zIOKAnG9yaWfigJ0sIGlzIHRo ZSBhc3N1bXB0aW9uIHRoYXQgdGhlIHNpZ25pbmcgZW50aXR5IGFsd2F5cyBhbHNvIGhhcyBhdXRo b3JpdHkNCiB0byBhc3NlcnQgdGhlIGNhbGxlcnMgaWRlbnRpdHk/IEkgdGhpbmsgaXQgd291bGQg YmUgZ29vZCB0byBleHBsaWNpdGx5IG1lbnRpb24gaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHN0aXIgW21haWx0bzo8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnN0aXItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+c3Rpci1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWRhbSBSb2FjaDxicj4NCjxiPlNl bnQ6PC9iPiAyMCBKYW51YXJ5IDIwMTggMDA6MTU8YnI+DQo8Yj5Ubzo8L2I+IFNUSVIgQ2hhaXJz ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnN0aXItY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5zdGlyLWNoYWlyc0BpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzdGlyQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5zdGlyQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi1zdGlyLXJwaC5hbGxAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPmRyYWZ0LWlldGYtc3Rpci1ycGguYWxsQHRvb2xzLmlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc3Rpcl0gQUQgUmV2aWV3OiBk cmFmdC1pZXRmLXN0aXItcnBoLTAyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5JJ20g ZG9pbmcgbXkgQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc3Rpci1ycGgtMDIuIFRoYW5rcyB0byBl dmVyeW9uZSB3aG8gaGFzIHdvcmtlZCBvbiB0aGlzIGRvY3VtZW50LCBhbmQgdGhlIGF1dGhvcnMg YW5kIGNoYWlycyBpbiBwYXJ0aWN1bGFyLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIHRlY2huaWNh bCBjb250ZW50IGhlcmUgbG9va3MgZ2VuZXJhbGx5IGdvb2QgdG8gbWUuIEknZCBsaWtlIHRvIHNl ZSBhIGZldyBpc3N1ZXMgYWRkcmVzc2VkIGJlZm9yZSBJRVRGIExDLiBJbiBzaG9ydCBzdW1hcnk6 PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpUaGUgdmFsaWRhdGlv biBzZWN0aW9uIG5lZWRzIHRvIGFkZCBhIGRpc2N1c3Npb24gb2YgaG93IHRvIHRyZWF0IGNhbGxz IHdoZW4gdGhlIHByaW9yaXR5IHZhbHVlcyBpbiAmcXVvdDtycGgmcXVvdDsgcGFzc3BvcnRzIGFu ZCBTSVAgJnF1b3Q7UmVzb3VyY2UtUHJpb3JpdHkmcXVvdDsgaGVhZGVyIGZpZWxkcyBhcmVuJ3Qg MTAwJSBpZGVudGljYWwuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NClRoZSBleGFtcGxlcyBuZWVk IHNvbWUgYWRqdXN0bWVudC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KVGhlcmUgaXMgYSBtaW5v ciBwb2ludCBvZiBhbWJpZ3VpdHkgaW4gdGhlIFNlY3VyaXR5IFNlY3Rpb24sIGJ1dCB0aGlzIHNo b3VsZCBiZSBlYXN5IHRvIGZpeCwgYXMgbG9uZyBhcyB0aGUgV0cga25vd3Mgd2hhdCB3YXMgaW50 ZW5kZWQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NClRoZSBJQU5BIGFjdGlvbnMgbmVlZCBhIGxp dHRsZSBiaXQgb2YgYWRqdXN0bWVudC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KVGhlcmUgYXJl IGEgbnVtYmVyIG9mIG1pbm9yIGVkaXRvcmlhbCBpc3N1ZXMgdG8gYmUgY2xlYW5lZCB1cC48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwPkRldGFpbGVkIGNvbW1lbnRzIG9uIHRoZXNlIHBvaW50cyBh cmUgaW5saW5lIGluIHRoZSBkb2N1bWVudCBiZWxvdy4gSSd2ZSByZW1vdmVkIHNvbWUgcG9ydGlv bnMgb2YgdGhlIGRvY3VtZW50IG9uIHdoaWNoIEkgaGF2ZSBubyBjb21tZW50cy48bzpwPjwvbzpw PjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YnI+DQo8dHQ+QWJzdHJhY3Q8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgVGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBTVElSIFBBU1Nwb3JUIHNwZWNpZmljYXRp b24gdG8gYWxsb3cgdGhlPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLnRoZSBTZWN1cmUgVGVsZXBo b25lIElkZW50aXR5IFJldmlzaXRlZCAoU1RJUikgUGVyc29uYWwgQXNzZXJ0aW9uIFRva2VuIChQ QVNTcG9yVCkgc3BlY2lmaWNhdGlvbiBkZWZpbmVkIGluIFJGQyA4MTIyLi4uJnF1b3Q7PG86cD48 L286cD48L3A+DQo8cD4oU2VlIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LnJmYy0yRGVkaXRvci5vcmdfbWF0ZXJpYWxzX2Fi YnJldi5leHBhbnNpb24udHh0JmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2 aklnJmFtcDtyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcmYW1wO209c2xLSUJZMzd5OHA0aUMzSmdq dXdEMVRJOU9nVzdRVEhXem1KVnlxeUpOZyZhbXA7cz1pQlRBaHdONTE3Qk5Bcm1qOGJiOFVhdDNM QUlmU3FFYjNPenVxSE9sNmtvJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KJmx0O2h0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dCZndDs8L2E+ IGZvciBndWlkYW5jZSBvbiBhYmJyZXZpYXRpb25zKTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgaW5jbHVzaW9uIG9mIGNyeXB0b2dyYXBo aWNhbGx5LXNpZ25lZCBhc3NlcnRpb25zIG9mIGF1dGhvcml6YXRpb24gZm9yPC9zcGFuPjwvdHQ+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgdGhlIHZhbHVlcyBwb3B1bGF0ZWQgaW4g dGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCw8L3R0Pjxicj4NCjx0dD4m bmJzcDsmbmJzcDsgd2hpY2ggaXMgdXNlZCBmb3IgY29tbXVuaWNhdGlvbnMgcmVzb3VyY2UgcHJp b3JpdGl6YXRpb24uPC90dD48YnI+DQo8YnI+DQo8dHQ+Li4uPC90dD48YnI+DQo8YnI+DQo8dHQ+ MS4mbmJzcDsgSW50cm9kdWN0aW9uPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFBB U1Nwb3JUIFtJLUQuaWV0Zi1zdGlyLXBhc3Nwb3J0XSBpcyBhIHRva2VuIGZvcm1hdCBiYXNlZCBv biBKV1Q8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgW1JGQzc1MTldIGZvciBjb252ZXlpbmcg Y3J5cHRvZ3JhcGhpY2FsbHktc2lnbmVkIGluZm9ybWF0aW9uIGFib3V0PC90dD48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IHRoZSBpZGVudGl0aWVzIGludm9sdmVkIGluIHBlcnNvbmFsIGNvbW11bmlj YXRpb25zOyBpdCBpcyB1c2VkIHdpdGg8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgU1RJUiBb SS1ELmlldGYtc3Rpci1yZmM0NDc0YmlzXSB0byBjb252ZXkgYSBzaWduZWQgYXNzZXJ0aW9uIG9m IHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpZGVudGl0eSBvZiB0aGUgcGFydGljaXBh bnRzIGluIHJlYWwtdGltZSBjb21tdW5pY2F0aW9ucyBlc3RhYmxpc2hlZDwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyB2aWEgYSBwcm90b2NvbCBsaWtlIFNJUC4mbmJzcDsgVGhpcyBzcGVjaWZp Y2F0aW9uIGV4dGVuZHMgUEFTU3BvclQgdG88L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4ubGlrZSBT SVAgW1JGQzMyNjFdLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4oV2Ugd2FudCB0byBjaXRl IFNJUCB0aGUgZmlyc3QgdGltZSBpdCBpcyBtZW50aW9uZWQpPG86cD48L286cD48L3A+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBhbGxvdyBjcnlwdG9ncmFwaGlj LXNpZ25pbmcgb2YgdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlcjwvc3Bhbj48L3R0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGZpZWxkIGRlZmluZWQgaW4gW1JGQzQ0 MTJdLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBbUkZDNDQxMl0gZGVmaW5lcyB0 aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGZvcjwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyBjb21tdW5pY2F0aW9ucyBSZXNvdXJjZSBQcmlvcml0eS4mbmJzcDsgQXMg c3BlY2lmaWVkIGluIFtSRkM0NDEyXSwgdGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7ICdS ZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIG1heSBiZSB1c2VkIGJ5IFNJUCB1c2VyIGFn ZW50czwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBbUkZDMzI2MV0sIGluY2x1ZGluZywgUHVi bGljIFN3aXRjaGVkIFRlbGVwaG9uZSBOZXR3b3JrIChQU1ROKTwvdHQ+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mcXVv dDsuLi5pbmNsdWRpbmcgUHVibGljIFN3aXRjaGVkLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8 cD4ocmVtb3ZlIHRoZSBjb21tYSk8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGdhdGV3YXlzIGFuZCB0ZXJtaW5hbHMsIGFuZCBTSVAgcHJv eHkgc2VydmVycyB0byBpbmZsdWVuY2U8L3NwYW4+PC90dD48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uYW5kIGJ5IFNJ UCBwcm94eSBzZXJ2ZXJzLCB0byBpbmZsdWVuY2UuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw PihhZGQgJnF1b3Q7YnkmcXVvdDsgYW5kIGNvbW1hKTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgcHJpb3JpdGl6YXRpb24gYWZmb3JkZWQg dG8gY29tbXVuaWNhdGlvbiBzZXNzaW9ucyxpbmNsdWRpbmcgUFNUTjwvc3Bhbj48L3R0PjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLnNlc3Npb25zLCBpbmNsdWRpbmcuLi4mcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjxwPihzcGFjZSBhZnRlciBjb21tYSk8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGNhbGxzLiZuYnNwOyBIb3dl dmVyLCB0aGUgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGNvdWxkIGJlPC9z cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgc3Bvb2ZlZCBhbmQgYWJ1 c2VkIGJ5IHVuYXV0aG9yaXplZCBlbnRpdGllcy48L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgVGhlIFNUSVIgYXJjaGl0ZWN0dXJlIFtSRkM3MzQwXWFzc3VtZXMgdGhhdCBhbiBhdXRo b3JpdHkgb24gdGhlPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLlNUSVIgYXJjaGl0ZWN0dXJlIFtS RkM3MzQwXSBhc3N1bWVzLi4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4oc3BhY2UgYmVmb3Jl ICZxdW90O2Fzc3VtZXMmcXVvdDspPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBvcmlnaW5hdGluZyBzaWRlIG9mIGEgY2FsbCBwcm92aWRl cyBhIGNyeXB0b2dyYXBoaWMgYXNzdXJhbmNlIG9mIHRoZTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHZhbGlkaXR5IG9mIHRoZSBjYWxsaW5nIHBhcnR5IG51bWJl ciBpbiBvcmRlciB0byBwcmV2ZW50PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGltcGVyc29u YXRpb24gYXR0YWNrcy4mbmJzcDsgVGhlIFNUSVIgYXJjaGl0ZWN0dXJlIGFsbG93cyBleHRlbnNp b24gdGhhdDwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5hbGxvd3MgZXh0ZW5zaW9ucy4uLiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJz cDsgY2FuIGJlIHV0aWxpemVkIGJ5IGF1dGhvcml0aWVzIHN1cHBvcnRpbmcgcmVhbC10aW1lIGNv bW11bmljYXRpb248L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBz ZXJ2aWNlcyB1c2luZyB0aGUgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQgdG88L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgY3J5cHRvZ3JhcGhpY2FsbHkgc2lnbiB0aGUgU0lQICdS ZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGFuZDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBjb252ZXkgYXNzZXJ0aW9uIG9mIHRoZSBhdXRob3JpemF0aW9uIGZvciAnUmVzb3VyY2Ut UHJpb3JpdHknLiZuYnNwOyBGb3I8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgZXhhbXBsZSwg dGhlIGF1dGhvcml0eSBvbiB0aGUgb3JpZ2luYXRpbmcgc2lkZSB2ZXJpZnlpbmcgdGhlPC90dD48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGF1dGhvcml6YXRpb24gb2YgYSBwYXJ0aWN1bGFyIGNvbW11 bmljYXRpb24gZm9yIFJlc291cmNlLVByaW9yaXR5IGNhbjwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5TaW5nbGUg cXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3JpdHknLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgdXNlIGEgUEFTU1BvclQgY2xhaW0g dG8gY3J5cHRvZ3JhcGhpY2FsbHktc2lnbiB0aGUgU0lQICdSZXNvdXJjZS08L3NwYW4+PC90dD48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHA+JnF1b3Q7Li4uY3J5cHRvZ3JhcGhpY2FsbHkgc2lnbi4uLiZxdW90OzxvOnA+PC9vOnA+PC9w Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0 PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgUHJpb3JpdHknIGhl YWRlciBmaWVsZCBhbmQgY29udmV5IGFuIGFzc2VydGlvbiBvZiB0aGUgYXV0aG9yaXphdGlvbjwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGZvciAnUmVzb3VyY2Ut UHJpb3JpdHknLiZuYnNwOyBUaGlzIHdpbGwgYWxsb3cgYSByZWNlaXZpbmcgZW50aXR5PC90dD48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IChpbmNsdWRpbmcgZW50aXRpZXMgbG9jYXRlZCBpbiBkaWZm ZXJlbnQgbmV0d29yayBkb21haW5zL2JvdW5kYXJpZXMpPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IHRvIHZlcmlmeSB0aGUgdmFsaWRpdHkgb2YgYXNzZXJ0aW9ucyBhdXRob3JpemluZyBSZXNv dXJjZS1Qcmlvcml0eS48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+U2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291 cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jm5ic3A7Jm5ic3A7IENyeXB0b2dyYXBoaWNhbGx5LXNpZ25lZCBTSVAgJ1Jlc291cmNlLVBy aW9yaXR5JyBoZWFkZXJzIHdpbGwgYWxsb3cgYTwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5jcnlw dG9ncmFwaGljYWxseSBzaWduZWQgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxk cy4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+KHJlbW92ZSBoeXBoZW4sIGFuZCByZXBsYWNl ICZxdW90O2hlYWRlcnMmcXVvdDsgd2l0aCAmcXVvdDtoZWFkZXIgZmllbGRzJnF1b3Q7KTxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgcmVj ZWl2aW5nIGVudGl0eSB0byB2ZXJpZnkgYW5kIGFjdCBvbiB0aGUgaW5mb3JtYXRpb24gd2l0aCBj b25maWRlbmNlPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgdGhh dCB0aGUgaW5mb3JtYXRpb24gaGF2ZSBub3QgYmVlbiBzcG9vZmVkIG9yIGNvbXByb21pc2VkLjwv dHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cD4mcXVvdDsuLi5oYXMgbm90IGJlZW4gc3Bvb2ZlZCBvciBjb21wcm9taXNl ZC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoaXMg c3BlY2lmaWNhdGlvbiBkb2N1bWVudHMgYW4gb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFBBU1Nwb3JU IGFuZDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB0aGUgYXNzb2NpYXRlZCBTVElSIG1lY2hh bmlzbXMgdG8gcHJvdmlkZSBhIGZ1bmN0aW9uIHRvIHNpZ24gdGhlIFNJUDwvdHQ+PGJyPg0KPHR0 PiZuYnNwOyZuYnNwOyAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZC4mbmJzcDsgVGhp cyBQQVNTcG9yVCBvYmplY3QgaXMgdXNlZCB0bzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBw cm92aWRlIGF0dGVzdGF0aW9uIG9mIGEgY2FsbGluZyB1c2VyIGF1dGhvcml6YXRpb24gZm9yIHBy aW9yaXR5PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNvbW11bmljYXRpb25zLiZuYnNwOyBU aGlzIGlzIG5lY2Vzc2FyeSBpbiBhZGRpdGlvbiB0byB0aGUgUEFTU3BvclQgb2JqZWN0PC90dD48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoYXQgaXMgdXNlZCBmb3IgY2FsbGluZyB1c2VyIHRlbGVw aG9uZSBudW1iZXIgYXR0ZXN0YXRpb24uJm5ic3A7IEhvdyB0aGU8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgb3B0aW9uYWwgZXh0ZW5zaW9uIHRvIFBBU1Nwb3JUIGlzIHVzZWQgZm9yIHJlYWwt dGltZSBjb21tdW5pY2F0aW9uczwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBzdXBwb3J0ZWQg dXNpbmcgU0lQICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVyIGZpZWxkIGlzIGRlZmluZWQgaW48 L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgb3RoZXIgZG9jdW1lbnRzIGFuZCBpcyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LjwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5JIGFzc3VtZSB0aGVz ZSBvdGhlciBkb2N1bWVudHMgYXJlIHVuZGVyIGRldmVsb3BtZW50PyBJZiBzbywgdGhleSBzaG91 bGQgYmUgY2l0ZWQgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Mi4mbmJzcDsg VGVybWlub2xvZ3k8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIGtleSB3b3Jk cyAmcXVvdDtNVVNUJnF1b3Q7LCAmcXVvdDtNVVNUIE5PVCZxdW90OywgJnF1b3Q7UkVRVUlSRUQm cXVvdDssICZxdW90O1NIQUxMJnF1b3Q7LCAmcXVvdDtTSEFMTCBOT1QmcXVvdDssPC90dD48YnI+ DQo8dHQ+Jm5ic3A7Jm5ic3A7ICZxdW90O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hPVUxEIE5PVCZx dW90OywgJnF1b3Q7UkVDT01NRU5ERUQmcXVvdDssICZxdW90O01BWSZxdW90OywgYW5kICZxdW90 O09QVElPTkFMJnF1b3Q7IGluIHRoaXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgZG9jdW1l bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjEx OV0uPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwPlRoaXMgZG9jdW1lbnQgaGFzIHNldmVyYWwgbm9uLW5vcm1hdGl2 ZSB1c2VzIG9mICZxdW90O211c3QmcXVvdDssICZxdW90O3Nob3VsZCwmcXVvdDsgYW5kICZxdW90 O21heSwmcXVvdDsgYW5kIHNvIGl0IG5lZWRzIHRvIHVzZSB0aGUgUkZDODE3NCBib2lsZXJwbGF0 ZSBpbnN0ZWFkIG9mIHRoZSBSRkMyMTE5IGJvaWxlcnBsYXRlLjxvOnA+PC9vOnA+PC9wPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCjx0dD4zLiZuYnNwOyBQQVNTcG9yVCAncnBoJyBDbGFpbTwvdHQ+PGJyPg0KPGJyPg0K PHR0PiZuYnNwOyZuYnNwOyBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIG5ldyBKU09OIFdl YiBUb2tlbiBjbGFpbSBmb3IgJnF1b3Q7cnBoJnF1b3Q7LDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyB3aGljaCBwcm92aWRlcyBhbiBhc3NlcnRpb24gZm9yIGluZm9ybWF0aW9uIGluIFNJUCAn UmVzb3VyY2UtPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFByaW9yaXR5J2hlYWRlci48L3R0 Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHA+JnF1b3Q7Li4uUHJpb3JpdHknIGhlYWRlciBmaWVsZC4mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjxwPihzcGFjZSBhZnRlciBjbG9zaW5nIHF1b3RhdGlvbiBtYXJrLCAmcXVvdDto ZWFkZXIgZmllbGQmcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDtoZWFkZXImcXVvdDspPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGUgY3JlYXRvciBvZiBhIFBBU1Nw b3JUIG9iamVjdCBhZGRzIGEgJnF1b3Q7cHB0JnF1b3Q7IHZhbHVlIG9mICZxdW90O3JwaCZxdW90 OyB0byB0aGU8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgaGVhZGVyIG9mIGEgUEFTU3BvclQg b2JqZWN0LCBpbiB3aGljaCBjYXNlIHRoZSBQQVNTcG9yVCBjbGFpbXMgTVVTVDwvdHQ+PGJyPg0K PHR0PiZuYnNwOyZuYnNwOyBjb250YWluIGEgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltLCBhbmQgYW55 IGVudGl0aWVzIHZlcmlmeWluZyB0aGUgUEFTU3BvclQgb2JqZWN0PC90dD48YnI+DQo8dHQ+Jm5i c3A7Jm5ic3A7IHdpbGwgYmUgcmVxdWlyZWQgdG8gdW5kZXJzdGFuZCB0aGUgJnF1b3Q7cHB0JnF1 b3Q7IGV4dGVuc2lvbiBpbiBvcmRlciB0bzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBwcm9j ZXNzIHRoZSBQQVNTcG9yVCBpbiBxdWVzdGlvbi4mbmJzcDsgQSBQQVNTUG9yVCBoZWFkZXIgd2l0 aCB0aGUgJnF1b3Q7cHB0JnF1b3Q7PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGluY2x1ZGVk IHdpbGwgbG9vayBhcyBmb2xsb3dzOjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB7 Jm5ic3A7ICZxdW90O3R5cCZxdW90OzomcXVvdDtwYXNzcG9ydCZxdW90Oyw8L3R0Pjxicj4NCjx0 dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7cHB0JnF1b3Q7OiZxdW90O3JwaCZxdW90 Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YWxnJnF1b3Q7 OiZxdW90O0VTMjU2JnF1b3Q7LDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDt4NXUmcXVvdDs6PC90dD48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuZXhhbXBsZS5vcmdfY2VydC5j ZXImYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9Rzl2OHVD U1NRaENtcHc3SXRHMHIyZyZhbXA7bT1zbEtJQlkzN3k4cDRpQzNKZ2p1d0QxVEk5T2dXN1FUSFd6 bUpWeXF5Sk5nJmFtcDtzPVdUVHVEbXkzOWkyekkzaWNNSG84MmNxUkdhWGp6SHl3SWdCQUlLMW9x Q1UmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZxdW90O2h0dHBzOi8vd3d3LmV4 YW1wbGUub3JnL2NlcnQuY2VyJnF1b3Q7PC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPn08L3NwYW4+PC90dD48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+SWRlYWxseSwgdGhpcyB3b3VsZCBiZSBlaXRo ZXIgcHJldHR5LXByaW50ZWQgb3IgY2Fub25pY2FsaXplZC4gU2luY2UgaXQncyB0b28gbG9uZyB0 byBmaXQgb24gYSBsaW5lIGluIGNhbm9uaWNhbCBmb3JtLCBJIHByb3Bvc2U6PG86cD48L286cD48 L3A+DQo8cD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPns8L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyAmcXVvdDt0eXAmcXVvdDs6JnF1b3Q7cGFzc3BvcnQm cXVvdDssPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZxdW90O3BwdCZxdW90OzomcXVvdDtycGgmcXVv dDssPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZxdW90O2FsZyZxdW90OzomcXVvdDtFUzI1NiZxdW90 Oyw8L3R0Pjxicj4NCjx0dD4mbmJzcDsgJnF1b3Q7eDV1JnF1b3Q7OjwvdHQ+PC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmV4YW1wbGUub3JnX2NlcnQuY2VyJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVN VFNRaWN2aklnJmFtcDtyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcmYW1wO209c2xLSUJZMzd5OHA0 aUMzSmdqdXdEMVRJOU9nVzdRVEhXem1KVnlxeUpOZyZhbXA7cz1XVFR1RG15MzlpMnpJM2ljTUhv ODJjcVJHYVhqekh5d0lnQkFJSzFvcUNVJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mcXVvdDtodHRwczovL3d3dy5leGFtcGxlLm9yZy9jZXJ0LmNlciZxdW90Ozwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPjxicj4NCjx0dD59PC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJy Pg0KPHR0PiZuYnNwOyZuYnNwOyBUaGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIHdpbGwgcHJvdmlk ZSBhbiBhc3NlcnRpb24gb2YgYXV0aG9yaXphdGlvbiwmcXVvdDthdXRoJnF1b3Q7LDwvdHQ+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cD4mcXVvdDsuLi5hdXRob3JpemF0aW9uLCAmcXVvdDthdXRoJnF1b3Q7LCAuLi4mcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwPihzcGFjZSBiZXR3ZWVuIGNvbW1hIGFuZCBvcGVuaW5nIHF1 b3RhdGlvbiBtYXJrKTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mbmJzcDsmbmJzcDsgZm9yIGluZm9ybWF0aW9uIGluIHRoZSBTSVAgJnF1b3Q7UmVzb3VyY2Ut UHJpb3JpdHkmcXVvdDsgaGVhZGVyIGZpZWxkIChpLmUuLDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFJlc291cmNlLVByaW9yaXR5OiBuYW1lc3BhY2UgJnF1b3Q7 LiZxdW90OyByLXByaW9yaXR5KSBiYXNlZCBvbiBbUkZDNDQxMl0uPC90dD48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlRo ZSB1c2Ugb2YgdGhlIHN0cmluZyAnbmFtZXNwYWNlICZxdW90Oy4mcXVvdDsgci1wcmlvcml0eScg aGVyZSBhbmQgZWxzZXdoZXJlIGluIHRoZSBkb2N1bWVudCBoYXMgYSBkZXRyaW1lbnRhbCBpbXBh Y3Qgb24gcmVhZGFiaWxpdHkuIEkgc3Ryb25nbHkgc3VnZ2VzdCByZXBsYWNpbmcgaXQgd2l0aCAm cXVvdDtyLXZhbHVlJnF1b3Q7ICh0aGUgbmFtZSBvZiB0aGlzIHByb2R1Y3Rpb24gaW4gUkZDNDQx MikgZXZlcnl3aGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jm5ic3A7Jm5ic3A7IFNwZWNpZmljYWxseSwgdGhlICZxdW90O3JwaCZxdW90OyBjbGFpbSBp bmNsdWRlcyBhc3NlcnRpb24gb2YgdGhlIHByaW9yaXR5LTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGxldmVsIG9mIHRoZSB1c2VyIHRvIGJlIHVzZWQgZm9yIGEg Z2l2ZW4gY29tbXVuaWNhdGlvbiBzZXNzaW9uLiZuYnNwOyBUaGU8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgdmFsdWUgb2YgdGhlICZxdW90O3JwaCZxdW90OyBjbGFpbSBpcyBhbiBhcnJheSBj b250YWluaW5nIG9uZSBvciBtb3JlIG9mIEpTT048L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsg b2JqZWN0cyBmb3IgdGhlIGNvbnRlbnQgb2YgdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3JpdHknIGhl YWRlciB0aGF0IGlzPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGJlaW5nIGFzc2VydGVkIG9m IHdoaWNoIG9uZSBvZiB0aGUgJnF1b3Q7cnBoJnF1b3Q7IG9iamVjdCwgaXMgbWFuZGF0b3J5Ljwv dHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cD5UaGlzIGxhc3Qgc2VudGVuY2UgaXMgdmVyeSBoYXJkIHRvIHBhcnNlOyBh bmQgKGJhc2VkIG9uIHRoZSBleGFtcGxlKSB0aGUgdmFsdWUgaXMgaW50ZW5kZWQgdG8gYmUgYSBK U09OIE9iamVjdCAoY3VybHkgYnJhY2VzKSByYXRoZXIgdGhhbiBhIEpTT04gQXJyYXkgKHNxdWFy ZSBicmFjZXMpLiBJIHN1Z2dlc3Q6ICdUaGUgdmFsdWUgb2YgdGhlICZxdW90O3JwaCZxdW90OyBj bGFpbSBpcyBhbiBPYmplY3Qgd2l0aCBvbmUgb3IgbW9yZSBrZXlzLiBFYWNoIGtleQ0KIGlzIGFz c29jaWF0ZWQgd2l0aCBhIEpTT04gQXJyYXkuIFRoZXNlIGFycmF5cyBjb250YWluIFN0cmluZ3Mg dGhhdCBjb3JyZXNwb25kIHRvIHRoZSByLXZhbHVlcyBpbmRpY2F0ZWQgaW4gdGhlIFNJUCAmcXVv dDtSZXNvdXJjZS1Qcmlvcml0eSZxdW90OyBoZWFkZXIgZmllbGQuJyAobm90ZTogJnF1b3Q7aGVh ZGVyIGZpZWxkJnF1b3Q7LCBub3QgJnF1b3Q7aGVhZGVyJnF1b3Q7KTxvOnA+PC9vOnA+PC9wPg0K PHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIGZvbGxvd2luZyBpcyBhbiBleGFtcGxlICZx dW90O3JwaCZxdW90OyBjbGFpbSBmb3IgYSBTSVAgJnF1b3Q7UmVzb3VyY2UtUHJpb3JpdHkmcXVv dDs8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgaGVhZGVyIGZpZWxkIHdpdGggYSAmcXVvdDtu YW1lc3BhY2UgJnF1b3Q7LiZxdW90OyByLXByaW9yaXR5JnF1b3Q7IHZhbHVlIG9mICZxdW90O2V0 cy4wJnF1b3Q7IGFuZDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB3aXRoIGEgJnF1b3Q7bmFt ZXNwYWNlICZxdW90Oy4mcXVvdDsgci1wcmlvcml0eSZxdW90OyB2YWx1ZSBvZiAmcXVvdDt3cHMu MCZxdW90Oy48L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgeyAmcXVvdDtv cmlnJnF1b3Q7OnsmcXVvdDt0biZxdW90OzomcXVvdDs8L3R0Pjwvc3Bhbj48YSBocmVmPSJ0ZWw6 KDIxNSklMjA1NTUtMTIxMiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4xMjE1NTU1MTIxMjwv c3Bhbj48L2E+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mcXVvdDt9PC9zcGFu PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7 ZGVzdCZxdW90Ozp7WyZxdW90O3RuJnF1b3Q7OiZxdW90OzwvdHQ+PC9zcGFuPjxhIGhyZWY9InRl bDooMjEyKSUyMDU1NS0xMjEzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEyMTI1NTUxMjEz PC9zcGFuPjwvYT48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZxdW90O119LDwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZx dW90O2lhdCZxdW90OzoxNDQzMjA4MzQ1LDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtycGgmcXVvdDs6eyZxdW90O2F1dGgmcXVvdDs6WyZxdW90O2V0cy4wJnF1 b3Q7LCZxdW90O3dwcy4wJnF1b3Q7XX08L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+QXMgYWJvdmUsIEkgcmVjb21t ZW5kIHByZXR0eS1wcmludGluZyB0aGlzLiBJdCdzIGFsc28gbWlzc2luZyBhIGNvbW1hIGFmdGVy IHRoZSAmcXVvdDtvcmlnJnF1b3Q7IHZhbHVlLCBhbmQgdGhlIHRvcC1sZXZlbCBzdHJ1Y3R1cmUg aXMgbWlzc2luZyBhIGNsb3NpbmcgYnJhY2UuIFRoZSB2YWx1ZSBmb3IgJnF1b3Q7aWF0JnF1b3Q7 IG5lZWRzIHRvIGJlIGVuY2xvc2VkIGluIHF1b3Rlcy48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBO QU5QQSBoYXMgYWxsb2NhdGVkIE5QQTU1NTAxeHggZm9yIGV4YW1wbGUgdXNlLCBub3QgTlBBNTU1 eHh4eCwgbXVjaCBvZiB3aGljaCByZW1haW5zIGFzc2lnbmFibGUgKGNmDQo8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5uYXRp b25hbG5hbnBhLmNvbV9wZGZfTlJVRl9BVElTLTJEMDMwMDExNS5wZGYmYW1wO2Q9RHdNRmFRJmFt cDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZh bXA7bT1zbEtJQlkzN3k4cDRpQzNKZ2p1d0QxVEk5T2dXN1FUSFd6bUpWeXF5Sk5nJmFtcDtzPWo1 cUJqc3dTUUEweXNvT19wTEtUVWRDa0tQTGJ3UjZRLWdnOEFiYUJjRk0mYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+DQombHQ7aHR0cHM6Ly93d3cubmF0aW9uYWxuYW5wYS5jb20vcGRmL05SVUYvQVRJ Uy0wMzAwMTE1LnBkZiZndDs8L2E+KS48bzpwPjwvbzpwPjwvcD4NCjxwPlB1dHRpbmcgYWxsIHRo aXMgdG9nZXRoZXIsIEkgYmVsaWV2ZSB3aGF0IHlvdSB3YW50IGlzOjxvOnA+PC9vOnA+PC9wPg0K PHA+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij57PC9zcGFuPjwvdHQ+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjx0dD4mbmJzcDsgJnF1b3Q7b3JpZyZxdW90Ozp7JnF1b3Q7dG4mcXVvdDs6JnF1 b3Q7PC90dD48L3NwYW4+PGEgaHJlZj0idGVsOigyMTUpJTIwNTU1LTAxMTIiIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+MTIxNTU1NTAxMTI8L3NwYW4+PC9hPjx0dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+JnF1b3Q7fSw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZu YnNwOyAmcXVvdDtkZXN0JnF1b3Q7OntbJnF1b3Q7dG4mcXVvdDs6JnF1b3Q7PC90dD48L3NwYW4+ PGEgaHJlZj0idGVsOigyMTIpJTIwNTU1LTAxMTMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ MTIxMjU1NTAxMTM8L3NwYW4+PC9hPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ JnF1b3Q7XX0sPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsgJnF1b3Q7aWF0 JnF1b3Q7OiZxdW90OzE0NDMyMDgzNDUmcXVvdDssPC90dD48YnI+DQo8dHQ+Jm5ic3A7ICZxdW90 O3JwaCZxdW90Ozp7JnF1b3Q7YXV0aCZxdW90OzpbJnF1b3Q7ZXRzLjAmcXVvdDssJnF1b3Q7d3Bz LjAmcXVvdDtdfTwvdHQ+PGJyPg0KPHR0Pn08L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IEFmdGVyIHRoZSBoZWFkZXIgYW5kIGNsYWltcyBQQVNT cG9yVCBvYmplY3RzIGhhdmUgYmVlbiBjb25zdHJ1Y3RlZCw8L3R0Pjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgdGhlaXIgc2lnbmF0dXJlIGlzIGdlbmVyYXRlZCBub3JtYWxseSBwZXIgdGhlIGd1aWRh bmNlIGluPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFtJLUQuaWV0Zi1zdGlyLXBhc3Nwb3J0 XSB1c2luZyB0aGUgZnVsbCBmb3JtIG9mIFBBU1NQb3JULiZuYnNwOyBUaGU8L3R0Pjxicj4NCjx0 dD4mbmJzcDsmbmJzcDsgY3JlZGVudGlhbHMgKGUuZy4sIGF1dGhvcml0eSByZXNwb25zaWJsZSBm b3IgYXV0aG9yaXppbmcgUmVzb3VyY2UtPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFByaW9y aXR5KSB1c2VkIHRvIGNyZWF0ZSB0aGUgc2lnbmF0dXJlIG11c3QgaGF2ZSBhdXRob3JpdHkgb3Zl ciB0aGU8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIGFu ZCB0aGVyZSBpcyBvbmx5IG9uZSBhdXRob3JpdHkgcGVyIGNsYWltLiZuYnNwOyBUaGUgYXV0aG9y aXR5PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IE1VU1QgdXNlIGl0cyBjcmVkZW50aWFscyAo aS5lLiwgQ0VSVCkgYXNzb2NpYXRlZCB3aXRoIHRoZSBzcGVjaWZpYzwvdHQ+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyBzZXJ2aWNlIHN1cHBvcnRlZCBieSB0aGUgU0lQIG5hbWVzcGFjZSBpbiB0aGUg Y2xhaW0uPC90dD48YnI+DQo8YnI+DQo8dHQ+NC4mbmJzcDsgJ3JwaCcgaW4gU0lQPC90dD48YnI+ DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoaXMgc2VjdGlvbiBzcGVjaWZpZXMgU0lQLXNwZWNp ZmljIHVzYWdlIGZvciB0aGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIGluPC90dD48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IFBBU1Nwb3JULjwvdHQ+PGJyPg0KPGJyPg0KPHR0PjQuMS4mbmJzcDsgQXV0 aGVudGljYXRpb24gU2VydmljZSBCZWhhdmlvcjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBUaGUgQXV0aGVudGljYXRpb24gU2VydmljZSB3aWxsIGNyZWF0ZSB0aGUgJnF1b3Q7cnBo JnF1b3Q7IGNsYWltIHVzaW5nIHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB2YWx1ZXMg ZGlzY3Vzc2VkIGluIHNlY3Rpb24gMyBiYXNlZCBvbiBbUkZDNDQxMl0uJm5ic3A7IFRoZSBjb25z dHJ1Y3Rpb248L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgb2YgJnF1b3Q7cnBoJnF1b3Q7IGNs YWltIGZvbGxvd3MgdGhlIHN0ZXBzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQgb2Y8L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgW0ktRC5pZXRmLXN0aXItcmZjNDQ3NGJpc10uPC90dD48YnI+DQo8 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSByZXN1bHRpbmcgSWRlbnRpdHkgaGVhZGVyIGZvciAm cXVvdDtycGgmcXVvdDsgbWlnaHQgbG9vayBhcyBmb2xsb3dzOjwvdHQ+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mcXVv dDsuLi5oZWFkZXIgZmllbGQuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7ICZxdW90O2V5SmhiR2NpT2lKRlV6STFOaUlzSW5SNWNDSTZJa3BYVkNKOS5l eUpwYzNNaU9pSmxlVW93WlZoQmFVOXBTbmQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgWldF NTZZMGM1ZVdSRFNYTkVVVzlwWTBoQ01FbHFiMmxqYmtKdlNXbDNUa05wU21oaVIyTnBUMmxLUmxW NlNURk88L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYVVselJGRnZhV1ZFVmpGSmFuQnZaRWhT ZDJONmIzWk1NMlF6WkhrMWJHVkhSblJqUjNoc1RHMU9kbUpUT1dwYVc8L3R0Pjxicj4NCjx0dD4m bmJzcDsmbmJzcDsgRW93VEcxT2JHTnVNRTVEWnpCTElIeDg0b0NaTHVLQW1YeDhJR1Y1UVdsaU0w cHdXbmxKTm1WNVNqQmlhVWsyU1c8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgcEZlVTFVVlRG T1ZGVjRUV3BGZVVsdU1FNURhVXByV2xoT01FbHFjRGRYZVVvd1ltbEpOa2xxUlhsTlZFa3hUbFI8 L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVmVFMXFSWHBKYkRFNVRFRXdTMGx0Ykdoa1EwazJU VlJSTUUxNlNYZFBSRTB3VGxOM1RrTnBTbmxqUjJkcFQyNXo8L3R0Pjxicj4NCjx0dD4mbmJzcDsm bmJzcDsgYVZsWVZqQmhRMGsyVjNsS2JHUklUWFZOUTBselNXNWtkMk41TkhkSmJERTVSRkZ2UFNK OS5zMzdTNlZDOEhNNkQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgbDZZekplUURzclpjd0ow bGl6eGhVckE3Zl85OG9XQkh2by1jbC1uOE1JaG9DcjE4dllZRnkzYmxYdnMzZnNsTV88L3R0Pjxi cj4NCjx0dD4mbmJzcDsmbmJzcDsgb29zMlAyRHl3JnF1b3Q7OyBpbmZvPSA8L3R0Pjwvc3Bhbj48 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5leGFtcGxlLm9yZ19jZXJ0LmNlciZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9I VU1lTVRTUWljdmpJZyZhbXA7cj1HOXY4dUNTU1FoQ21wdzdJdEcwcjJnJmFtcDttPXNsS0lCWTM3 eThwNGlDM0pnanV3RDFUSTlPZ1c3UVRIV3ptSlZ5cXlKTmcmYW1wO3M9V1RUdURteTM5aTJ6STNp Y01IbzgyY3FSR2FYanpIeXdJZ0JBSUsxb3FDVSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+JnF1b3Q7aHR0cHM6Ly93d3cuZXhhbXBsZS5vcmcvY2VydC5jZXImcXVvdDs8L3NwYW4+ PC9hPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+O2FsZz1FUzI1Njs8L3NwYW4+ PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBwcHQ9JnF1b3Q7cnBoJnF1b3Q7 PC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwPlRoaXMgZXhhbXBsZSBoYXMgYSBudW1iZXIgb2YgaXNzdWVzOjxvOnA+ PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPg0KSW4gdGhlIElkZW50aXR5IGhl YWRlciBmaWVsZCwgdGhlIHNpZ25lZC1pZGVudGl0eS1kaWdlc3Qgc2hvdWxkbid0IGJlIHF1b3Rl ZC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPg0KSW4gdGhlIElkZW50aXR5IGhlYWRlciBmaWVsZCwg aW5mbyBpcyBlbmNsb3NlZCBpbiAmbHQ7Jmd0OyByYXRoZXIgdGhhbiAmcXVvdDsmcXVvdDsuPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwzIGxldmVsMSBsZm82Ij4NCkluIHRoZSBJZGVudGl0eSBoZWFkZXIgZmllbGQsIHBwdCBp cyBhIHRva2VuIHJhdGhlciB0aGFuIGEgcXVvdGVkIHN0cmluZy48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxm bzYiPg0KVGhlIHNpZ25lZC1pZGVudGl0eS1kaWdlc3QgaGVhZGVyIG5lZWRzIHRvIGluZGljYXRl IGEgJnF1b3Q7dHlwJnF1b3Q7IG9mICZxdW90O3Bhc3Nwb3J0JnF1b3Q7IHJhdGhlciB0aGFuIEpX VCwgYW5kIGl0IG5lZWRzIHRvIGluY2x1ZGUgYm90aCBhICZxdW90O3BwdCZxdW90OyBhbmQgJnF1 b3Q7eDV1JnF1b3Q7IGZpZWxkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNiI+DQpUaGUgc2lnbmVkLWlk ZW50aXR5LWRpZ2VzdCBib2R5IHNob3VsZCBjb250YWluIG9ubHkgdGhlIHBhc3Nwb3J0IGNsYWlt IHJhdGhlciB0aGFuIGEgSlNPTiBvYmplY3QgdGhhdCBpdHNlbGYgY29udGFpbnMgYSBiYXNlNjQt ZW5jb2RlZCBKV1MgaGVhZGVyIGNvbmNhdGVuYXRlZCB3aXRoIGEgY2xhaW0uPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxl dmVsMSBsZm82Ij4NCkkgYmVsaWV2ZSB0aGF0LCBldmVuIHdoZW4gdGhlIGJvZHkgaXMgaW5jbHVk ZWQsIHZhbHVlcyBpbiB0aGUgaGVhZGVyIGFuZCBib2R5IG5lZWQgdG8gYmUgYmUgY2Fub25pY2Fs aXplZCAoaS5lLiwgYWxsIG9uIG9uZSBsaW5lLCBubyBzcGFjZXMsIGluIGFscGhhYmV0aWNhbCBv cmRlciwgZXRjLik8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPkkgd291bGQgYWxzbyByZWNvbW1l bmQgZm9sbG93aW5nIHRoZSBjb252ZW50aW9uIG9mIGluZGljYXRpbmcgdGhhdCBsaW5lLXdyYXBz IGFyZSBvbmx5IGZvciByZWFkYWJpbGl0eSwgYW5kIGluY2x1ZGluZyB0aGUgaGVhZGVyIGZpZWxk IG5hbWUgaW4gdGhlIGV4YW1wbGUuIFB1dHRpbmcgYWxsIHRoaXMgdG9nZXRoZXIsIEkgYmVsaWV2 ZSB3aGF0IHlvdSB3YW50IGlzOjxvOnA+PC9vOnA+PC9wPg0KPHA+PHR0PjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgRm9yIGV4YW1wbGUsIGEgSWRlbnRpdHkgaGVh ZGVyIGZpZWxkIGZvciAmcXVvdDtycGgmcXVvdDsgbWlnaHQgbG9vazwvc3Bhbj48L3R0PjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGFzIGZvbGxvd3MgKGJhY2tzbGFzaGVzIHNob3du IGZvciBsaW5lIGZvbGRpbmcgb25seSk6PC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBJZGVudGl0eTog ZXlKaGJHY2lPaUpGVXpJMU5pSXNJbkJ3ZENJNkluSndhQ0lzSW5SNWNDSTZJbkJoYzNOd2IzSjBJ IFw8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpd2llRFYxSWpv aWFIUjBjSE02THk5M2QzY3VaWGhoYlhCc1pTNWpiMjB2WTJWeWRDNWpaWElpZlFvLmV5SmtaWE4w IFw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgSWpwN1d5SjBiaUk2SWpFeU1USTFOVFV3TVRF eklsMTlMQ0pwWVhRaU9pSXhORFF6TWpBNE16UTFJaXdpYjNKcFp5SSBcPC90dD48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IDZleUowYmlJNklqRXlNVFUxTlRVd01URXlJbjBzSW5Kd2FDSTZleUpoZFhS b0lqcGJJbVYwY3k0d0lpd2lkM0J6TGogXDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBBaVhY MTlDZy5zMzdTNlZDOEhNNkRsNll6SmVRRHNyWmN3SjBsaXp4aFVyQTdmXzk4b1dCSHZvLWNsLW44 TUlob0NyIFw8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgMTh2WVlGeTNibFh2czNmc2xNX29v czJQMkR5dztpbmZvPSZsdDs8L3R0Pjwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5leGFtcGxlLm9yZ19jZXJ0LmNl ciZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1HOXY4dUNT U1FoQ21wdzdJdEcwcjJnJmFtcDttPXNsS0lCWTM3eThwNGlDM0pnanV3RDFUSTlPZ1c3UVRIV3pt SlZ5cXlKTmcmYW1wO3M9V1RUdURteTM5aTJ6STNpY01IbzgyY3FSR2FYanpIeXdJZ0JBSUsxb3FD VSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+aHR0cHM6Ly93d3cuZXhhbXBsZS5v cmcvY2VydC5jZXI8L3NwYW4+PC9hPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ DQogXDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7ICZndDs7YWxn PUVTMjU2O3BwdD1ycGg8L3R0Pjxicj4NCjwvc3Bhbj48YnI+DQooTm90ZTogdGhpcyBleGFtcGxl IGFzc3VtZXMgdGhlIGNhbGxpbmcgYW5kIGNhbGxlZCBwYXJ0eSBudW1iZXJzIGluIHRoZSBwcmV2 aW91cyBleGFtcGxlIGFyZSBjaGFuZ2VkIHRvDQo8YSBocmVmPSJ0ZWw6KDIxNSklMjA1NTUtMDEx MiIgdGFyZ2V0PSJfYmxhbmsiPjEyMTU1NTUwMTEyPC9hPiBhbmQgPGEgaHJlZj0idGVsOigyMTUp JTIwNTU1LTAxMTMiIHRhcmdldD0iX2JsYW5rIj4NCjEyMTU1NTUwMTEzPC9hPiwgcmVzcGVjdGl2 ZWx5KTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgQSBTSVAgYXV0 aGVudGljYXRpb24gc2VydmljZSB0eXBpY2FsbHkgd2lsbCBkZXJpdmUgdGhlIHZhbHVlIG9mICZx dW90O3JwaCZxdW90OzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBmcm9tIHRoZSAnUmVzb3Vy Y2UtUHJpb3JpdHknIGhlYWRlciBmaWVsZCBiYXNlZCBvbiBwb2xpY3kgYXNzb2NpYXRlZDwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB3aXRoIHNlcnZpY2Ugc3BlY2lmaWMgdXNlIG9mIHRoZSAm cXVvdDtuYW1lc3BhY2UgJnF1b3Q7LiZxdW90OyByLXByaW9yaXR5JnF1b3Q7IHZhbHVlczwvdHQ+ PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBiYXNlZCBvbiBbUkZDNDQxMl0uJm5ic3A7IFRoZSBhdXRo ZW50aWNhdGlvbiBzZXJ2aWNlIGRlcml2ZXMgdGhlIHZhbHVlIG9mPC90dD48YnI+DQo8dHQ+Jm5i c3A7Jm5ic3A7IHRoZSBQQVNTUG9yVCBjbGFpbSBieSB2ZXJpZnlpbmcgdGhlIGF1dGhvcml6YXRp b24gZm9yIFJlc291cmNlLTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBQcmlvcml0eSAoaS5l LiwgdmVyaWZ5aW5nIGEgY2FsbGluZyB1c2VyIHByaXZpbGVnZSBmb3IgUmVzb3VyY2UtPC90dD48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFByaW9yaXR5IGJhc2VkIG9uIGl0cyBpZGVudGl0eSkgd2hp Y2ggbWlnaHQgYmUgZGVyaXZlZCBmcm9tIGN1c3RvbWVyPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IHByb2ZpbGUgZGF0YSBvciBmcm9tIGFjY2VzcyB0byBleHRlcm5hbCBzZXJ2aWNlcy48L3R0 Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgW1JGQzQ0MTJdIGFsbG93cyBtdWx0aXBsZSAm cXVvdDtuYW1lc3BhY2UgJnF1b3Q7LiZxdW90OyByLXByaW9yaXR5JnF1b3Q7IHBhaXJzLCBlaXRo ZXIgaW48L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYSBzaW5nbGUgU0lQIFJlc291cmNlLVBy aW9yaXR5IGhlYWRlciBvciBhY3Jvc3MgbXVsdGlwbGUgU0lQPC90dD48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmds ZSBxdW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScuPG86cD48L286cD48L3A+DQo8cD4m cXVvdDsuLi5oZWFkZXIgZmllbGQuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFJlc291cmNlLVByaW9yaXR5IGhlYWRlcnMu Jm5ic3A7IEhvd2V2ZXIsIGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gc2lnbiBhbGw8L3NwYW4+PC90 dD48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHA+U2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpw PjwvcD4NCjxwPiZxdW90Oy4uLmhlYWRlciBmaWVsZHMuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IGNvbnRlbnQgb2YgYSBT SVAgUmVzb3VyY2UtUHJpb3JpdHkgaGVhZGVyIG9yIGFsbCBTSVAgUmVzb3VyY2UtPC9zcGFuPjwv dHQ+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwPlNpbmdsZSBxdW90ZXMgYXJvdW5kICdSZXNvdXJjZS1Qcmlvcml0eScuPG86cD48L286 cD48L3A+DQo8cD4mcXVvdDsuLi5oZWFkZXIgZmllbGQuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFByaW9yaXR5IGhlYWRl cnMgaW4gYSBnaXZlbiBTSVAgbWVzc2FnZS4mbmJzcDsgQW4gYXV0aG9yaXR5IGlzIG9ubHk8L3Nw YW4+PC90dD48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHA+U2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpw PjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4uLmhlYWRlciBmaWVsZHMuLi4mcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IHJlc3BvbnNp YmxlIGZvciBzaWduaW5nIHRoZSBjb250ZW50IG9mIGEgU0lQIFJlc291cmNlLVByaW9yaXR5IGhl YWRlcjwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cD5TaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJpb3Jp dHknLjxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1b3Q7Li4uaGVhZGVyIGZpZWxkLi4uJnF1b3Q7PG86 cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBm b3Igd2hpY2ggaXQgaGFzIGF1dGhvcml0eSAoZS5nLiwgYSBzcGVjaWZpYyAmcXVvdDtuYW1lc3Bh Y2UgJnF1b3Q7LiZxdW90Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IHItcHJpb3JpdHkmcXVvdDspLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PjQuMi4mbmJzcDsgVmVy aWZpY2F0aW9uIFNlcnZpY2UgQmVoYXZpb3I8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJz cDsgW0ktRC5pZXRmLXN0aXItcmZjNDQ3NGJpc10gU2VjdGlvbiA2LjIgU3RlcCA1IHJlcXVpcmVz IHRoYXQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbnMgZGVmaW5pbmcg JnF1b3Q7cHB0JnF1b3Q7IHZhbHVlcyBkZXNjcmliZSBhbnkgYWRkaXRpb25hbCB2ZXJpZmllcjwv dHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBiZWhhdmlvci4mbmJzcDsgVGhlIGJlaGF2aW9yIHNw ZWNpZmllZCBmb3IgdGhlICZxdW90O3BwdCZxdW90OyB2YWx1ZXMgb2YgJnF1b3Q7cnBoJnF1b3Q7 IGlzIGFzPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGZvbGxvd3M6PC90dD48YnI+DQo8YnI+ DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSB2ZXJpZmljYXRpb24gc2VydmljZSBNVVNUIGV4dHJhY3Qg dGhlIHZhbHVlIGFzc29jaWF0ZWQgd2l0aCB0aGU8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsg JnF1b3Q7YXV0aCZxdW90OyBrZXkgaW4gYSBmdWxsIGZvcm0gUEFTU1BvclQgd2l0aCBhICZxdW90 O3BwdCZxdW90OyB2YWx1ZSBvZiAmcXVvdDtycGgmcXVvdDsuJm5ic3A7IElmPC90dD48YnI+DQo8 dHQ+Jm5ic3A7Jm5ic3A7IHRoZSBzaWduYXR1cmUgdmFsaWRhdGVzLCB0aGVuIHRoZSB2ZXJpZmlj YXRpb24gc2VydmljZSBjYW4gdXNlIHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB2YWx1 ZSBvZiB0aGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIGFzIHZhbGlkYXRpb24gdGhhdCB0aGUgY2Fs bGluZyBwYXJ0eSBpczwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBhdXRob3JpemVkIGZvciBS ZXNvdXJjZS1Qcmlvcml0eSwgd2hpY2ggd291bGQgaW4gdHVybiBiZSB1c2VkIGZvcjwvdHQ+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmdsZSBxdW90ZXMgYXJvdW5kICdSZXNvdXJj ZS1Qcmlvcml0eScuPG86cD48L286cD48L3A+DQo8cD5UaGlzIHRleHQgaXMgYW1iaWd1b3VzIGFi b3V0IHdoZXRoZXIgdGhlIHZhbGlkYXRpb24gaW5kaWNhdGVzIHRoYXQgdGhlIGNhbGxpbmcgcGFy dHkgaXMgYXV0aG9yaXplZCB0byB1c2UgdGhlIHByaW9yaXRpZXMgaW5kaWNhdGVkIGluIHRoZSBw YXNzcG9ydCBvYmplY3QsIG9yIHRoZSB2YWx1ZXMgaW4gdGhlIFNJUCAnUmVzb3VyY2UtUHJpb3Jp dHknIGhlYWRlciBmaWVsZDsgYW5kICh0YWtlbiBvbiBpdHMgZmFjZSkgaW1wbGllcyB0aGUgbGF0 dGVyLA0KIHdoZW4gdGhlIGludGVudGlvbiBoZXJlIHNob3VsZCBjbGVhcmx5IGJlIHRoZSBmb3Jt ZXIuPG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5hdXRob3JpemVkIGZvciAnUmVzb3VyY2Ut UHJpb3JpdHknIGluZGljYXRlZCBpbiB0aGUgY2xhaW0uIFRoaXMgdmFsdWUgd291bGQgaW4gdHVy biBiZSB1c2VkIGZvci4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIHRleHQgYWxzbyBu ZWVkcyB0byBzYXkgc29tZXRoaW5nIGFib3V0IGNvbXBhcmluZyB2YWx1ZXMgaW4gdGhlIGNsYWlt IHRvIHZhbHVlcyBpbiB0aGUgJ1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZmllbGQsIGFuZCB3 aGF0IGEgbWlzbWF0Y2ggbWlnaHQgbWVhbi4gVGhlIGRvY3VtZW50IHNheXMgZWxzZXdoZXJlIHRo YXQgdGhlIHNpZ25hdHVyZSBtaWdodCBvbmx5IGNvdmVyIHNvbWUgb2YgdGhlIHItdmFsdWVzLCB3 aGljaCBtYWtlcw0KIGl0IGVudGlyZWx5IHBvc3NpYmxlIHRoYXQgdGhlICdSZXNvdXJjZS1Qcmlv cml0eScgZmllbGQgbWlnaHQgY29udGFpbiBtb3JlIHZhbHVlcyB0aGFuIGFyZSBzaWduZWQuIE9u IHRoZSBvdGhlciBoYW5kLCBpbnRlcm1lZGlhcmllcyBtaWdodCByZWFzb25hYmx5IHJlbW92ZSBy LXZhbHVlcyBhcyB0aGUgY2FsbCBpcyBwcm9jZXNzZWQuIFRoaXMgcHJvYmFibHkgbWVhbnMgdGhh dCB0aG9zZSByZW1vdmVkIHByaW9yaXRpZXMgc2hvdWxkIG5vdCBiZQ0KIHVzZWQsIGV2ZW4gaWYg dGhleSBhcmUgcHJlc2VudCBpbiB0aGUgcGFzc3BvcnQuIEl0IHNlZW1zIHJlYXNvbmFibGUgdG8g c2F5IHRoYXQgKnR5cGljYWwqIHByb2Nlc3NpbmcgYnkgYSByZWNlaXZpbmcgcGFydHkgd291bGQg YmUgdG8gdGFrZSB0aGUgKnVuaW9uKiBvZiBhbGwgUlBIIHBhc3Nwb3J0cyB0aGF0IHRoZXkgdHJ1 c3QsIGFuZCAqaW50ZXJzZWN0KiB0aGF0IHdpdGggdGhlIHByaW9yaXRpZXMgaW4gJ1Jlc291cmNl LVByaW9yaXR5JyBoZWFkZXINCiBmaWVsZHMgdG8gZ2V0IHRoZSBhY3R1YWwgcHJpb3JpdHkgb3Ig cHJpb3JpdGllcyB0byBiZSBhcHBsaWVkIHRvIHRoZSBjYWxsIChzdWJqZWN0IHRvIGxvY2FsIHBv bGljeSkuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNw OyZuYnNwOyBwcmlvcml0eSB0cmVhdG1lbnQgaW4gYWNjb3JkYW5jZSB3aXRoIGxvY2FsIHBvbGlj eSBmb3IgdGhlIGFzc29jaWF0ZWQ8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNw OyZuYnNwOyBjb21tdW5pY2F0aW9uIHNlcnZpY2UuPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IEluIGFkZGl0aW9uLCBbSS1ELmlldGYtc3Rpci1yZmM0NDc0YmlzXSBTZWN0aW9uIDYu MiBTdGVwIDQgcmVxdWlyZXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgJnF1b3Q7aWF0JnF1 b3Q7IHZhbHVlIGluICZxdW90O3JwaCZxdW90OyBjbGFpbSB0byBiZSB2ZXJpZmllZC48L3R0Pjxi cj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlIGJlaGF2aW9yIG9mIGEgU0lQIFVBcyB1cG9u IHJlY2VpdmluZyBhbiBJTlZJVEUgY29udGFpbmluZyBhPC90dD48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZxdW90Oy4u Lm9mIGEgU0lQIFVBIHVwb24uLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPm9yPG86cD48L286 cD48L3A+DQo8cD4mcXVvdDsuLi5vZiBTSVAgVUFzIHVwb24uLi4mcXVvdDs8bzpwPjwvbzpwPjwv cD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0 dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFBBU1Nwb3JUIG9i amVjdCB3aXRoIGEgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIHdpbGwgbGFyZ2VseSByZW1haW4gYSBt YXR0ZXIgb2Y8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpbXBs ZW1lbnRhdGlvbiBwb2xpY3kgZm9yIHRoZSBzcGVjaWZpYyBjb21tdW5pY2F0aW9uIHNlcnZpY2Uu Jm5ic3A7IEluPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IG1vc3QgY2FzZXMsaW1wbGVtZW50 YXRpb25zIHdvdWxkIGFjdCBiYXNlZCBvbiBjb25maWRlbmNlIGluIHRoZTwvdHQ+PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cD4mcXVvdDsuLi5jYXNlcywgaW1wbGVtZW50YXRpb25zLi4uJnF1b3Q7PG86cD48L286cD48L3A+ DQo8cD4oc3BhY2UgYWZ0ZXIgY29tbWEpPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyB2ZXJhY2l0eSBvZiB0aGlzIGluZm9ybWF0aW9uLiZu YnNwOyBUaGUgdXNlIG9mIHRoZSBjb21wYWN0IGZvcm0gb2Y8L3NwYW4+PC90dD48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+UGFyYWdy YXBoIGJyZWFrIGJlZm9yZSAmcXVvdDtUaGUmcXVvdDsuPG86cD48L286cD48L3A+DQo8cD4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48dHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBQQVNTcG9yVCBpcyBub3Qgc3BlY2lm aWVkIGluIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjxicj4NCjx0 dD41LiZuYnNwOyBGdXJ0aGVyIEluZm9ybWF0aW9uIEFzc29jaWF0ZWQgd2l0aCBSZXNvdXJjZS1Q cmlvcml0eTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD5TaW5nbGUgcXVvdGVzIGFyb3VuZCAnUmVzb3VyY2UtUHJp b3JpdHknLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhlcmUg bWF5IGJlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNhbGxpbmcgcGFydHkgb3Ig dGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNhbGwgdGhhdCBjb3VsZCBiZSByZWxldmFu dCB0byBhdXRob3JpemF0aW9uIGZvciBSZXNvdXJjZS1Qcmlvcml0eS48L3R0Pjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+ U2luZ2xlIHF1b3RlcyBhcm91bmQgJ1Jlc291cmNlLVByaW9yaXR5Jy48bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFRoaXMgbWF5IGluY2x1 ZGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgZGV2aWNlIHN1YnNjcmlwdGlvbiBvZjwvc3Bh bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoZSBjYWxsZXIsIG9yIHRv IGFueSBpbnN0aXR1dGlvbnMgdGhhdCB0aGUgY2FsbGVyIG9yIGRldmljZSBpczwvdHQ+PGJyPg0K PHR0PiZuYnNwOyZuYnNwOyBhc3NvY2lhdGVkIHdpdGgsIG9yIGV2ZW4gY2F0ZWdvcmllcyBvZiBp bnN0aXR1dGlvbnMuJm5ic3A7IEFsbCBvZiB0aGVzZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw OyBkYXRhIGVsZW1lbnRzIHdvdWxkIGJlbmVmaXQgZnJvbSB0aGUgc2VjdXJlIGF0dGVzdGF0aW9u cyBwcm92aWRlZCBieTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB0aGUgU1RJUiBhbmQgUEFT U3BvclQgZnJhbWV3b3Jrcy4mbmJzcDsgVGhlIHNwZWNpZmljYXRpb24gb2YgdGhlICZxdW90O3Jw aCZxdW90OzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBjbGFpbSBjb3VsZCBlbnRhaWwgdGhl IG9wdGlvbmFsIHByZXNlbmNlIG9mIG9uZSBvciBtb3JlIHN1Y2g8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBmaWVsZHMuPC90dD48YnI+DQo8YnI+DQo8 dHQ+Jm5ic3A7Jm5ic3A7IEEgbmV3IElBTkEgcmVnaXN0cnkgaGFzIGJlZW4gZGVmaW5lZCB0byBo b2xkIHBvdGVudGlhbCB2YWx1ZXMgb2YgdGhlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7ICZx dW90O3JwaCZxdW90OyBhcnJheTsgc2VlIFNlY3Rpb24gNi4yLiZuYnNwOyBUaGUgZGVmaW5pdGlv biBvZiB0aGUgJnF1b3Q7cnBoJnF1b3Q7IGNsYWltIG1heTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBoYXZlIG9uZSBvciBtb3JlIHN1Y2ggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBmaWVsZChz KS4mbmJzcDsgRGV0YWlscyBvZjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBzdWNoICZxdW90 O3JwaCZxdW90OyBjbGFpbSB0byBlbmNvbXBhc3Mgb3RoZXIgZGF0YSBlbGVtZW50cyBhcmUgbGVm dCBmb3IgZnV0dXJlPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHZlcnNpb24gb2YgdGhpcyBz cGVjaWZpY2F0aW9uLjwvdHQ+PGJyPg0KPGJyPg0KPHR0PjYuJm5ic3A7IElBTkEgQ29uc2lkZXJh dGlvbnM8L3R0Pjxicj4NCjxicj4NCjx0dD42LjEuJm5ic3A7IEpTT04gV2ViIFRva2VuIENsYWlt cyBSZWdpc3RyYXRpb248L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+SSB0aGluayB0aGVyZSdzIHNvbWUgY29uZnVz aW9uIGhlcmUuIFlvdSdyZSByZWdpc3RlcmluZyBhIFBBU1Nwb3JUIHBwdCB2YWx1ZSwgbm90IGEg bmV3IEpXVCBjbGFpbS4gVGhhdCBpcyB0byBzYXksIHlvdSdyZSBhZGRpbmcgYW4gZW50cnkgdG8g dGhpcyB0YWJsZTo8bzpwPjwvbzpwPjwvcD4NCjxwPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlhbmEub3JnX2Fzc2lnbm1l bnRzX3Bhc3Nwb3J0X3Bhc3Nwb3J0LnhodG1sJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hV TWVNVFNRaWN2aklnJmFtcDtyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcmYW1wO209c2xLSUJZMzd5 OHA0aUMzSmdqdXdEMVRJOU9nVzdRVEhXem1KVnlxeUpOZyZhbXA7cz1YSElzV011eXRBNk1qdTZt aUV6VnBudDBENFp4a0FCVFN2Si1qZmNZdVRVJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Bhc3Nwb3J0L3Bhc3Nwb3J0LnhodG1sPC9hPjxv OnA+PC9vOnA+PC9wPg0KPHA+Tm90IHRvIHRoaXMgdGFibGU6PG86cD48L286cD48L3A+DQo8cD48 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pYW5hLm9yZ19hc3NpZ25tZW50c19qd3Rfand0LnhodG1sJmFtcDtkPUR3TUZhUSZh bXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFtcDtyPUc5djh1Q1NTUWhDbXB3N0l0RzByMmcm YW1wO209c2xLSUJZMzd5OHA0aUMzSmdqdXdEMVRJOU9nVzdRVEhXem1KVnlxeUpOZyZhbXA7cz1B em1qZm81NDZZSFdrOXI0SFFXZEVCNVBqWTlOeEFQOGxsdVdmYTZmX0I0JmFtcDtlPSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2p3dC9qd3QueGh0bWw8 L2E+PG86cD48L286cD48L3A+DQo8cD5Zb3Ugd291bGQgb25seSB1c2UgdGhlIHNlY29uZCB0YWJs ZSBpZiB5b3UgaGFkIGEgbmV3IGtleSB0byBhZGQgdG8gdGhlIFBBU1Nwb3JUIGhlYWRlciAtLSB0 aGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgZG8gdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxwPlRo aXMgc2VjdGlvbiBhbHNvIG5lZWRzIHNvbWUgaW50cm9kdWN0b3J5IHRleHQgdG8gbGV0IHRoZSBJ QU5BIGtub3cgZXhhY3RseSB3aGF0IHRvIGRvOyBlLmcuICZxdW90O1RoaXMgZG9jdW1lbnQgcmVn aXN0ZXJzIGEgbmV3IHZhbHVlIGZvciB0aGUgJnF1b3Q7UGVyc29uYWwgQXNzZXJ0aW9uIFRva2Vu IChQQVNTcG9yVCkgRXh0ZW5zaW9ucyZxdW90OyB0YWJsZS48bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBvJm5i c3A7IHBwdCB2YWx1ZTogJnF1b3Q7cnBoJnF1b3Q7PC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IG8mbmJzcDsgU3BlY2lmaWNhdGlvbiBEb2N1bWVudChzKTogU2VjdGlvbiAzIG9mIFtS RkNUaGlzXTwvdHQ+PGJyPg0KPGJyPg0KPHR0PjYuMi4mbmJzcDsgUEFTU3BvclQgJ3JwaCcgVHlw ZXM8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCByZXF1ZXN0 cyB0aGF0IHRoZSBJQU5BIGFkZCBhIG5ldyBlbnRyeSB0byB0aGUgUEFTU3BvclQ8L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsgVHlwZXMgcmVnaXN0cnkgZm9yIHRoZSB0eXBlICZxdW90O3JwaCZx dW90OyB3aGljaCBpcyBzcGVjaWZpZWQgaW4gW1JGQ1RoaXNdLjwvdHQ+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5UaGVy ZSBpc24ndCBhbiBJQU5BIHRhYmxlIGNhbGxlZCAmcXVvdDtQQVNTcG9yVCBUeXBlcy4mcXVvdDsg SSBwcmVzdW1lIHRoaXMgaXMgdGhlIHJlZ2lzdHJhdGlvbiB3ZSBqdXN0IGRpc2N1c3NlZCBpbiBz ZWN0aW9uIDYuMSwgYW5kIHNvIHRoZSBhYm92ZSB0d28gbGluZXMgY2FuIGJlIHJlbW92ZWQuPG86 cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBU aGlzIHNwZWNpZmljYXRpb24gYWxzbyByZXF1ZXN0cyB0aGF0IHRoZSBJQU5BIGNyZWF0ZSBhIG5l dyByZWdpc3RyeTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGZv ciBQQVNTcG9yVCAmcXVvdDtycGgmcXVvdDsgdHlwZXMuJm5ic3A7IFJlZ2lzdHJhdGlvbiBvZiBu ZXcgUEFTU3BvclQgJnF1b3Q7cnBoJnF1b3Q7IHR5cGVzPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5i c3A7IHNoYWxsIGJlIHVuZGVyIHRoZSBzcGVjaWZpY2F0aW9uIHJlcXVpcmVkIHBvbGljeS4mbmJz cDsgVGhpcyByZWdpc3RyeSBpczwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyB0byBiZSBpbml0 aWFsbHkgcG9wdWxhdGVkIHdpdGggYSBzaW5nbGUgdmFsdWUgZm9yICZxdW90O2F1dGgmcXVvdDsg d2hpY2ggaXM8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgc3BlY2lmaWVkIGluIFtSRkNUaGlz XS48L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBuZWVkcyB0byBiZSB2ZXJ5IGNsZWFyIGFib3V0IHRoZSBm aWVsZHMgdG8gYmUgaW5jbHVkZWQgaW4gdGhpcyBuZXcgcmVnaXN0cnkgKGUuZy4sICZxdW90O1Jl Z2lzdHJ5IGVudHJpZXMgbXVzdCBjb250YWluIHR3byBmaWVsZHM6IHRoZSBuYW1lIG9mIHRoZSAn cnBoJyB0eXBlIGFuZCB0aGUgc3BlY2lmaWNhdGlvbiBpbiB3aGljaCB0aGUgdHlwZSBpcyBkZXNj cmliZWQmcXVvdDspLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD43LiZuYnNwOyBTZWN1 cml0eSBDb25zaWRlcmF0aW9uczwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBUaGUg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFtJLUQuaWV0Zi1zdGlyLXJmYzQ0 NzRiaXNdPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGluIFNlY3Rpb24gMTAgYXJlIGFwcGxp Y2FibGUgaGVyZS48L3R0Pjxicj4NCjxicj4NCjx0dD43LjEuJm5ic3A7IEF2b2lkYW5jZSBvZiBy ZXBsYXkgYW5kIGN1dCBhbmQgcGFzdGUgYXR0YWNrczwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNw OyZuYnNwOyBUaGUgUEFTU3BvclQgZXh0ZW5zaW9uIHdpdGggYSAmcXVvdDtwcHQmcXVvdDsgdmFs dWUgb2YgJnF1b3Q7cnBoJnF1b3Q7IE1VU1Qgb25seSBiZSBzZW50PC90dD48YnI+DQo8dHQ+Jm5i c3A7Jm5ic3A7IHdpdGggU0lQIElOVklURSB3aGVuICdSZXNvdXJjZS1Qcmlvcml0eScgaGVhZGVy IGlzIHVzZWQgdG8gY29udmV5IHRoZTwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5oZWFkZXIgZmll bGQuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jm5ic3A7Jm5ic3A7IHByaW9yaXR5IG9mIHRoZSBjb21tdW5pY2F0aW9uIGFzIGRlZmluZWQgaW4g W1JGQzQ0MTJdLiZuYnNwOyBUbyBhdm9pZCB0aGU8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K PHR0PiZuYnNwOyZuYnNwOyByZXBsYXksIGFuZCBjdXQgYW5kIHBhc3RlIGF0dGFja3MsIHRoZSBw cm9jZWR1cmVzIGRlc2NyaWJlZCBpbjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBTZWN0aW9u IDEwLjEgb2YgW0ktRC5pZXRmLXN0aXItcmZjNDQ3NGJpc10gTVVTVCBiZSBmb2xsb3dlZC48L3R0 Pjxicj4NCjxicj4NCjx0dD43LjIuJm5ic3A7IFNvbHV0aW9uIENvbnNpZGVyYXRpb25zPC90dD48 YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSB1c2Ugb2YgZXh0ZW5zaW9uIHRvIFBBU1Nw b3JUIHRva2VucyB3aXRoICZxdW90O3BwdCZxdW90OyB2YWx1ZSAmcXVvdDtycGgmcXVvdDsgYmFz ZWQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgb24gdGhlIHZhbGlkYXRpb24gb2YgdGhlIGRp Z2l0YWwgc2lnbmF0dXJlIGFuZCB0aGUgYXNzb2NpYXRlZDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBjZXJ0aWZpY2F0ZSByZXF1aXJlcyBjb25zaWRlcmF0aW9uIG9mIHRoZSBhdXRoZW50aWNh dGlvbiBhbmQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgYXV0aG9yaXR5IG9yIHJlcHV0YXRp b24gb2YgdGhlIHNpZ25lciB0byBhdHRlc3QgdG8gdGhlIGlkZW50aXR5IGJlaW5nPC90dD48YnI+ DQo8dHQ+Jm5ic3A7Jm5ic3A7IGFzc2VydGVkLiZuYnNwOyBUaGUgZm9sbG93aW5nIGNvbnNpZGVy YXRpb25zIHNob3VsZCBiZSByZWNvZ25pemVkIHdoZW48L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJz cDsgdXNpbmcgUEFTU3BvclQgZXh0ZW5zaW9uIHdpdGggJnF1b3Q7cHB0JnF1b3Q7IHZhbHVlIG9m ICZxdW90O3JwaCZxdW90Ozo8L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgbyZuYnNw OyBBbiBhdXRob3JpdHkgKHNpZ25lcikgaXMgb25seSBhbGxvd2VkIHRvIHNpZ24gdGhlIGNvbnRl bnQgb2YgYSBTSVA8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg J1Jlc291cmNlLVByaW9yaXR5JyBoZWFkZXIgZm9yIHdoaWNoIGl0IGhhcyB0aGUgcmlnaHQgYXV0 aG9yaXR5LjwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDsuLi5oZWFkZXIgZmllbGQuLi4mcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFRoZSBhdXRob3JpdHkgdGhhdCBzaWducyB0aGUgdG9rZW4gTVVTVCBo YXZlIGEgc2VjdXJlIG1ldGhvZCBmb3I8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0PiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRoZW50aWNhdGlvbiBvZiB0aGUgZW5kIHVz ZXIgb3IgdGhlIGRldmljZS48L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgbyZuYnNw OyBUaGUgdmVyaWZpY2F0aW9uIG9mIHRoZSBzaWduYXR1cmUgTVVTVCBpbmNsdWRlIG1lYW5zIG9m IHZlcmlmeWluZzwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGF0IHRoZSBzaWduZXIgaXMgYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIHNpZ25lZCBjb250ZW50IG9m IHRoZSBTSVA8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+SXQncyBub3QgY2xlYXIgd2hhdCBhdXRob3JpdHkgaXMg YmVpbmcgY2xhaW1lZCBoZXJlLiBJcyB0aGlzIHN1cHBvc2VkIHRvIG1lYW4gc29tZXRoaW5nIGxp a2UgJnF1b3Q7Li4udmVyaWZ5aW5nIHRoYXQgdGhlIHNpZ25lciBpcyBhdXRob3JpdGF0aXZlIGZv ciB0aGUgb3JpZ2luYXRpbmcgdG4gaW4gdGhlIFBBU1Nwb3JULi4uJnF1b3Q7PyBPciAmcXVvdDsu Li5hdXRob3JpdGF0aXZlIGZvciB0aGUgcmVzb3VyY2UgcHJpb3JpdHkgbmFtZXNwYWNlIGluIHRo ZSBQQVNTcG9yVD8mcXVvdDsNCiBXaGF0ZXZlciB0aGUgc2VydmVyIGlzIHB1cnBvcnRlZGx5IGF1 dGhvcml0YXRpdmUgZm9yIG5lZWRzIHRvIGJlIGNsZWFybHkgc3BlbGxlZCBvdXQuPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAnUmVzb3VyY2UtUHJpb3JpdHknIGhlYWRlci48L3NwYW4+PC90dD48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+JnF1 b3Q7Li4uaGVhZGVyIGZpZWxkLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi9hDQo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0Kc3RpciBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3RpckBpZXRm Lm9yZyI+c3RpckBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX3N0aXImYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1w O3I9Rzl2OHVDU1NRaENtcHc3SXRHMHIyZyZhbXA7bT1zbEtJQlkzN3k4cDRpQzNKZ2p1d0QxVEk5 T2dXN1FUSFd6bUpWeXF5Sk5nJmFtcDtzPXU2UUNybm1ranpxeHU2UTNaVE02TUNVUFBqd1hGYmlZ blJSdE1wWlRYNkkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zdGlyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E42CCDDA6722744CB241677169E8365668A592A9MISOUT7MSGUSRDB_-- From nobody Sun Feb 4 18:45:54 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FDE124319; Sun, 4 Feb 2018 18:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 iS61jWZCRgxm; Sun, 4 Feb 2018 18:45:47 -0800 (PST) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760C712422F; Sun, 4 Feb 2018 18:45:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id 8BD2A646B32; Sun, 4 Feb 2018 21:41:10 -0500 (EST) X-Virus-Scanned: by SpamTitan at appcomsci.com Received: from thumper.appcomsci.com (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id 02F85646B2F; Sun, 4 Feb 2018 21:41:09 -0500 (EST) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (Postfix) with ESMTPS id B5064646B00; Sun, 4 Feb 2018 21:41:09 -0500 (EST) Received: from brg-exmb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id w152jgCT003150; Sun, 4 Feb 2018 21:45:42 -0500 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([fe80::fc05:b53:7f2b:84f9%18]) with mapi id 14.03.0361.001; Sun, 4 Feb 2018 21:45:42 -0500 From: "Singh, Ray P" To: "DOLLY, MARTIN C" , Subir , "Christer Holmberg" CC: "stir@ietf.org" , Adam Roach , "STIR Chairs" , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AdOTv2oSY/dEf4YfRra4GseuGeXVLAIG3t0AAIk5yQAADV+xAAACac0A///VyW4= Date: Mon, 5 Feb 2018 02:45:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [205.132.0.198] Content-Type: multipart/alternative; boundary="_000_C1A3E161FB009440ABA575570A60CD9C9A5FED72rrcatsexmb2atsa_" MIME-Version: 1.0 Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 02:45:52 -0000 --_000_C1A3E161FB009440ABA575570A60CD9C9A5FED72rrcatsexmb2atsa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, Yes, the claim is only for the RPH. The"orig" and "dest" is included so tha= t the RPH claim can be correlated to the call. We can add some clarificati= on text to indicate that "orig" is only included so that the RPH claim can = be correlated to a specific call, and that the signer of the RPH claim may = no have authority of the "orig" TN. Thanks Ray ________________________________ From: stir [stir-bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135@att= .com] Sent: Sunday, February 04, 2018 7:05 PM To: Subir; Christer Holmberg Cc: stir@ietf.org; Adam Roach; STIR Chairs; draft-ietf-stir-rph.all@tools.i= etf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We only have one claim and that is the RPH From: Subir [mailto:subirdas21@gmail.com] Sent: Sunday, February 04, 2018 5:56 PM To: Christer Holmberg Cc: Adam Roach ; STIR Chairs ; stir= @ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to other claim= s such as 'orig' and in other cases it may not have. We can add a may stat= ement clarifying this or explicitly say that it is not required to have aut= hority to other claims. Thanks, Subir Sent from my iPhone On Feb 4, 2018, at 10:03 PM, Christer Holmberg > wrote: Hi, The text says: =93The credentials (e.g., authority responsible for authorizing Resource= - Priority) used to create the signature must have authority over the namespace of the "rph" claim and there is only one authority per claim.=94 If the credentials don=92t need to have authority of the other claims (e.g.= , =93orig=94) in the RPH PASSPorT I think you should explicitly say so. Regards, Christer From: Subir Das [mailto:subirdas21@gmail.com] Sent: 02 February 2018 01:04 To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hello Christer, The signing entity does not have always the authority to assert the caller = identity in rph. We are submitting ver-03 draft and it is clarified as fo= llows: "The credentials (e.g., authority responsible for authorizing Resource-Prio= rity) used to create the signature must have authority over the namespace o= f the=93rph" claim.." -Subir On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg > wrote: Hi, Another question for clarification. Section 3 contains the following example: { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} =85and the following text: =93The credentials (e.g., authority responsible for authorizing Resource= - Priority) used to create the signature must have authority over the "rph" claim=85=94 Since the claim also contains =93orig=94, is the assumption that the signin= g entity always also has authority to assert the callers identity? I think = it would be good to explicitly mention it. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On = Behalf Of Adam Roach Sent: 20 January 2018 00:15 To: STIR Chairs >; stir@i= etf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: [stir] AD Review: draft-ietf-stir-rph-02 I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who ha= s worked on this document, and the authors and chairs in particular. The technical content here looks generally good to me. I'd like to see a fe= w issues addressed before IETF LC. In short sumary: * The validation section needs to add a discussion of how to treat call= s when the priority values in "rph" passports and SIP "Resource-Priority" h= eader fields aren't 100% identical. * The examples need some adjustment. * There is a minor point of ambiguity in the Security Section, but this= should be easy to fix, as long as the WG knows what was intended. * The IANA actions need a little bit of adjustment. * There are a number of minor editorial issues to be cleaned up. Detailed comments on these points are inline in the document below. I've re= moved some portions of the document on which I have no comments. Abstract This document extends the STIR PASSporT specification to allow the "...the Secure Telephone Identity Revisited (STIR) Personal Assertion Token= (PASSporT) specification defined in RFC 8122..." (See for guidance on abbreviations) inclusion of cryptographically-signed assertions of authorization for the values populated in the SIP 'Resource-Priority' header field, which is used for communications resource prioritization. ... 1. Introduction PASSporT [I-D.ietf-stir-passport] is a token format based on JWT [RFC7519] for conveying cryptographically-signed information about the identities involved in personal communications; it is used with STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to "...like SIP [RFC3261]..." (We want to cite SIP the first time it is mentioned) allow cryptographic-signing of the SIP 'Resource-Priority' header field defined in [RFC4412]. [RFC4412] defines the SIP 'Resource-Priority' header field for communications Resource Priority. As specified in [RFC4412], the 'Resource-Priority' header field may be used by SIP user agents [RFC3261], including, Public Switched Telephone Network (PSTN) "...including Public Switched..." (remove the comma) gateways and terminals, and SIP proxy servers to influence "...and by SIP proxy servers, to influence..." (add "by" and comma) prioritization afforded to communication sessions,including PSTN "...sessions, including..." (space after comma) calls. However, the SIP 'Resource-Priority' header field could be spoofed and abused by unauthorized entities. The STIR architecture [RFC7340]assumes that an authority on the "...STIR architecture [RFC7340] assumes..." (space before "assumes") originating side of a call provides a cryptographic assurance of the validity of the calling party number in order to prevent impersonation attacks. The STIR architecture allows extension that "...allows extensions..." can be utilized by authorities supporting real-time communication services using the 'Resource-Priority' header field to cryptographically sign the SIP 'Resource-Priority' header field and convey assertion of the authorization for 'Resource-Priority'. For example, the authority on the originating side verifying the authorization of a particular communication for Resource-Priority can Single quotes around 'Resource-Priority'. use a PASSPorT claim to cryptographically-sign the SIP 'Resource- "...cryptographically sign..." Priority' header field and convey an assertion of the authorization for 'Resource-Priority'. This will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing Resource-Priority. Single quotes around 'Resource-Priority'. Cryptographically-signed SIP 'Resource-Priority' headers will allow a "...cryptographically signed SIP 'Resource-Priority' header fields..." (remove hyphen, and replace "headers" with "header fields") receiving entity to verify and act on the information with confidence that the information have not been spoofed or compromised. "...has not been spoofed or compromised." This specification documents an optional extension to PASSporT and the associated STIR mechanisms to provide a function to sign the SIP 'Resource-Priority' header field. This PASSporT object is used to provide attestation of a calling user authorization for priority communications. This is necessary in addition to the PASSporT object that is used for calling user telephone number attestation. How the optional extension to PASSporT is used for real-time communications supported using SIP 'Resource-Priority' header field is defined in other documents and is outside the scope of this document. I assume these other documents are under development? If so, they should be= cited here. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document has several non-normative uses of "must", "should," and "may,= " and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boi= lerplate. 3. PASSporT 'rph' Claim This specification defines a new JSON Web Token claim for "rph", which provides an assertion for information in SIP 'Resource- Priority'header. "...Priority' header field." (space after closing quotation mark, "header field" instead of "header") The creator of a PASSporT object adds a "ppt" value of "rph" to the header of a PASSporT object, in which case the PASSporT claims MUST contain a "rph" claim, and any entities verifying the PASSporT object will be required to understand the "ppt" extension in order to process the PASSporT in question. A PASSPorT header with the "ppt" included will look as follows: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer"} Ideally, this would be either pretty-printed or canonicalized. Since it's t= oo long to fit on a line in canonical form, I propose: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer" } The "rph" claim will provide an assertion of authorization,"auth", "...authorization, "auth", ..." (space between comma and opening quotation mark) for information in the SIP "Resource-Priority" header field (i.e., Resource-Priority: namespace "." r-priority) based on [RFC4412]. The use of the string 'namespace "." r-priority' here and elsewhere in the = document has a detrimental impact on readability. I strongly suggest replac= ing it with "r-value" (the name of this production in RFC4412) everywhere. Specifically, the "rph" claim includes assertion of the priority- level of the user to be used for a given communication session. The value of the "rph" claim is an array containing one or more of JSON objects for the content of the SIP 'Resource-Priority' header that is being asserted of which one of the "rph" object, is mandatory. This last sentence is very hard to parse; and (based on the example) the va= lue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object wit= h one or more keys. Each key is associated with a JSON Array. These arrays = contain Strings that correspond to the r-values indicated in the SIP "Resou= rce-Priority" header field.' (note: "header field", not "header") The following is an example "rph" claim for a SIP "Resource-Priority" header field with a "namespace "." r-priority" value of "ets.0" and with a "namespace "." r-priority" value of "wps.0". { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} As above, I recommend pretty-printing this. It's also missing a comma after= the "orig" value, and the top-level structure is missing a closing brace. = The value for "iat" needs to be enclosed in quotes. The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much of= which remains assignable (cf ). Putting all this together, I believe what you want is: { "orig":{"tn":"12155550112"}, "dest":{["tn":"12125550113"]}, "iat":"1443208345", "rph":{"auth":["ets.0","wps.0"]} } After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in [I-D.ietf-stir-passport] using the full form of PASSPorT. The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim and there is only one authority per claim. The authority MUST use its credentials (i.e., CERT) associated with the specific service supported by the SIP namespace in the claim. 4. 'rph' in SIP This section specifies SIP-specific usage for the "rph" claim in PASSporT. 4.1. Authentication Service Behavior The Authentication Service will create the "rph" claim using the values discussed in section 3 based on [RFC4412]. The construction of "rph" claim follows the steps described in Section 4 of [I-D.ietf-stir-rfc4474bis]. The resulting Identity header for "rph" might look as follows: "...header field..." "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256; ppt=3D"rph" This example has a number of issues: * In the Identity header field, the signed-identity-digest shouldn't be= quoted. * In the Identity header field, info is enclosed in <> rather than "". * In the Identity header field, ppt is a token rather than a quoted str= ing. * The signed-identity-digest header needs to indicate a "typ" of "passp= ort" rather than JWT, and it needs to include both a "ppt" and "x5u" field. * The signed-identity-digest body should contain only the passport clai= m rather than a JSON object that itself contains a base64-encoded JWS heade= r concatenated with a claim. * I believe that, even when the body is included, values in the header = and body need to be be canonicalized (i.e., all on one line, no spaces, in = alphabetical order, etc.) I would also recommend following the convention of indicating that line-wra= ps are only for readability, and including the header field name in the exa= mple. Putting all this together, I believe what you want is: For example, a Identity header field for "rph" might look as follows (backslashes shown for line folding only): Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D \ >;alg=3DES256;ppt=3Drph (Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550= 113, respectively) A SIP authentication service typically will derive the value of "rph" from the 'Resource-Priority' header field based on policy associated with service specific use of the "namespace "." r-priority" values based on [RFC4412]. The authentication service derives the value of the PASSPorT claim by verifying the authorization for Resource- Priority (i.e., verifying a calling user privilege for Resource- Priority based on its identity) which might be derived from customer profile data or from access to external services. [RFC4412] allows multiple "namespace "." r-priority" pairs, either in a single SIP Resource-Priority header or across multiple SIP Single quotes around 'Resource-Priority'. "...header field..." Resource-Priority headers. However, it is not necessary to sign all Single quotes around 'Resource-Priority'. "...header fields..." content of a SIP Resource-Priority header or all SIP Resource- Single quotes around 'Resource-Priority'. "...header field..." Priority headers in a given SIP message. An authority is only Single quotes around 'Resource-Priority'. "...header fields..." responsible for signing the content of a SIP Resource-Priority header Single quotes around 'Resource-Priority'. "...header field..." for which it has authority (e.g., a specific "namespace "." r-priority"). 4.2. Verification Service Behavior [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The behavior specified for the "ppt" values of "rph" is as follows: The verification service MUST extract the value associated with the "auth" key in a full form PASSPorT with a "ppt" value of "rph". If the signature validates, then the verification service can use the value of the "rph" claim as validation that the calling party is authorized for Resource-Priority, which would in turn be used for Single quotes around 'Resource-Priority'. This text is ambiguous about whether the validation indicates that the call= ing party is authorized to use the priorities indicated in the passport obj= ect, or the values in the SIP 'Resource-Priority' header field; and (taken = on its face) implies the latter, when the intention here should clearly be = the former. "...authorized for 'Resource-Priority' indicated in the claim. This value w= ould in turn be used for..." The text also needs to say something about comparing values in the claim to= values in the 'Resource-Priority' header field, and what a mismatch might = mean. The document says elsewhere that the signature might only cover some = of the r-values, which makes it entirely possible that the 'Resource-Priori= ty' field might contain more values than are signed. On the other hand, int= ermediaries might reasonably remove r-values as the call is processed. This= probably means that those removed priorities should not be used, even if t= hey are present in the passport. It seems reasonable to say that *typical* = processing by a receiving party would be to take the *union* of all RPH pas= sports that they trust, and *intersect* that with the priorities in 'Resour= ce-Priority' header fields to get the actual priority or priorities to be a= pplied to the call (subject to local policy). priority treatment in accordance with local policy for the associated communication service. In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires "iat" value in "rph" claim to be verified. The behavior of a SIP UAs upon receiving an INVITE containing a "...of a SIP UA upon..." or "...of SIP UAs upon..." PASSporT object with a "rph" claim will largely remain a matter of implementation policy for the specific communication service. In most cases,implementations would act based on confidence in the "...cases, implementations..." (space after comma) veracity of this information. The use of the compact form of Paragraph break before "The". PASSporT is not specified in this document. 5. Further Information Associated with Resource-Priority Single quotes around 'Resource-Priority'. There may be additional information about the calling party or the call that could be relevant to authorization for Resource-Priority. Single quotes around 'Resource-Priority'. This may include information related to the device subscription of the caller, or to any institutions that the caller or device is associated with, or even categories of institutions. All of these data elements would benefit from the secure attestations provided by the STIR and PASSporT frameworks. The specification of the "rph" claim could entail the optional presence of one or more such additional information fields. A new IANA registry has been defined to hold potential values of the "rph" array; see Section 6.2. The definition of the "rph" claim may have one or more such additional information field(s). Details of such "rph" claim to encompass other data elements are left for future version of this specification. 6. IANA Considerations 6.1. JSON Web Token Claims Registration I think there's some confusion here. You're registering a PASSporT ppt valu= e, not a new JWT claim. That is to say, you're adding an entry to this tabl= e: https://www.iana.org/assignments/passport/passport.xhtml Not to this table: https://www.iana.org/assignments/jwt/jwt.xhtml You would only use the second table if you had a new key to add to the PASS= porT header -- this specification does not do that. This section also needs some introductory text to let the IANA know exactly= what to do; e.g. "This document registers a new value for the "Personal As= sertion Token (PASSporT) Extensions" table. o ppt value: "rph" o Specification Document(s): Section 3 of [RFCThis] 6.2. PASSporT 'rph' Types This document requests that the IANA add a new entry to the PASSporT Types registry for the type "rph" which is specified in [RFCThis]. There isn't an IANA table called "PASSporT Types." I presume this is the re= gistration we just discussed in section 6.1, and so the above two lines can= be removed. This specification also requests that the IANA create a new registry for PASSporT "rph" types. Registration of new PASSporT "rph" types shall be under the specification required policy. This registry is to be initially populated with a single value for "auth" which is specified in [RFCThis]. This needs to be very clear about the fields to be included in this new reg= istry (e.g., "Registry entries must contain two fields: the name of the 'rp= h' type and the specification in which the type is described"). 7. Security Considerations The security considerations discussed in [I-D.ietf-stir-rfc4474bis] in Section 10 are applicable here. 7.1. Avoidance of replay and cut and paste attacks The PASSporT extension with a "ppt" value of "rph" MUST only be sent with SIP INVITE when 'Resource-Priority' header is used to convey the "...header field..." priority of the communication as defined in [RFC4412]. To avoid the replay, and cut and paste attacks, the procedures described in Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. 7.2. Solution Considerations The use of extension to PASSporT tokens with "ppt" value "rph" based on the validation of the digital signature and the associated certificate requires consideration of the authentication and authority or reputation of the signer to attest to the identity being asserted. The following considerations should be recognized when using PASSporT extension with "ppt" value of "rph": o An authority (signer) is only allowed to sign the content of a SIP 'Resource-Priority' header for which it has the right authority. "...header field..." The authority that signs the token MUST have a secure method for authentication of the end user or the device. o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the SIP It's not clear what authority is being claimed here. Is this supposed to me= an something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource pri= ority namespace in the PASSporT?" Whatever the server is purportedly author= itative for needs to be clearly spelled out. 'Resource-Priority' header. "...header field." /a _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_C1A3E161FB009440ABA575570A60CD9C9A5FED72rrcatsexmb2atsa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

All,

Yes, the claim is only for the RPH. The"orig" and "dest&q= uot; is included so that the RPH claim can be correlated to the call. = We can add some clarification text to indicate that "orig" is on= ly included so that the RPH claim can be correlated to a specific call, and that the signer of the RPH claim may no have authority of the "or= ig" TN.

Thanks

Ray

 

 

From: stir [stir-bounces@ietf.org] on beha= lf of DOLLY, MARTIN C [md3135@att.com]
Sent: Sunday, February 04, 2018 7:05 PM
To: Subir; Christer Holmberg
Cc: stir@ietf.org; Adam Roach; STIR Chairs; draft-ietf-stir-rph.all@= tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

We only have one claim and that is the RPH<= /p>

 

From: Subir [mailto:subirdas21@gma= il.com]
Sent: Sunday, February 04, 2018 5:56 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs= @ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 


We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to  other = claims such as 'orig' and in other cases it may not have.  We can add = a may statement clarifying this or explicitly say that it is not required to have authority to other claims.

 

Thanks,

 

Subir 
Sent from my iPhone


On Feb 4, 2018, at 10:03 PM, Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:

Hi,

 

The text says:

 

   =93The credentials (e= .g., authority responsible for authorizing Resource-

   Priority) used to cre= ate the signature must have authority over the

   namespace of the &quo= t;rph" claim and there is only one authority per

   claim.=94

 

If the credentials don=92t need to= have authority of the other claims (e.g., =93orig=94) in the RPH PASSPorT = I think you should explicitly say so.

 

Regards,

 

Christer

 

 

From: Subir Das [mailto:subirdas21@gmail.com]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hello Christer,

The signing entity does not have always the authorit= y to assert the caller identity in rph. We are submitting ver-03 draft = ; and it is clarified  as follows:

"The credentials (e.g., autho= rity responsible for authorizing Resource-Priority) used to create the sign= ature must have authority over the namespace of the=93rph" claim.."

 

-Subir

 

On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

Another question for clarification= .

 

Section 3 contains the following e= xample:

 

    { "orig&qu= ot;:{"tn":"12155551212"}

     "des= t":{["tn":"12125551213"]},

     "iat= ":1443208345,

     "rph= ":{"auth":["ets.0","wps.0"]}

 

=85and the following text:<= /p>

 

   =93The credentials (e= .g., authority responsible for authorizing Resource-

   Priority) used to cre= ate the signature must have authority over the

   "rph" claim= =85=94

<= span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: "Calibri",sans-serif;= COLOR: #1f497d"> 

Since the claim also contains =93o= rig=94, is the assumption that the signing entity always also has authority= to assert the callers identity? I think it would be good to explicitly mention it.

 

Regards,

 

Christer

 

 

 

 

 

 

From: stir [mailto:stir-bounces@ietf.org= ] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: [stir] AD Review: draft-ietf-stir-rph-02

 

I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who= has worked on this document, and the authors and chairs in particular.

The technical content here looks generally good to me. I'd like to see a= few issues addressed before IETF LC. In short sumary:

  • The validation section n= eeds to add a discussion of how to treat calls when the priority values in = "rph" passports and SIP "Resource-Priority" header fiel= ds aren't 100% identical.
  • The examples need s= ome adjustment.
  • There is a minor po= int of ambiguity in the Security Section, but this should be easy to fix, a= s long as the WG knows what was intended.
  • The IANA actions ne= ed a little bit of adjustment.
  • There are a number = of minor editorial issues to be cleaned up.

Detailed comments on these points are inline in the document below. I've= removed some portions of the document on which I have no comments.

 


Abstract

   This document extends the STIR PASSporT specification to a= llow the

 

"...the Secure Telephone Identity Revisited (STIR) Personal Asserti= on Token (PASSporT) specification defined in RFC 8122..."

(See <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for g= uidance on abbreviations)

 

   inc= lusion of cryptographically-signed assertions of authorization for    the values populated in the SIP 'Resource-Priority' header= field,
   which is used for communications resource prioritization.<= /tt>

...

1.  Introduction

   PASSporT [I-D.ietf-stir-passport] is a token format based = on JWT
   [RFC7519] for conveying cryptographically-signed informati= on about
   the identities involved in personal communications; it is = used with
   STIR [I-D.ietf-stir-rfc4474bis] to convey a signed asserti= on of the
   identity of the participants in real-time communications e= stablished
   via a protocol like SIP.  This specification extends = PASSporT to

 

"...like SIP [RFC3261]..."

(We want to cite SIP the first time it is mentioned)

 

   all= ow cryptographic-signing of the SIP 'Resource-Priority' header<= span style=3D"FONT-SIZE: 10pt; FONT-FAMILY: "Courier New"">
   field defined in [RFC4412].

   [RFC4412] defines the SIP 'Resource-Priority' header field= for
   communications Resource Priority.  As specified in [R= FC4412], the
   'Resource-Priority' header field may be used by SIP user a= gents
   [RFC3261], including, Public Switched Telephone Network (P= STN)

 

"...including Public Switched..."

(remove the comma)

 

   gat= eways and terminals, and SIP proxy servers to influence

 

"...and by SIP proxy servers, to influence..."

(add "by" and comma)

 

   pri= oritization afforded to communication sessions,including PSTN

 

"...sessions, including..."

(space after comma)

 

   cal= ls.  However, the SIP 'Resource-Priority' header field could be= =
   spoofed and abused by unauthorized entities.

   The STIR architecture [RFC7340]assumes that an authority o= n the

 

"...STIR architecture [RFC7340] assumes..."

(space before "assumes")

 

   ori= ginating side of a call provides a cryptographic assurance of the    validity of the calling party number in order to prevent
   impersonation attacks.  The STIR architecture allows = extension that

 

"...allows extensions..."

 

   can= be utilized by authorities supporting real-time communication<= span style=3D"FONT-SIZE: 10pt; FONT-FAMILY: "Courier New"">
   services using the 'Resource-Priority' header field to
   cryptographically sign the SIP 'Resource-Priority' header = field and
   convey assertion of the authorization for 'Resource-Priori= ty'.  For
   example, the authority on the originating side verifying t= he
   authorization of a particular communication for Resource-P= riority can

 

Single quotes around 'Resource-Priority'.

 

   use= a PASSPorT claim to cryptographically-sign the SIP 'Resource-<= /p>

 

"...cryptographically sign..."

 

   Pri= ority' header field and convey an assertion of the authorization
   for 'Resource-Priority'.  This will allow a receiving= entity
   (including entities located in different network domains/b= oundaries)
   to verify the validity of assertions authorizing Resource-= Priority.

 

Single quotes around 'Resource-Priority'.

 

   Cry= ptographically-signed SIP 'Resource-Priority' headers will allow a

 

"...cryptographically signed SIP 'Resource-Priority' header fields.= .."

(remove hyphen, and replace "headers" with "header fields= ")

 

   rec= eiving entity to verify and act on the information with confidence    that the information have not been spoofed or compromised.=

 

"...has not been spoofed or compromised."

 


   This specification documents an optional extension to PASS= porT and
   the associated STIR mechanisms to provide a function to si= gn the SIP
   'Resource-Priority' header field.  This PASSporT obje= ct is used to
   provide attestation of a calling user authorization for pr= iority
   communications.  This is necessary in addition to the= PASSporT object
   that is used for calling user telephone number attestation= .  How the
   optional extension to PASSporT is used for real-time commu= nications
   supported using SIP 'Resource-Priority' header field is de= fined in
   other documents and is outside the scope of this document.=

 

I assume these other documents are under development? If so, they should= be cited here.

 


2.  Terminology

   The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [R= FC2119].

 

This document has several non-normative uses of "must", "= should," and "may," and so it needs to use the RFC8174 boile= rplate instead of the RFC2119 boilerplate.

 


3.  PASSporT 'rph' Claim

   This specification defines a new JSON Web Token claim for = "rph",
   which provides an assertion for information in SIP 'Resour= ce-
   Priority'header.

 

"...Priority' header field."

(space after closing quotation mark, "header field" instead of= "header")

 


   The creator of a PASSporT object adds a "ppt" va= lue of "rph" to the
   header of a PASSporT object, in which case the PASSporT cl= aims MUST
   contain a "rph" claim, and any entities verifyin= g the PASSporT object
   will be required to understand the "ppt" extensi= on in order to
   process the PASSporT in question.  A PASSPorT header = with the "ppt"
   included will look as follows:

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.examp= le.org/cert.cer"}

 

Ideally, this would be either pretty-printed or canonicalized. Since it'= s too long to fit on a line in canonical form, I propose:

{
  "typ":"passport",
  "ppt":"rph",
  "alg":"ES256",
  "x5u":"https://www.example.org/cert.cer&qu= ot;
}

 


   The "rph" claim will provide an assertion of aut= horization,"auth",

 

"...authorization, "auth", ..."

(space between comma and opening quotation mark)

 

   for= information in the SIP "Resource-Priority" header field (i.e.,
   Resource-Priority: namespace "." r-priority) bas= ed on [RFC4412].

 

The use of the string 'namespace "." r-priority' here and else= where in the document has a detrimental impact on readability. I strongly s= uggest replacing it with "r-value" (the name of this production i= n RFC4412) everywhere.

 

   Spe= cifically, the "rph" claim includes assertion of the priority-
   level of the user to be used for a given communication ses= sion.  The
   value of the "rph" claim is an array containing = one or more of JSON
   objects for the content of the SIP 'Resource-Priority' hea= der that is
   being asserted of which one of the "rph" object,= is mandatory.

 

This last sentence is very hard to parse; and (based on the example) the= value is intended to be a JSON Object (curly braces) rather than a JSON Ar= ray (square braces). I suggest: 'The value of the "rph" claim is = an Object with one or more keys. Each key is associated with a JSON Array. These arrays contain Strings that corresp= ond to the r-values indicated in the SIP "Resource-Priority" head= er field.' (note: "header field", not "header")

 


   The following is an example "rph" claim for a SI= P "Resource-Priority"
   header field with a "namespace "." r-priori= ty" value of "ets.0" and
   with a "namespace "." r-priority" valu= e of "wps.0".

    { "orig":{"tn":"12155551212"}
     "dest":{["tn":"<= /span>12125551213<= tt>"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0= ","wps.0"]}

 

As above, I recommend pretty-printing this. It's also missing a comma af= ter the "orig" value, and the top-level structure is missing a cl= osing brace. The value for "iat" needs to be enclosed in quotes.<= /p>

The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much= of which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).

Putting all this together, I believe what you want is:

{
  "orig":{"tn":"12155550112"},
  "dest":{["tn":"12125550113"]},
  "iat":"1443208345",
  "rph":{"auth":["ets.0","wps.0= "]}
}

 


   After the header and claims PASSporT objects have been con= structed,
   their signature is generated normally per the guidance in<= /tt>
   [I-D.ietf-stir-passport] using the full form of PASSPorT.&= nbsp; The
   credentials (e.g., authority responsible for authorizing R= esource-
   Priority) used to create the signature must have authority= over the
   "rph" claim and there is only one authority per = claim.  The authority
   MUST use its credentials (i.e., CERT) associated with the = specific
   service supported by the SIP namespace in the claim.<= br>
4.  'rph' in SIP

   This section specifies SIP-specific usage for the "rp= h" claim in
   PASSporT.

4.1.  Authentication Service Behavior

   The Authentication Service will create the "rph"= claim using the
   values discussed in section 3 based on [RFC4412].  Th= e construction
   of "rph" claim follows the steps described in Se= ction 4 of
   [I-D.ietf-stir-rfc4474bis].

   The resulting Identity header for "rph" might lo= ok as follows:

 

"...header field..."

 


   "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUo= wZVhBaU9pSnd
   ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKR= lV6STFO
   aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1Odm= JTOWpaW
   EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjB= iaUk2SW
   pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlN= VEkxTlR
   VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR= 2dpT25z
   aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6= VC8HM6D
   l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXv= s3fslM_
   oos2P2Dyw"; info=3D "https://www.example.= org/cert.cer";alg=3DES2= 56;
   ppt=3D"rph"

 

This example has a number of issues:

  • In the Identity header f= ield, the signed-identity-digest shouldn't be quoted.
  • In the Identity hea= der field, info is enclosed in <> rather than "".
  • In the Identity hea= der field, ppt is a token rather than a quoted string.
  • The signed-identity= -digest header needs to indicate a "typ" of "passport" = rather than JWT, and it needs to include both a "ppt" and "x= 5u" field.
  • The signed-identity= -digest body should contain only the passport claim rather than a JSON obje= ct that itself contains a base64-encoded JWS header concatenated with a cla= im.
  • I believe that, eve= n when the body is included, values in the header and body need to be be ca= nonicalized (i.e., all on one line, no spaces, in alphabetical order, etc.)=

I would also recommend following the convention of indicating that line-= wraps are only for readability, and including the header field name in the = example. Putting all this together, I believe what you want is:

   For example, a Identity= header field for "rph" might look
   as follows (backslashes shown for line folding only):=

   Identity: eyJhbGciOiJFU= zI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \
   iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo= .eyJkZXN0 \
   Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Ii= wib3JpZyI \
   6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wI= iwid3BzLj \
   AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl= -n8MIhoCr \
   18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D<https://www= .example.org/cert.cer \
   >;alg=3DES256;ppt=3Drph

(Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550113, respectively)

 


   A SIP authentication service typically will derive the val= ue of "rph"
   from the 'Resource-Priority' header field based on policy = associated
   with service specific use of the "namespace ".&q= uot; r-priority" values
   based on [RFC4412].  The authentication service deriv= es the value of
   the PASSPorT claim by verifying the authorization for Reso= urce-
   Priority (i.e., verifying a calling user privilege for Res= ource-
   Priority based on its identity) which might be derived fro= m customer
   profile data or from access to external services.

   [RFC4412] allows multiple "namespace "." r-= priority" pairs, either in
   a single SIP Resource-Priority header or across multiple S= IP

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   Res= ource-Priority headers.  However, it is not necessary to sign all

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

   con= tent of a SIP Resource-Priority header or all SIP Resource-

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   Pri= ority headers in a given SIP message.  An authority is only

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

   res= ponsible for signing the content of a SIP Resource-Priority header

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   for= which it has authority (e.g., a specific "namespace "."
   r-priority").

4.2.  Verification Service Behavior

   [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires tha= t
   specifications defining "ppt" values describe an= y additional verifier
   behavior.  The behavior specified for the "ppt&q= uot; values of "rph" is as
   follows:

   The verification service MUST extract the value associated= with the
   "auth" key in a full form PASSPorT with a "= ppt" value of "rph".  If
   the signature validates, then the verification service can= use the
   value of the "rph" claim as validation that the = calling party is
   authorized for Resource-Priority, which would in turn be u= sed for

 

Single quotes around 'Resource-Priority'.

This text is ambiguous about whether the validation indicates that the c= alling party is authorized to use the priorities indicated in the passport = object, or the values in the SIP 'Resource-Priority' header field; and (tak= en on its face) implies the latter, when the intention here should clearly be the former.

"...authorized for 'Resource-Priority' indicated in the claim. This= value would in turn be used for..."

The text also needs to say something about comparing values in the claim= to values in the 'Resource-Priority' header field, and what a mismatch mig= ht mean. The document says elsewhere that the signature might only cover so= me of the r-values, which makes it entirely possible that the 'Resource-Priority' field might contain more= values than are signed. On the other hand, intermediaries might reasonably= remove r-values as the call is processed. This probably means that those r= emoved priorities should not be used, even if they are present in the passport. It seems reasonable to say= that *typical* processing by a receiving party would be to take the *union= * of all RPH passports that they trust, and *intersect* that with the prior= ities in 'Resource-Priority' header fields to get the actual priority or priorities to be applied to the call = (subject to local policy).

 

   pri= ority treatment in accordance with local policy for the associated    communication service.

   In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4= requires
   "iat" value in "rph" claim to be verif= ied.

   The behavior of a SIP UAs upon receiving an INVITE contain= ing a

 

"...of a SIP UA upon..."

or

"...of SIP UAs upon..."

 

   PAS= SporT object with a "rph" claim will largely remain a matter of
   implementation policy for the specific communication servi= ce.  In
   most cases,implementations would act based on confidence i= n the

 

"...cases, implementations..."

(space after comma)

 

   ver= acity of this information.  The use of the compact form of=

 

Paragraph break before "The".

 

   PAS= SporT is not specified in this document.

5.  Further Information Associated with Resource-Priority

 

Single quotes around 'Resource-Priority'.

 


   There may be additional information about the calling part= y or the
   call that could be relevant to authorization for Resource-= Priority.

 

Single quotes around 'Resource-Priority'.

 

   Thi= s may include information related to the device subscription of=
   the caller, or to any institutions that the caller or devi= ce is
   associated with, or even categories of institutions. = All of these
   data elements would benefit from the secure attestations p= rovided by
   the STIR and PASSporT frameworks.  The specification = of the "rph"
   claim could entail the optional presence of one or more su= ch
   additional information fields.

   A new IANA registry has been defined to hold potential val= ues of the
   "rph" array; see Section 6.2.  The definiti= on of the "rph" claim may
   have one or more such additional information field(s).&nbs= p; Details of
   such "rph" claim to encompass other data element= s are left for future
   version of this specification.

6.  IANA Considerations

6.1.  JSON Web Token Claims Registration

 

I think there's some confusion here. You're registering a PASSporT ppt v= alue, not a new JWT claim. That is to say, you're adding an entry to this t= able:

https://www.iana.org/assignments/passport/passpo= rt.xhtml

Not to this table:

https://www.iana.org/assignments/jwt/jwt.xhtml

You would only use the second table if you had a new key to add to the P= ASSporT header -- this specification does not do that.

This section also needs some introductory text to let the IANA know exac= tly what to do; e.g. "This document registers a new value for the &quo= t;Personal Assertion Token (PASSporT) Extensions" table.


   o  ppt value: "rph"

   o  Specification Document(s): Section 3 of [RFCThis]<= /tt>

6.2.  PASSporT 'rph' Types

   This document requests that the IANA add a new entry to th= e PASSporT
   Types registry for the type "rph" which is speci= fied in [RFCThis].

 

There isn't an IANA table called "PASSporT Types." I presume t= his is the registration we just discussed in section 6.1, and so the above = two lines can be removed.

 

   Thi= s specification also requests that the IANA create a new registry    for PASSporT "rph" types.  Registration of = new PASSporT "rph" types
   shall be under the specification required policy.  Th= is registry is
   to be initially populated with a single value for "au= th" which is
   specified in [RFCThis].

 

This needs to be very clear about the fields to be included in this new = registry (e.g., "Registry entries must contain two fields: the name of= the 'rph' type and the specification in which the type is described")= .

 


7.  Security Considerations

   The security considerations discussed in [I-D.ietf-stir-rf= c4474bis]
   in Section 10 are applicable here.

7.1.  Avoidance of replay and cut and paste attacks

   The PASSporT extension with a "ppt" value of &qu= ot;rph" MUST only be sent
   with SIP INVITE when 'Resource-Priority' header is used to= convey the

 

"...header field..."

 

   pri= ority of the communication as defined in [RFC4412].  To avoid the

  &nbs= p;   The authority that signs the token MUST have a secure method= for
      authentication of the end user or the de= vice.

   o  The verification of the signature MUST include mea= ns of verifying
      that the signer is authoritative for the= signed content of the SIP

 

It's not clear what authority is being claimed here. Is this supposed to= mean something like "...verifying that the signer is authoritative fo= r the originating tn in the PASSporT..."? Or "...authoritative fo= r the resource priority namespace in the PASSporT?" Whatever the server is purportedly authoritative for needs to be clearly s= pelled out.

 

  &nbs= p;   'Resource-Priority' header.

 

"...header field."

 

/a


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 

--_000_C1A3E161FB009440ABA575570A60CD9C9A5FED72rrcatsexmb2atsa_-- From nobody Sun Feb 4 22:37:53 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4971A126E01 for ; Sun, 4 Feb 2018 22:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 FTKlfmAFgMiV for ; Sun, 4 Feb 2018 22:37:47 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C5A126BF0 for ; Sun, 4 Feb 2018 22:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517812663; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SMMdb0kkSESFScqdjEXtUOoEahkcMrpsKnPwvdizgCM=; b=NnBvMfBGH9haxGlBv+pn1izQCXe3isx4o/wI9EBnGT/WD6kx7HpOPfTlQpjSuGcz cGkmgahzmo5ik30qfguAIr0gK4S84ueFRk8DU+ILTfR2ZQZBadINvRcn+szaIzdm aBmdNfYCRmBGG/d/JRQ1hjo2qop6oVc9sniLYP/cl1M=; X-AuditID: c1b4fb2d-499ff70000005540-9d-5a77fbb79656 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8D.66.21824.7BBF77A5; Mon, 5 Feb 2018 07:37:43 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Mon, 5 Feb 2018 07:37:43 +0100 From: Christer Holmberg To: "Singh, Ray P" CC: "DOLLY, MARTIN C" , Subir , "stir@ietf.org" , Adam Roach , STIR Chairs , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AdOTv2oSY/dEf4YfRra4GseuGeXVLAH6TDcAAIWJiHAAEQ/yAAACac0AAAWX2oAACjLjqg== Date: Mon, 5 Feb 2018 06:37:42 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D3F011C97E234BBF8D9FE7C2776A4317ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7uu723+VRBjc/Glrs+buI3WL18XNM FocePGW3OP/wJbPFsx3rWS2Wr93GZDHlwDJ2B3aPl/1zGD12zrrL7rFkyU8mj1k7n7B4fLn8 mc2j+dRW5gC2KC6blNSczLLUIn27BK6MK5PXshc0XmSt6P3/hL2BccZ7li5GTg4JAROJ3yeO MXUxcnEICRxmlNh79xYLhLOYUeL3tp/sXYwcHGwCFhLd/7RBTBEBbYl36/xBSpgFGpkk1s9b xwoySFggW2Lj0U1gtohAjsTJX38ZIewwiZuf57KD2CwCKhK3fn0Eq+EVsJfou7+VDWLXMmaJ LzNWMIEkOAUiJZ4+XgzWwCggJvH91BqwOLOAuMStJ/OZIK4WkFiy5zwzhC0q8fLxP1aImmSJ eUdOs0AsEJQ4OfMJywRG4VlI2mchKZuFpAwibiDx/tx8ZghbW2LZwtdQtr7Exi9nGZHFFzCy r2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjM+DW37r7mBc/drxEKMAB6MSD2/yy/IoIdbE suLK3EOMEhzMSiK8TteBQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5akZqemFqQW wWSZODilGhhdlXgkNiSXV9nrn7Kbtn5FfLrLzrfX0qyd/PVNp88uSekPuvZkf7tNvWK69yaP NsP9u+y/7PnQ/VJIO7zmyjpz3eBTH/0Tc3cUXMjl3s4qKnpM/7XCrvsC3HZHMk0dV91rsc8z ixHmiRHf4LD30PcnUsqbLwmfjv1v4dj+I1vrs+POTWXJ4UosxRmJhlrMRcWJAGfV9vfLAgAA Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 06:37:52 -0000 --_000_D3F011C97E234BBF8D9FE7C2776A4317ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I think the reason why =91orig=92 and =91dest=92 are required in every PASS= PorT should be explained the the PASSPorT document, in my opinion. It is no= t specific to the RPH extension. Not sure how =91orig=92 can be used to identify a call. You can have multip= le calls with the same =91orig=92 value, can=92t you? Regards, Christer Sent from my iPhone On 4 Feb 2018, at 21.45, Singh, Ray P > wrote: All, Yes, the claim is only for the RPH. The"orig" and "dest" is included so tha= t the RPH claim can be correlated to the call. We can add some clarificati= on text to indicate that "orig" is only included so that the RPH claim can = be correlated to a specific call, and that the signer of the RPH claim may = no have authority of the "orig" TN. Thanks Ray ________________________________ From: stir [stir-bounces@ietf.org] on behalf = of DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, February 04, 2018 7:05 PM To: Subir; Christer Holmberg Cc: stir@ietf.org; Adam Roach; STIR Chairs; draft-iet= f-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We only have one claim and that is the RPH From: Subir [mailto:subirdas21@gmail.com] Sent: Sunday, February 04, 2018 5:56 PM To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to other claim= s such as 'orig' and in other cases it may not have. We can add a may stat= ement clarifying this or explicitly say that it is not required to have aut= hority to other claims. Thanks, Subir Sent from my iPhone On Feb 4, 2018, at 10:03 PM, Christer Holmberg > wrote: Hi, The text says: =93The credentials (e.g., authority responsible for authorizing Resource= - Priority) used to create the signature must have authority over the namespace of the "rph" claim and there is only one authority per claim.=94 If the credentials don=92t need to have authority of the other claims (e.g.= , =93orig=94) in the RPH PASSPorT I think you should explicitly say so. Regards, Christer From: Subir Das [mailto:subirdas21@gmail.com] Sent: 02 February 2018 01:04 To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hello Christer, The signing entity does not have always the authority to assert the caller = identity in rph. We are submitting ver-03 draft and it is clarified as fo= llows: "The credentials (e.g., authority responsible for authorizing Resource-Prio= rity) used to create the signature must have authority over the namespace o= f the=93rph" claim.." -Subir On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg > wrote: Hi, Another question for clarification. Section 3 contains the following example: { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} =85and the following text: =93The credentials (e.g., authority responsible for authorizing Resource= - Priority) used to create the signature must have authority over the "rph" claim=85=94 Since the claim also contains =93orig=94, is the assumption that the signin= g entity always also has authority to assert the callers identity? I think = it would be good to explicitly mention it. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On = Behalf Of Adam Roach Sent: 20 January 2018 00:15 To: STIR Chairs >; stir@i= etf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: [stir] AD Review: draft-ietf-stir-rph-02 I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who ha= s worked on this document, and the authors and chairs in particular. The technical content here looks generally good to me. I'd like to see a fe= w issues addressed before IETF LC. In short sumary: * The validation section needs to add a discussion of how to treat call= s when the priority values in "rph" passports and SIP "Resource-Priority" h= eader fields aren't 100% identical. * The examples need some adjustment. * There is a minor point of ambiguity in the Security Section, but this= should be easy to fix, as long as the WG knows what was intended. * The IANA actions need a little bit of adjustment. * There are a number of minor editorial issues to be cleaned up. Detailed comments on these points are inline in the document below. I've re= moved some portions of the document on which I have no comments. Abstract This document extends the STIR PASSporT specification to allow the "...the Secure Telephone Identity Revisited (STIR) Personal Assertion Token= (PASSporT) specification defined in RFC 8122..." (See for guidance on abbreviations) inclusion of cryptographically-signed assertions of authorization for the values populated in the SIP 'Resource-Priority' header field, which is used for communications resource prioritization. ... 1. Introduction PASSporT [I-D.ietf-stir-passport] is a token format based on JWT [RFC7519] for conveying cryptographically-signed information about the identities involved in personal communications; it is used with STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to "...like SIP [RFC3261]..." (We want to cite SIP the first time it is mentioned) allow cryptographic-signing of the SIP 'Resource-Priority' header field defined in [RFC4412]. [RFC4412] defines the SIP 'Resource-Priority' header field for communications Resource Priority. As specified in [RFC4412], the 'Resource-Priority' header field may be used by SIP user agents [RFC3261], including, Public Switched Telephone Network (PSTN) "...including Public Switched..." (remove the comma) gateways and terminals, and SIP proxy servers to influence "...and by SIP proxy servers, to influence..." (add "by" and comma) prioritization afforded to communication sessions,including PSTN "...sessions, including..." (space after comma) calls. However, the SIP 'Resource-Priority' header field could be spoofed and abused by unauthorized entities. The STIR architecture [RFC7340]assumes that an authority on the "...STIR architecture [RFC7340] assumes..." (space before "assumes") originating side of a call provides a cryptographic assurance of the validity of the calling party number in order to prevent impersonation attacks. The STIR architecture allows extension that "...allows extensions..." can be utilized by authorities supporting real-time communication services using the 'Resource-Priority' header field to cryptographically sign the SIP 'Resource-Priority' header field and convey assertion of the authorization for 'Resource-Priority'. For example, the authority on the originating side verifying the authorization of a particular communication for Resource-Priority can Single quotes around 'Resource-Priority'. use a PASSPorT claim to cryptographically-sign the SIP 'Resource- "...cryptographically sign..." Priority' header field and convey an assertion of the authorization for 'Resource-Priority'. This will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing Resource-Priority. Single quotes around 'Resource-Priority'. Cryptographically-signed SIP 'Resource-Priority' headers will allow a "...cryptographically signed SIP 'Resource-Priority' header fields..." (remove hyphen, and replace "headers" with "header fields") receiving entity to verify and act on the information with confidence that the information have not been spoofed or compromised. "...has not been spoofed or compromised." This specification documents an optional extension to PASSporT and the associated STIR mechanisms to provide a function to sign the SIP 'Resource-Priority' header field. This PASSporT object is used to provide attestation of a calling user authorization for priority communications. This is necessary in addition to the PASSporT object that is used for calling user telephone number attestation. How the optional extension to PASSporT is used for real-time communications supported using SIP 'Resource-Priority' header field is defined in other documents and is outside the scope of this document. I assume these other documents are under development? If so, they should be= cited here. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document has several non-normative uses of "must", "should," and "may,= " and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boi= lerplate. 3. PASSporT 'rph' Claim This specification defines a new JSON Web Token claim for "rph", which provides an assertion for information in SIP 'Resource- Priority'header. "...Priority' header field." (space after closing quotation mark, "header field" instead of "header") The creator of a PASSporT object adds a "ppt" value of "rph" to the header of a PASSporT object, in which case the PASSporT claims MUST contain a "rph" claim, and any entities verifying the PASSporT object will be required to understand the "ppt" extension in order to process the PASSporT in question. A PASSPorT header with the "ppt" included will look as follows: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer"} Ideally, this would be either pretty-printed or canonicalized. Since it's t= oo long to fit on a line in canonical form, I propose: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer" } The "rph" claim will provide an assertion of authorization,"auth", "...authorization, "auth", ..." (space between comma and opening quotation mark) for information in the SIP "Resource-Priority" header field (i.e., Resource-Priority: namespace "." r-priority) based on [RFC4412]. The use of the string 'namespace "." r-priority' here and elsewhere in the = document has a detrimental impact on readability. I strongly suggest replac= ing it with "r-value" (the name of this production in RFC4412) everywhere. Specifically, the "rph" claim includes assertion of the priority- level of the user to be used for a given communication session. The value of the "rph" claim is an array containing one or more of JSON objects for the content of the SIP 'Resource-Priority' header that is being asserted of which one of the "rph" object, is mandatory. This last sentence is very hard to parse; and (based on the example) the va= lue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object wit= h one or more keys. Each key is associated with a JSON Array. These arrays = contain Strings that correspond to the r-values indicated in the SIP "Resou= rce-Priority" header field.' (note: "header field", not "header") The following is an example "rph" claim for a SIP "Resource-Priority" header field with a "namespace "." r-priority" value of "ets.0" and with a "namespace "." r-priority" value of "wps.0". { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} As above, I recommend pretty-printing this. It's also missing a comma after= the "orig" value, and the top-level structure is missing a closing brace. = The value for "iat" needs to be enclosed in quotes. The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much of= which remains assignable (cf ). Putting all this together, I believe what you want is: { "orig":{"tn":"12155550112"}, "dest":{["tn":"12125550113"]}, "iat":"1443208345", "rph":{"auth":["ets.0","wps.0"]} } After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in [I-D.ietf-stir-passport] using the full form of PASSPorT. The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim and there is only one authority per claim. The authority MUST use its credentials (i.e., CERT) associated with the specific service supported by the SIP namespace in the claim. 4. 'rph' in SIP This section specifies SIP-specific usage for the "rph" claim in PASSporT. 4.1. Authentication Service Behavior The Authentication Service will create the "rph" claim using the values discussed in section 3 based on [RFC4412]. The construction of "rph" claim follows the steps described in Section 4 of [I-D.ietf-stir-rfc4474bis]. The resulting Identity header for "rph" might look as follows: "...header field..." "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256; ppt=3D"rph" This example has a number of issues: * In the Identity header field, the signed-identity-digest shouldn't be= quoted. * In the Identity header field, info is enclosed in <> rather than "". * In the Identity header field, ppt is a token rather than a quoted str= ing. * The signed-identity-digest header needs to indicate a "typ" of "passp= ort" rather than JWT, and it needs to include both a "ppt" and "x5u" field. * The signed-identity-digest body should contain only the passport clai= m rather than a JSON object that itself contains a base64-encoded JWS heade= r concatenated with a claim. * I believe that, even when the body is included, values in the header = and body need to be be canonicalized (i.e., all on one line, no spaces, in = alphabetical order, etc.) I would also recommend following the convention of indicating that line-wra= ps are only for readability, and including the header field name in the exa= mple. Putting all this together, I believe what you want is: For example, a Identity header field for "rph" might look as follows (backslashes shown for line folding only): Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D \ >;alg=3DES256;ppt=3Drph (Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550= 113, respectively) A SIP authentication service typically will derive the value of "rph" from the 'Resource-Priority' header field based on policy associated with service specific use of the "namespace "." r-priority" values based on [RFC4412]. The authentication service derives the value of the PASSPorT claim by verifying the authorization for Resource- Priority (i.e., verifying a calling user privilege for Resource- Priority based on its identity) which might be derived from customer profile data or from access to external services. [RFC4412] allows multiple "namespace "." r-priority" pairs, either in a single SIP Resource-Priority header or across multiple SIP Single quotes around 'Resource-Priority'. "...header field..." Resource-Priority headers. However, it is not necessary to sign all Single quotes around 'Resource-Priority'. "...header fields..." content of a SIP Resource-Priority header or all SIP Resource- Single quotes around 'Resource-Priority'. "...header field..." Priority headers in a given SIP message. An authority is only Single quotes around 'Resource-Priority'. "...header fields..." responsible for signing the content of a SIP Resource-Priority header Single quotes around 'Resource-Priority'. "...header field..." for which it has authority (e.g., a specific "namespace "." r-priority"). 4.2. Verification Service Behavior [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The behavior specified for the "ppt" values of "rph" is as follows: The verification service MUST extract the value associated with the "auth" key in a full form PASSPorT with a "ppt" value of "rph". If the signature validates, then the verification service can use the value of the "rph" claim as validation that the calling party is authorized for Resource-Priority, which would in turn be used for Single quotes around 'Resource-Priority'. This text is ambiguous about whether the validation indicates that the call= ing party is authorized to use the priorities indicated in the passport obj= ect, or the values in the SIP 'Resource-Priority' header field; and (taken = on its face) implies the latter, when the intention here should clearly be = the former. "...authorized for 'Resource-Priority' indicated in the claim. This value w= ould in turn be used for..." The text also needs to say something about comparing values in the claim to= values in the 'Resource-Priority' header field, and what a mismatch might = mean. The document says elsewhere that the signature might only cover some = of the r-values, which makes it entirely possible that the 'Resource-Priori= ty' field might contain more values than are signed. On the other hand, int= ermediaries might reasonably remove r-values as the call is processed. This= probably means that those removed priorities should not be used, even if t= hey are present in the passport. It seems reasonable to say that *typical* = processing by a receiving party would be to take the *union* of all RPH pas= sports that they trust, and *intersect* that with the priorities in 'Resour= ce-Priority' header fields to get the actual priority or priorities to be a= pplied to the call (subject to local policy). priority treatment in accordance with local policy for the associated communication service. In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires "iat" value in "rph" claim to be verified. The behavior of a SIP UAs upon receiving an INVITE containing a "...of a SIP UA upon..." or "...of SIP UAs upon..." PASSporT object with a "rph" claim will largely remain a matter of implementation policy for the specific communication service. In most cases,implementations would act based on confidence in the "...cases, implementations..." (space after comma) veracity of this information. The use of the compact form of Paragraph break before "The". PASSporT is not specified in this document. 5. Further Information Associated with Resource-Priority Single quotes around 'Resource-Priority'. There may be additional information about the calling party or the call that could be relevant to authorization for Resource-Priority. Single quotes around 'Resource-Priority'. This may include information related to the device subscription of the caller, or to any institutions that the caller or device is associated with, or even categories of institutions. All of these data elements would benefit from the secure attestations provided by the STIR and PASSporT frameworks. The specification of the "rph" claim could entail the optional presence of one or more such additional information fields. A new IANA registry has been defined to hold potential values of the "rph" array; see Section 6.2. The definition of the "rph" claim may have one or more such additional information field(s). Details of such "rph" claim to encompass other data elements are left for future version of this specification. 6. IANA Considerations 6.1. JSON Web Token Claims Registration I think there's some confusion here. You're registering a PASSporT ppt valu= e, not a new JWT claim. That is to say, you're adding an entry to this tabl= e: https://www.iana.org/assignments/passport/passport.xhtml Not to this table: https://www.iana.org/assignments/jwt/jwt.xhtml You would only use the second table if you had a new key to add to the PASS= porT header -- this specification does not do that. This section also needs some introductory text to let the IANA know exactly= what to do; e.g. "This document registers a new value for the "Personal As= sertion Token (PASSporT) Extensions" table. o ppt value: "rph" o Specification Document(s): Section 3 of [RFCThis] 6.2. PASSporT 'rph' Types This document requests that the IANA add a new entry to the PASSporT Types registry for the type "rph" which is specified in [RFCThis]. There isn't an IANA table called "PASSporT Types." I presume this is the re= gistration we just discussed in section 6.1, and so the above two lines can= be removed. This specification also requests that the IANA create a new registry for PASSporT "rph" types. Registration of new PASSporT "rph" types shall be under the specification required policy. This registry is to be initially populated with a single value for "auth" which is specified in [RFCThis]. This needs to be very clear about the fields to be included in this new reg= istry (e.g., "Registry entries must contain two fields: the name of the 'rp= h' type and the specification in which the type is described"). 7. Security Considerations The security considerations discussed in [I-D.ietf-stir-rfc4474bis] in Section 10 are applicable here. 7.1. Avoidance of replay and cut and paste attacks The PASSporT extension with a "ppt" value of "rph" MUST only be sent with SIP INVITE when 'Resource-Priority' header is used to convey the "...header field..." priority of the communication as defined in [RFC4412]. To avoid the replay, and cut and paste attacks, the procedures described in Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. 7.2. Solution Considerations The use of extension to PASSporT tokens with "ppt" value "rph" based on the validation of the digital signature and the associated certificate requires consideration of the authentication and authority or reputation of the signer to attest to the identity being asserted. The following considerations should be recognized when using PASSporT extension with "ppt" value of "rph": o An authority (signer) is only allowed to sign the content of a SIP 'Resource-Priority' header for which it has the right authority. "...header field..." The authority that signs the token MUST have a secure method for authentication of the end user or the device. o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the SIP It's not clear what authority is being claimed here. Is this supposed to me= an something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource pri= ority namespace in the PASSporT?" Whatever the server is purportedly author= itative for needs to be clearly spelled out. 'Resource-Priority' header. "...header field." /a _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_D3F011C97E234BBF8D9FE7C2776A4317ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi,

I think the reason why =91orig=92 and =91dest=92 are required in every= PASSPorT should be explained the the PASSPorT document, in my opinion. It = is not specific to the RPH extension.

Not sure how =91orig=92 can be used to identify a call. You can have m= ultiple calls with the same =91orig=92 value, can=92t you? 

Regards,

Christer



Sent from my iPhone

On 4 Feb 2018, at 21.45, Singh, Ray P <rsingh@vencorelabs.com> wrote:

All,

Yes, the claim is only for the RPH. The"orig" and "dest&q= uot; is included so that the RPH claim can be correlated to the call. = We can add some clarification text to indicate that "orig" is on= ly included so that the RPH claim can be correlated to a specific call, and that the signer of the RPH claim may no have authority of the "or= ig" TN.

Thanks

Ray

 

 

From: stir [stir-bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135@att.com]
Sent: Sunday, February 04, 2018 7:05 PM
To: Subir; Christer Holmberg
Cc: stir@ietf.org; Adam Roach; = STIR Chairs; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

We only have one claim and that is the RPH<= /p>

 

From: Subir [mailto:subirdas21@gmail.com]
Sent: Sunday, February 04, 2018 5:56 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.= com>; STIR Chairs <stir-c= hairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 


We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to  other = claims such as 'orig' and in other cases it may not have.  We can add = a may statement clarifying this or explicitly say that it is not required to have authority to other claims.

 

Thanks,

 

Subir 
Sent from my iPhone


On Feb 4, 2018, at 10:03 PM, Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:

Hi,

 

The text says:

 

   =93The credentials (e= .g., authority responsible for authorizing Resource-

   Priority) used to cre= ate the signature must have authority over the

   namespace of the &quo= t;rph" claim and there is only one authority per

   claim.=94

 

If the credentials don=92t need to= have authority of the other claims (e.g., =93orig=94) in the RPH PASSPorT = I think you should explicitly say so.

 

Regards,

 

Christer

 

 

From: Subir Das [mailto:subirdas21@gmail.com]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hello Christer,

The signing entity does not have always the authorit= y to assert the caller identity in rph. We are submitting ver-03 draft = ; and it is clarified  as follows:

"The credentials (e.g., autho= rity responsible for authorizing Resource-Priority) used to create the sign= ature must have authority over the namespace of the=93rph" claim.."

 

-Subir

 

On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

 

Another question for clarification= .

 

Section 3 contains the following e= xample:

 

    { "orig&qu= ot;:{"tn":"12155551212"}

     "des= t":{["tn":"12125551213"]},

     "iat= ":1443208345,

     "rph= ":{"auth":["ets.0","wps.0"]}

 

=85and the following text:<= /p>

 

   =93The credentials (e= .g., authority responsible for authorizing Resource-

   Priority) used to cre= ate the signature must have authority over the

   "rph" claim= =85=94

<= span style=3D"FONT-SIZE: 11pt; FONT-FAMILY: "Calibri",sans-serif;= COLOR: #1f497d"> 

Since the claim also contains =93o= rig=94, is the assumption that the signing entity always also has authority= to assert the callers identity? I think it would be good to explicitly mention it.

 

Regards,

 

Christer

 

 

 

 

 

 

From: stir [mailto:stir-bounces@ietf.org= ] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: [stir] AD Review: draft-ietf-stir-rph-02

 

I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who= has worked on this document, and the authors and chairs in particular.

The technical content here looks generally good to me. I'd like to see a= few issues addressed before IETF LC. In short sumary:

  • The validation section n= eeds to add a discussion of how to treat calls when the priority values in = "rph" passports and SIP "Resource-Priority" header fiel= ds aren't 100% identical.
  • The examples need s= ome adjustment.
  • There is a minor po= int of ambiguity in the Security Section, but this should be easy to fix, a= s long as the WG knows what was intended.
  • The IANA actions ne= ed a little bit of adjustment.
  • There are a number = of minor editorial issues to be cleaned up.

Detailed comments on these points are inline in the document below. I've= removed some portions of the document on which I have no comments.

 


Abstract

   This document extends the STIR PASSporT specification to a= llow the

 

"...the Secure Telephone Identity Revisited (STIR) Personal Asserti= on Token (PASSporT) specification defined in RFC 8122..."

(See <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for g= uidance on abbreviations)

 

   inc= lusion of cryptographically-signed assertions of authorization for    the values populated in the SIP 'Resource-Priority' header= field,
   which is used for communications resource prioritization.<= /tt>

...

1.  Introduction

   PASSporT [I-D.ietf-stir-passport] is a token format based = on JWT
   [RFC7519] for conveying cryptographically-signed informati= on about
   the identities involved in personal communications; it is = used with
   STIR [I-D.ietf-stir-rfc4474bis] to convey a signed asserti= on of the
   identity of the participants in real-time communications e= stablished
   via a protocol like SIP.  This specification extends = PASSporT to

 

"...like SIP [RFC3261]..."

(We want to cite SIP the first time it is mentioned)

 

   all= ow cryptographic-signing of the SIP 'Resource-Priority' header<= span style=3D"FONT-SIZE: 10pt; FONT-FAMILY: "Courier New"">
   field defined in [RFC4412].

   [RFC4412] defines the SIP 'Resource-Priority' header field= for
   communications Resource Priority.  As specified in [R= FC4412], the
   'Resource-Priority' header field may be used by SIP user a= gents
   [RFC3261], including, Public Switched Telephone Network (P= STN)

 

"...including Public Switched..."

(remove the comma)

 

   gat= eways and terminals, and SIP proxy servers to influence

 

"...and by SIP proxy servers, to influence..."

(add "by" and comma)

 

   pri= oritization afforded to communication sessions,including PSTN

 

"...sessions, including..."

(space after comma)

 

   cal= ls.  However, the SIP 'Resource-Priority' header field could be= =
   spoofed and abused by unauthorized entities.

   The STIR architecture [RFC7340]assumes that an authority o= n the

 

"...STIR architecture [RFC7340] assumes..."

(space before "assumes")

 

   ori= ginating side of a call provides a cryptographic assurance of the    validity of the calling party number in order to prevent
   impersonation attacks.  The STIR architecture allows = extension that

 

"...allows extensions..."

 

   can= be utilized by authorities supporting real-time communication<= span style=3D"FONT-SIZE: 10pt; FONT-FAMILY: "Courier New"">
   services using the 'Resource-Priority' header field to
   cryptographically sign the SIP 'Resource-Priority' header = field and
   convey assertion of the authorization for 'Resource-Priori= ty'.  For
   example, the authority on the originating side verifying t= he
   authorization of a particular communication for Resource-P= riority can

 

Single quotes around 'Resource-Priority'.

 

   use= a PASSPorT claim to cryptographically-sign the SIP 'Resource-<= /p>

 

"...cryptographically sign..."

 

   Pri= ority' header field and convey an assertion of the authorization
   for 'Resource-Priority'.  This will allow a receiving= entity
   (including entities located in different network domains/b= oundaries)
   to verify the validity of assertions authorizing Resource-= Priority.

 

Single quotes around 'Resource-Priority'.

 

   Cry= ptographically-signed SIP 'Resource-Priority' headers will allow a

 

"...cryptographically signed SIP 'Resource-Priority' header fields.= .."

(remove hyphen, and replace "headers" with "header fields= ")

 

   rec= eiving entity to verify and act on the information with confidence    that the information have not been spoofed or compromised.=

 

"...has not been spoofed or compromised."

 


   This specification documents an optional extension to PASS= porT and
   the associated STIR mechanisms to provide a function to si= gn the SIP
   'Resource-Priority' header field.  This PASSporT obje= ct is used to
   provide attestation of a calling user authorization for pr= iority
   communications.  This is necessary in addition to the= PASSporT object
   that is used for calling user telephone number attestation= .  How the
   optional extension to PASSporT is used for real-time commu= nications
   supported using SIP 'Resource-Priority' header field is de= fined in
   other documents and is outside the scope of this document.=

 

I assume these other documents are under development? If so, they should= be cited here.

 


2.  Terminology

   The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [R= FC2119].

 

This document has several non-normative uses of "must", "= should," and "may," and so it needs to use the RFC8174 boile= rplate instead of the RFC2119 boilerplate.

 


3.  PASSporT 'rph' Claim

   This specification defines a new JSON Web Token claim for = "rph",
   which provides an assertion for information in SIP 'Resour= ce-
   Priority'header.

 

"...Priority' header field."

(space after closing quotation mark, "header field" instead of= "header")

 


   The creator of a PASSporT object adds a "ppt" va= lue of "rph" to the
   header of a PASSporT object, in which case the PASSporT cl= aims MUST
   contain a "rph" claim, and any entities verifyin= g the PASSporT object
   will be required to understand the "ppt" extensi= on in order to
   process the PASSporT in question.  A PASSPorT header = with the "ppt"
   included will look as follows:

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.examp= le.org/cert.cer"}

 

Ideally, this would be either pretty-printed or canonicalized. Since it'= s too long to fit on a line in canonical form, I propose:

{
  "typ":"passport",
  "ppt":"rph",
  "alg":"ES256",
  "x5u":"https://www.example.org/cert.cer&qu= ot;
}

 


   The "rph" claim will provide an assertion of aut= horization,"auth",

 

"...authorization, "auth", ..."

(space between comma and opening quotation mark)

 

   for= information in the SIP "Resource-Priority" header field (i.e.,
   Resource-Priority: namespace "." r-priority) bas= ed on [RFC4412].

 

The use of the string 'namespace "." r-priority' here and else= where in the document has a detrimental impact on readability. I strongly s= uggest replacing it with "r-value" (the name of this production i= n RFC4412) everywhere.

 

   Spe= cifically, the "rph" claim includes assertion of the priority-
   level of the user to be used for a given communication ses= sion.  The
   value of the "rph" claim is an array containing = one or more of JSON
   objects for the content of the SIP 'Resource-Priority' hea= der that is
   being asserted of which one of the "rph" object,= is mandatory.

 

This last sentence is very hard to parse; and (based on the example) the= value is intended to be a JSON Object (curly braces) rather than a JSON Ar= ray (square braces). I suggest: 'The value of the "rph" claim is = an Object with one or more keys. Each key is associated with a JSON Array. These arrays contain Strings that corresp= ond to the r-values indicated in the SIP "Resource-Priority" head= er field.' (note: "header field", not "header")

 


   The following is an example "rph" claim for a SI= P "Resource-Priority"
   header field with a "namespace "." r-priori= ty" value of "ets.0" and
   with a "namespace "." r-priority" valu= e of "wps.0".

    { "orig":{"tn":"12155551212"}
     "dest":{["tn":"<= /span>12125551213<= tt>"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0= ","wps.0"]}

 

As above, I recommend pretty-printing this. It's also missing a comma af= ter the "orig" value, and the top-level structure is missing a cl= osing brace. The value for "iat" needs to be enclosed in quotes.<= /p>

The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much= of which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).

Putting all this together, I believe what you want is:

{
  "orig":{"tn":"12155550112"},
  "dest":{["tn":"12125550113"]},
  "iat":"1443208345",
  "rph":{"auth":["ets.0","wps.0= "]}
}

 


   After the header and claims PASSporT objects have been con= structed,
   their signature is generated normally per the guidance in<= /tt>
   [I-D.ietf-stir-passport] using the full form of PASSPorT.&= nbsp; The
   credentials (e.g., authority responsible for authorizing R= esource-
   Priority) used to create the signature must have authority= over the
   "rph" claim and there is only one authority per = claim.  The authority
   MUST use its credentials (i.e., CERT) associated with the = specific
   service supported by the SIP namespace in the claim.<= br>
4.  'rph' in SIP

   This section specifies SIP-specific usage for the "rp= h" claim in
   PASSporT.

4.1.  Authentication Service Behavior

   The Authentication Service will create the "rph"= claim using the
   values discussed in section 3 based on [RFC4412].  Th= e construction
   of "rph" claim follows the steps described in Se= ction 4 of
   [I-D.ietf-stir-rfc4474bis].

   The resulting Identity header for "rph" might lo= ok as follows:

 

"...header field..."

 


   "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUo= wZVhBaU9pSnd
   ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKR= lV6STFO
   aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1Odm= JTOWpaW
   EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjB= iaUk2SW
   pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlN= VEkxTlR
   VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR= 2dpT25z
   aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6= VC8HM6D
   l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXv= s3fslM_
   oos2P2Dyw"; info=3D "https://www.example.= org/cert.cer";alg=3DES2= 56;
   ppt=3D"rph"

 

This example has a number of issues:

  • In the Identity header f= ield, the signed-identity-digest shouldn't be quoted.
  • In the Identity hea= der field, info is enclosed in <> rather than "".
  • In the Identity hea= der field, ppt is a token rather than a quoted string.
  • The signed-identity= -digest header needs to indicate a "typ" of "passport" = rather than JWT, and it needs to include both a "ppt" and "x= 5u" field.
  • The signed-identity= -digest body should contain only the passport claim rather than a JSON obje= ct that itself contains a base64-encoded JWS header concatenated with a cla= im.
  • I believe that, eve= n when the body is included, values in the header and body need to be be ca= nonicalized (i.e., all on one line, no spaces, in alphabetical order, etc.)=

I would also recommend following the convention of indicating that line-= wraps are only for readability, and including the header field name in the = example. Putting all this together, I believe what you want is:

   For example, a Identity= header field for "rph" might look
   as follows (backslashes shown for line folding only):=

   Identity: eyJhbGciOiJFU= zI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \
   iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo= .eyJkZXN0 \
   Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Ii= wib3JpZyI \
   6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wI= iwid3BzLj \
   AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl= -n8MIhoCr \
   18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D<https://www= .example.org/cert.cer \
   >;alg=3DES256;ppt=3Drph

(Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550113, respectively)

 


   A SIP authentication service typically will derive the val= ue of "rph"
   from the 'Resource-Priority' header field based on policy = associated
   with service specific use of the "namespace ".&q= uot; r-priority" values
   based on [RFC4412].  The authentication service deriv= es the value of
   the PASSPorT claim by verifying the authorization for Reso= urce-
   Priority (i.e., verifying a calling user privilege for Res= ource-
   Priority based on its identity) which might be derived fro= m customer
   profile data or from access to external services.

   [RFC4412] allows multiple "namespace "." r-= priority" pairs, either in
   a single SIP Resource-Priority header or across multiple S= IP

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   Res= ource-Priority headers.  However, it is not necessary to sign all

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

   con= tent of a SIP Resource-Priority header or all SIP Resource-

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   Pri= ority headers in a given SIP message.  An authority is only

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

   res= ponsible for signing the content of a SIP Resource-Priority header

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

   for= which it has authority (e.g., a specific "namespace "."
   r-priority").

4.2.  Verification Service Behavior

   [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires tha= t
   specifications defining "ppt" values describe an= y additional verifier
   behavior.  The behavior specified for the "ppt&q= uot; values of "rph" is as
   follows:

   The verification service MUST extract the value associated= with the
   "auth" key in a full form PASSPorT with a "= ppt" value of "rph".  If
   the signature validates, then the verification service can= use the
   value of the "rph" claim as validation that the = calling party is
   authorized for Resource-Priority, which would in turn be u= sed for

 

Single quotes around 'Resource-Priority'.

This text is ambiguous about whether the validation indicates that the c= alling party is authorized to use the priorities indicated in the passport = object, or the values in the SIP 'Resource-Priority' header field; and (tak= en on its face) implies the latter, when the intention here should clearly be the former.

"...authorized for 'Resource-Priority' indicated in the claim. This= value would in turn be used for..."

The text also needs to say something about comparing values in the claim= to values in the 'Resource-Priority' header field, and what a mismatch mig= ht mean. The document says elsewhere that the signature might only cover so= me of the r-values, which makes it entirely possible that the 'Resource-Priority' field might contain more= values than are signed. On the other hand, intermediaries might reasonably= remove r-values as the call is processed. This probably means that those r= emoved priorities should not be used, even if they are present in the passport. It seems reasonable to say= that *typical* processing by a receiving party would be to take the *union= * of all RPH passports that they trust, and *intersect* that with the prior= ities in 'Resource-Priority' header fields to get the actual priority or priorities to be applied to the call = (subject to local policy).

 

   pri= ority treatment in accordance with local policy for the associated    communication service.

   In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4= requires
   "iat" value in "rph" claim to be verif= ied.

   The behavior of a SIP UAs upon receiving an INVITE contain= ing a

 

"...of a SIP UA upon..."

or

"...of SIP UAs upon..."

 

   PAS= SporT object with a "rph" claim will largely remain a matter of
   implementation policy for the specific communication servi= ce.  In
   most cases,implementations would act based on confidence i= n the

 

"...cases, implementations..."

(space after comma)

 

   ver= acity of this information.  The use of the compact form of=

 

Paragraph break before "The".

 

   PAS= SporT is not specified in this document.

5.  Further Information Associated with Resource-Priority

 

Single quotes around 'Resource-Priority'.

 


   There may be additional information about the calling part= y or the
   call that could be relevant to authorization for Resource-= Priority.

 

Single quotes around 'Resource-Priority'.

 

   Thi= s may include information related to the device subscription of=
   the caller, or to any institutions that the caller or devi= ce is
   associated with, or even categories of institutions. = All of these
   data elements would benefit from the secure attestations p= rovided by
   the STIR and PASSporT frameworks.  The specification = of the "rph"
   claim could entail the optional presence of one or more su= ch
   additional information fields.

   A new IANA registry has been defined to hold potential val= ues of the
   "rph" array; see Section 6.2.  The definiti= on of the "rph" claim may
   have one or more such additional information field(s).&nbs= p; Details of
   such "rph" claim to encompass other data element= s are left for future
   version of this specification.

6.  IANA Considerations

6.1.  JSON Web Token Claims Registration

 

I think there's some confusion here. You're registering a PASSporT ppt v= alue, not a new JWT claim. That is to say, you're adding an entry to this t= able:

https://www.iana.org/assignments/passport/passpo= rt.xhtml

Not to this table:

https://www.iana.org/assignments/jwt/jwt.xhtml

You would only use the second table if you had a new key to add to the P= ASSporT header -- this specification does not do that.

This section also needs some introductory text to let the IANA know exac= tly what to do; e.g. "This document registers a new value for the &quo= t;Personal Assertion Token (PASSporT) Extensions" table.


   o  ppt value: "rph"

   o  Specification Document(s): Section 3 of [RFCThis]<= /tt>

6.2.  PASSporT 'rph' Types

   This document requests that the IANA add a new entry to th= e PASSporT
   Types registry for the type "rph" which is speci= fied in [RFCThis].

 

There isn't an IANA table called "PASSporT Types." I presume t= his is the registration we just discussed in section 6.1, and so the above = two lines can be removed.

 

   Thi= s specification also requests that the IANA create a new registry    for PASSporT "rph" types.  Registration of = new PASSporT "rph" types
   shall be under the specification required policy.  Th= is registry is
   to be initially populated with a single value for "au= th" which is
   specified in [RFCThis].

 

This needs to be very clear about the fields to be included in this new = registry (e.g., "Registry entries must contain two fields: the name of= the 'rph' type and the specification in which the type is described")= .

 


7.  Security Considerations

   The security considerations discussed in [I-D.ietf-stir-rf= c4474bis]
   in Section 10 are applicable here.

7.1.  Avoidance of replay and cut and paste attacks

   The PASSporT extension with a "ppt" value of &qu= ot;rph" MUST only be sent
   with SIP INVITE when 'Resource-Priority' header is used to= convey the

 

"...header field..."

 

   pri= ority of the communication as defined in [RFC4412].  To avoid the

  &nbs= p;   The authority that signs the token MUST have a secure method= for
      authentication of the end user or the de= vice.

   o  The verification of the signature MUST include mea= ns of verifying
      that the signer is authoritative for the= signed content of the SIP

 

It's not clear what authority is being claimed here. Is this supposed to= mean something like "...verifying that the signer is authoritative fo= r the originating tn in the PASSporT..."? Or "...authoritative fo= r the resource priority namespace in the PASSporT?" Whatever the server is purportedly authoritative for needs to be clearly s= pelled out.

 

  &nbs= p;   'Resource-Priority' header.

 

"...header field."

 

/a


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 

--_000_D3F011C97E234BBF8D9FE7C2776A4317ericssoncom_-- From nobody Mon Feb 5 07:11:45 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7111242F7 for ; Mon, 5 Feb 2018 07:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=FyvRT5XN; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZbQKwkYq 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 cUH-7t1p1QUW for ; Mon, 5 Feb 2018 07:11:37 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D8B12700F for ; Mon, 5 Feb 2018 07:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517843494; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xGtJDPOP0VHx2Nr5v1sZcrMEezBaCWDsKmfbqf3YXBE=; b=FyvRT5XN9KDfcSXeugnI15BlQTYxsGVIbORzLnw/UZZRxoyLzmgCiTy+hwZ9TZ+R YwHDqXCRqHwsNJVQS3z7GzZBtxwUiCRPdMKhhjw/573JPjZmLjPibuPDfjaeBJVO wEgK/JPMchym5dA+i0FELgLnyoPs5OkNrw3cFaGU48k=; X-AuditID: c1b4fb2d-499ff70000005540-a3-5a787426d785 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.DE.21824.624787A5; Mon, 5 Feb 2018 16:11:34 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 5 Feb 2018 16:11:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u3C7kmAv26iD+Ff+z9JcynLnoSHYNo5ryz7f6FOG588=; b=ZbQKwkYqlvCJzUE9qy4pAikDyooRu5oaMoKv/HmSnpwmUIBe29JvXvBsQwRSfdo9LmhtxCwJIpCpCP677sCoFy00ND/cY1T/EsUvnwqXrhdKTXXj3j19w/egQFwMegDSCxnwlUD5GpoLCtWWNF+R6oaq+GDZPS4fwhgsibK54uA= Received: from VI1PR0701MB2304.eurprd07.prod.outlook.com (10.168.137.135) by VI1PR0701MB2461.eurprd07.prod.outlook.com (10.168.139.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Mon, 5 Feb 2018 15:11:31 +0000 Received: from VI1PR0701MB2304.eurprd07.prod.outlook.com ([fe80::65ff:6b0c:9a8b:9506]) by VI1PR0701MB2304.eurprd07.prod.outlook.com ([fe80::65ff:6b0c:9a8b:9506%17]) with mapi id 15.20.0485.009; Mon, 5 Feb 2018 15:11:31 +0000 From: Julio Martinez-Minguito To: Christer Holmberg , "Singh, Ray P" , "stir@ietf.org" CC: "DOLLY, MARTIN C" , Subir , "Adam Roach" , STIR Chairs , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AQHTnkvrOopoQWMV5E2+hWXM9jEC2qOV6Xow Date: Mon, 5 Feb 2018 15:11:31 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com>, , In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2461; 6:NGJyeQ/OWaMAt/9JEACdvFsASy91LIRl4VypTeKKEPWbXRqKp1LjcSadjf9i0cPRd8NmG3RUCs2AaDlk2hCedWtPUMLtpalyhvfRPZ/ozhnJB0/7jxqxQmEiUMAIHtgXVROIaoCKzSOnE1MajQdtROXHkYS+NiJxUCEVXyT0u0fdl6YIBY8siUA7mxdqP1zf18xZDLhTnFmka4knOctpOW7eWxqNCcoysw+gozbVdtVzIDMLYLzh1NEx6cAv7gG2EKcz2dTDB9DuXZWcwFAX3acJWqf7ALfBuqBS+Vudkmtt6V6tBDAJjbyjQj/89uEtZkcvuxfdUqXaz9TuGIfX02rddfu+gH4SKtWMq6Kewix8veK9NmFcpz3NqYb74Hj8; 5:sNyZrW9tRmVd+01TK95WujYQUiXmybSYv3U5s7BUSyPHPcEycL0t4h+Gx1TUuieu5iYd4HN/MwRhw0XXwV3flFy6evLc0FGsboDzI0hq/Lqd5M9GRRFdS5V3zYyrxLyNgiOFx60TcKZtwA8yJrcXx07CD/f9jR1/IAYd5s9Lyq4=; 24:6WJBU48r+KrVvWhiCY7X2FZKEEH+fjRrCRqCy4hAYLyMPWY52/oYr8SN66Ety2fJm+1D15Y5+B55Cn+kZk7RMsJnyG0l73V6/8cnPKGl/Tk=; 7:3Ko9TjtdIvk+HQ7PniiSK8DuCOsctwWxHskGJYbmGzcVMNplSQA1S1ozTm1OzakNfSMBB6irPeBZgGeES+gurNutUGt1h8BEFrXRJETfOXhCwi8QhUVHODKkK81p4G0in8lKdHe1ee1vh48IGYqCAWH6MZwVSLi8f9ExrOz/2wPeiLDYfGgC81nXFLYdC4asjMSxKQLCYlaTkKUq6cyJgiqysqg0i/FS0ZWGsfeO6ikim05gI3hz+3mvtAvzjusN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b8ed9b3a-3066-45aa-0812-08d56caabd38 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:VI1PR0701MB2461; x-ms-traffictypediagnostic: VI1PR0701MB2461: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(158342451672863)(10436049006162)(192374486261705)(131327999870524)(85827821059158)(97927398514766)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR0701MB2461; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2461; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39380400002)(39860400002)(396003)(346002)(376002)(366004)(54164003)(189003)(199004)(790700001)(3846002)(6116002)(97736004)(6436002)(99286004)(9326002)(93886005)(25786009)(53936002)(2950100002)(4326008)(236005)(5250100002)(2501003)(39060400002)(9686003)(6306002)(54896002)(19609705001)(66066001)(55016002)(16200700003)(53946003)(106356001)(6246003)(33656002)(229853002)(966005)(316002)(74316002)(7736002)(478600001)(5660300001)(26005)(6346003)(59450400001)(6506007)(606006)(14454004)(68736007)(76176011)(110136005)(53546011)(54906003)(102836004)(81156014)(5003630100001)(2906002)(81166006)(575784001)(8676002)(86362001)(3660700001)(8936002)(105586002)(3280700002)(2900100001)(7696005)(959014)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2461; H:VI1PR0701MB2304.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=julio.martinez-minguito@ericsson.com; x-microsoft-antispam-message-info: CaJFbPQt3dm0CPnJYt6e+IoYy5EazwFZ4EDEvekS+/Fz6jI6RjFlXKm61cqe7Fq/KFPMrtVBJqYanVVHqQnmbA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB2304239864FCD877776690D8C7FE0VI1PR0701MB2304_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b8ed9b3a-3066-45aa-0812-08d56caabd38 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 15:11:31.6192 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2461 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA03Se0hTYRQAcL5773bvVoOv5fBgSrVK6KGlFaySsOiPWRZhEbYeOvRW5nSy u3IGiSm9lqWCWj7IR8OkVfZwaQ/L1h/mIxf6h2I5XZqPTJElVuq0tmvQf79zzsf5zvn4GFLa JfBh4hL1rC5RrZELxVRBZM2SAH+9QbXh4uXlileuclphbmglFNber7TC5hgmFQO1VQLF3QfP CEVufQUdSiuHs4qR8nlhN600mX4TysLn/ZRyov2HUJnRZCH3C1XikFhWE3eW1a3fHi0+lf1l UJB0tYk2dLjeoDT0vVtoRCIG8CYofz1IGpGYkeJ3CD73PBLwQQOCO+l2yh1Q2ElA9YtMxFcK CbhVbqP5YADBRFEu7W4mxLug632355QXTkfw6ZvJ05nEXxDMtM1Q7lOLcTwMVE977IU10Djl QryDoTLvpmcsCq8EZ16awG0JjgbbpIN0W4r7SGi7EWFEDCPCoVDWdM6dRtgPen7aPS1J7A1d /SUEvx0G0ysbyVsGw32zAt7LwDSRQ/P2g7aSa4h3Jw2WofO8A8GSMzqf3wtDYw1C9y6A8xHU XHfNX7AOOs3180+phbmZzHk3IygZ9eNdTEJLfgJvX2gb6iX4RkYanLfr6GwUWPjf4Ly1cMXi 9FiCF0FjQT/F59dB6UunkPdaqCgbIf+5pb6P+D9fiuh7SMaxHJdwMnhjIKuLi+E4bWJgIqt/ gv7+uLfV0wG1yDyyw4owg+QLJbExBpVUoD7LpSRYETCk3EuysyNZJZXEqlPOsTptlO6MhuWs aAlDyb0ljWESlRSfVOvZeJZNYnX/qgQj8klDkdm+u8eOphaE12W0NxuOz5lvVRsrarb4O6LK wucWVgW9OUiMXfp5IDN18prXll8RuqX2reObow29EVPM6dbVF5LGbH6zxFx0iOzDoT05T3sy lO/vnzC7ilaJ9EfOL3g37ljgulL5+JihKCtgW3LXZ4lB9cQnNEz28cSKw8XeD7X2fXKKO6UO WkPqOPUfEYEzT20DAAA= Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 15:11:44 -0000 --_000_VI1PR0701MB2304239864FCD877776690D8C7FE0VI1PR0701MB2304_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, If the PASSporT with extension ppt:rph only has authority over the rph clai= m, does it mean that we need another PASSporT in the signaling to claim aut= hority over the 'orig' number? Should there be nested PASSporTs? Regards, Julio From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: den 5 februari 2018 07:38 To: Singh, Ray P Cc: DOLLY, MARTIN C ; Subir ; stir@ie= tf.org; Adam Roach ; STIR Chairs ; = draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hi, I think the reason why 'orig' and 'dest' are required in every PASSPorT sho= uld be explained the the PASSPorT document, in my opinion. It is not specif= ic to the RPH extension. Not sure how 'orig' can be used to identify a call. You can have multiple c= alls with the same 'orig' value, can't you? Regards, Christer Sent from my iPhone On 4 Feb 2018, at 21.45, Singh, Ray P > wrote: All, Yes, the claim is only for the RPH. The"orig" and "dest" is included so tha= t the RPH claim can be correlated to the call. We can add some clarificati= on text to indicate that "orig" is only included so that the RPH claim can = be correlated to a specific call, and that the signer of the RPH claim may = no have authority of the "orig" TN. Thanks Ray ________________________________ From: stir [stir-bounces@ietf.org] on behalf = of DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, February 04, 2018 7:05 PM To: Subir; Christer Holmberg Cc: stir@ietf.org; Adam Roach; STIR Chairs; draft-iet= f-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We only have one claim and that is the RPH From: Subir [mailto:subirdas21@gmail.com] Sent: Sunday, February 04, 2018 5:56 PM To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to other claim= s such as 'orig' and in other cases it may not have. We can add a may stat= ement clarifying this or explicitly say that it is not required to have aut= hority to other claims. Thanks, Subir Sent from my iPhone On Feb 4, 2018, at 10:03 PM, Christer Holmberg > wrote: Hi, The text says: "The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the namespace of the "rph" claim and there is only one authority per claim." If the credentials don't need to have authority of the other claims (e.g., = "orig") in the RPH PASSPorT I think you should explicitly say so. Regards, Christer From: Subir Das [mailto:subirdas21@gmail.com] Sent: 02 February 2018 01:04 To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hello Christer, The signing entity does not have always the authority to assert the caller = identity in rph. We are submitting ver-03 draft and it is clarified as fo= llows: "The credentials (e.g., authority responsible for authorizing Resource-Prio= rity) used to create the signature must have authority over the namespace o= f the"rph" claim.." -Subir On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg > wrote: Hi, Another question for clarification. Section 3 contains the following example: { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} ...and the following text: "The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim..." Since the claim also contains "orig", is the assumption that the signing en= tity always also has authority to assert the callers identity? I think it w= ould be good to explicitly mention it. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On = Behalf Of Adam Roach Sent: 20 January 2018 00:15 To: STIR Chairs >; stir@i= etf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: [stir] AD Review: draft-ietf-stir-rph-02 I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who ha= s worked on this document, and the authors and chairs in particular. The technical content here looks generally good to me. I'd like to see a fe= w issues addressed before IETF LC. In short sumary: * The validation section needs to add a discussion of how to treat call= s when the priority values in "rph" passports and SIP "Resource-Priority" h= eader fields aren't 100% identical. * The examples need some adjustment. * There is a minor point of ambiguity in the Security Section, but this= should be easy to fix, as long as the WG knows what was intended. * The IANA actions need a little bit of adjustment. * There are a number of minor editorial issues to be cleaned up. Detailed comments on these points are inline in the document below. I've re= moved some portions of the document on which I have no comments. Abstract This document extends the STIR PASSporT specification to allow the "...the Secure Telephone Identity Revisited (STIR) Personal Assertion Token= (PASSporT) specification defined in RFC 8122..." (See for guidance on abbreviations) inclusion of cryptographically-signed assertions of authorization for the values populated in the SIP 'Resource-Priority' header field, which is used for communications resource prioritization. ... 1. Introduction PASSporT [I-D.ietf-stir-passport] is a token format based on JWT [RFC7519] for conveying cryptographically-signed information about the identities involved in personal communications; it is used with STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to "...like SIP [RFC3261]..." (We want to cite SIP the first time it is mentioned) allow cryptographic-signing of the SIP 'Resource-Priority' header field defined in [RFC4412]. [RFC4412] defines the SIP 'Resource-Priority' header field for communications Resource Priority. As specified in [RFC4412], the 'Resource-Priority' header field may be used by SIP user agents [RFC3261], including, Public Switched Telephone Network (PSTN) "...including Public Switched..." (remove the comma) gateways and terminals, and SIP proxy servers to influence "...and by SIP proxy servers, to influence..." (add "by" and comma) prioritization afforded to communication sessions,including PSTN "...sessions, including..." (space after comma) calls. However, the SIP 'Resource-Priority' header field could be spoofed and abused by unauthorized entities. The STIR architecture [RFC7340]assumes that an authority on the "...STIR architecture [RFC7340] assumes..." (space before "assumes") originating side of a call provides a cryptographic assurance of the validity of the calling party number in order to prevent impersonation attacks. The STIR architecture allows extension that "...allows extensions..." can be utilized by authorities supporting real-time communication services using the 'Resource-Priority' header field to cryptographically sign the SIP 'Resource-Priority' header field and convey assertion of the authorization for 'Resource-Priority'. For example, the authority on the originating side verifying the authorization of a particular communication for Resource-Priority can Single quotes around 'Resource-Priority'. use a PASSPorT claim to cryptographically-sign the SIP 'Resource- "...cryptographically sign..." Priority' header field and convey an assertion of the authorization for 'Resource-Priority'. This will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing Resource-Priority. Single quotes around 'Resource-Priority'. Cryptographically-signed SIP 'Resource-Priority' headers will allow a "...cryptographically signed SIP 'Resource-Priority' header fields..." (remove hyphen, and replace "headers" with "header fields") receiving entity to verify and act on the information with confidence that the information have not been spoofed or compromised. "...has not been spoofed or compromised." This specification documents an optional extension to PASSporT and the associated STIR mechanisms to provide a function to sign the SIP 'Resource-Priority' header field. This PASSporT object is used to provide attestation of a calling user authorization for priority communications. This is necessary in addition to the PASSporT object that is used for calling user telephone number attestation. How the optional extension to PASSporT is used for real-time communications supported using SIP 'Resource-Priority' header field is defined in other documents and is outside the scope of this document. I assume these other documents are under development? If so, they should be= cited here. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document has several non-normative uses of "must", "should," and "may,= " and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boi= lerplate. 3. PASSporT 'rph' Claim This specification defines a new JSON Web Token claim for "rph", which provides an assertion for information in SIP 'Resource- Priority'header. "...Priority' header field." (space after closing quotation mark, "header field" instead of "header") The creator of a PASSporT object adds a "ppt" value of "rph" to the header of a PASSporT object, in which case the PASSporT claims MUST contain a "rph" claim, and any entities verifying the PASSporT object will be required to understand the "ppt" extension in order to process the PASSporT in question. A PASSPorT header with the "ppt" included will look as follows: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer"} Ideally, this would be either pretty-printed or canonicalized. Since it's t= oo long to fit on a line in canonical form, I propose: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer" } The "rph" claim will provide an assertion of authorization,"auth", "...authorization, "auth", ..." (space between comma and opening quotation mark) for information in the SIP "Resource-Priority" header field (i.e., Resource-Priority: namespace "." r-priority) based on [RFC4412]. The use of the string 'namespace "." r-priority' here and elsewhere in the = document has a detrimental impact on readability. I strongly suggest replac= ing it with "r-value" (the name of this production in RFC4412) everywhere. Specifically, the "rph" claim includes assertion of the priority- level of the user to be used for a given communication session. The value of the "rph" claim is an array containing one or more of JSON objects for the content of the SIP 'Resource-Priority' header that is being asserted of which one of the "rph" object, is mandatory. This last sentence is very hard to parse; and (based on the example) the va= lue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object wit= h one or more keys. Each key is associated with a JSON Array. These arrays = contain Strings that correspond to the r-values indicated in the SIP "Resou= rce-Priority" header field.' (note: "header field", not "header") The following is an example "rph" claim for a SIP "Resource-Priority" header field with a "namespace "." r-priority" value of "ets.0" and with a "namespace "." r-priority" value of "wps.0". { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} As above, I recommend pretty-printing this. It's also missing a comma after= the "orig" value, and the top-level structure is missing a closing brace. = The value for "iat" needs to be enclosed in quotes. The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much of= which remains assignable (cf ). Putting all this together, I believe what you want is: { "orig":{"tn":"12155550112"}, "dest":{["tn":"12125550113"]}, "iat":"1443208345", "rph":{"auth":["ets.0","wps.0"]} } After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in [I-D.ietf-stir-passport] using the full form of PASSPorT. The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim and there is only one authority per claim. The authority MUST use its credentials (i.e., CERT) associated with the specific service supported by the SIP namespace in the claim. 4. 'rph' in SIP This section specifies SIP-specific usage for the "rph" claim in PASSporT. 4.1. Authentication Service Behavior The Authentication Service will create the "rph" claim using the values discussed in section 3 based on [RFC4412]. The construction of "rph" claim follows the steps described in Section 4 of [I-D.ietf-stir-rfc4474bis]. The resulting Identity header for "rph" might look as follows: "...header field..." "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256; ppt=3D"rph" This example has a number of issues: * In the Identity header field, the signed-identity-digest shouldn't be= quoted. * In the Identity header field, info is enclosed in <> rather than "". * In the Identity header field, ppt is a token rather than a quoted str= ing. * The signed-identity-digest header needs to indicate a "typ" of "passp= ort" rather than JWT, and it needs to include both a "ppt" and "x5u" field. * The signed-identity-digest body should contain only the passport clai= m rather than a JSON object that itself contains a base64-encoded JWS heade= r concatenated with a claim. * I believe that, even when the body is included, values in the header = and body need to be be canonicalized (i.e., all on one line, no spaces, in = alphabetical order, etc.) I would also recommend following the convention of indicating that line-wra= ps are only for readability, and including the header field name in the exa= mple. Putting all this together, I believe what you want is: For example, a Identity header field for "rph" might look as follows (backslashes shown for line folding only): Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D \ >;alg=3DES256;ppt=3Drph (Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550= 113, respectively) A SIP authentication service typically will derive the value of "rph" from the 'Resource-Priority' header field based on policy associated with service specific use of the "namespace "." r-priority" values based on [RFC4412]. The authentication service derives the value of the PASSPorT claim by verifying the authorization for Resource- Priority (i.e., verifying a calling user privilege for Resource- Priority based on its identity) which might be derived from customer profile data or from access to external services. [RFC4412] allows multiple "namespace "." r-priority" pairs, either in a single SIP Resource-Priority header or across multiple SIP Single quotes around 'Resource-Priority'. "...header field..." Resource-Priority headers. However, it is not necessary to sign all Single quotes around 'Resource-Priority'. "...header fields..." content of a SIP Resource-Priority header or all SIP Resource- Single quotes around 'Resource-Priority'. "...header field..." Priority headers in a given SIP message. An authority is only Single quotes around 'Resource-Priority'. "...header fields..." responsible for signing the content of a SIP Resource-Priority header Single quotes around 'Resource-Priority'. "...header field..." for which it has authority (e.g., a specific "namespace "." r-priority"). 4.2. Verification Service Behavior [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The behavior specified for the "ppt" values of "rph" is as follows: The verification service MUST extract the value associated with the "auth" key in a full form PASSPorT with a "ppt" value of "rph". If the signature validates, then the verification service can use the value of the "rph" claim as validation that the calling party is authorized for Resource-Priority, which would in turn be used for Single quotes around 'Resource-Priority'. This text is ambiguous about whether the validation indicates that the call= ing party is authorized to use the priorities indicated in the passport obj= ect, or the values in the SIP 'Resource-Priority' header field; and (taken = on its face) implies the latter, when the intention here should clearly be = the former. "...authorized for 'Resource-Priority' indicated in the claim. This value w= ould in turn be used for..." The text also needs to say something about comparing values in the claim to= values in the 'Resource-Priority' header field, and what a mismatch might = mean. The document says elsewhere that the signature might only cover some = of the r-values, which makes it entirely possible that the 'Resource-Priori= ty' field might contain more values than are signed. On the other hand, int= ermediaries might reasonably remove r-values as the call is processed. This= probably means that those removed priorities should not be used, even if t= hey are present in the passport. It seems reasonable to say that *typical* = processing by a receiving party would be to take the *union* of all RPH pas= sports that they trust, and *intersect* that with the priorities in 'Resour= ce-Priority' header fields to get the actual priority or priorities to be a= pplied to the call (subject to local policy). priority treatment in accordance with local policy for the associated communication service. In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires "iat" value in "rph" claim to be verified. The behavior of a SIP UAs upon receiving an INVITE containing a "...of a SIP UA upon..." or "...of SIP UAs upon..." PASSporT object with a "rph" claim will largely remain a matter of implementation policy for the specific communication service. In most cases,implementations would act based on confidence in the "...cases, implementations..." (space after comma) veracity of this information. The use of the compact form of Paragraph break before "The". PASSporT is not specified in this document. 5. Further Information Associated with Resource-Priority Single quotes around 'Resource-Priority'. There may be additional information about the calling party or the call that could be relevant to authorization for Resource-Priority. Single quotes around 'Resource-Priority'. This may include information related to the device subscription of the caller, or to any institutions that the caller or device is associated with, or even categories of institutions. All of these data elements would benefit from the secure attestations provided by the STIR and PASSporT frameworks. The specification of the "rph" claim could entail the optional presence of one or more such additional information fields. A new IANA registry has been defined to hold potential values of the "rph" array; see Section 6.2. The definition of the "rph" claim may have one or more such additional information field(s). Details of such "rph" claim to encompass other data elements are left for future version of this specification. 6. IANA Considerations 6.1. JSON Web Token Claims Registration I think there's some confusion here. You're registering a PASSporT ppt valu= e, not a new JWT claim. That is to say, you're adding an entry to this tabl= e: https://www.iana.org/assignments/passport/passport.xhtml Not to this table: https://www.iana.org/assignments/jwt/jwt.xhtml You would only use the second table if you had a new key to add to the PASS= porT header -- this specification does not do that. This section also needs some introductory text to let the IANA know exactly= what to do; e.g. "This document registers a new value for the "Personal As= sertion Token (PASSporT) Extensions" table. o ppt value: "rph" o Specification Document(s): Section 3 of [RFCThis] 6.2. PASSporT 'rph' Types This document requests that the IANA add a new entry to the PASSporT Types registry for the type "rph" which is specified in [RFCThis]. There isn't an IANA table called "PASSporT Types." I presume this is the re= gistration we just discussed in section 6.1, and so the above two lines can= be removed. This specification also requests that the IANA create a new registry for PASSporT "rph" types. Registration of new PASSporT "rph" types shall be under the specification required policy. This registry is to be initially populated with a single value for "auth" which is specified in [RFCThis]. This needs to be very clear about the fields to be included in this new reg= istry (e.g., "Registry entries must contain two fields: the name of the 'rp= h' type and the specification in which the type is described"). 7. Security Considerations The security considerations discussed in [I-D.ietf-stir-rfc4474bis] in Section 10 are applicable here. 7.1. Avoidance of replay and cut and paste attacks The PASSporT extension with a "ppt" value of "rph" MUST only be sent with SIP INVITE when 'Resource-Priority' header is used to convey the "...header field..." priority of the communication as defined in [RFC4412]. To avoid the replay, and cut and paste attacks, the procedures described in Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. 7.2. Solution Considerations The use of extension to PASSporT tokens with "ppt" value "rph" based on the validation of the digital signature and the associated certificate requires consideration of the authentication and authority or reputation of the signer to attest to the identity being asserted. The following considerations should be recognized when using PASSporT extension with "ppt" value of "rph": o An authority (signer) is only allowed to sign the content of a SIP 'Resource-Priority' header for which it has the right authority. "...header field..." The authority that signs the token MUST have a secure method for authentication of the end user or the device. o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the SIP It's not clear what authority is being claimed here. Is this supposed to me= an something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource pri= ority namespace in the PASSporT?" Whatever the server is purportedly author= itative for needs to be clearly spelled out. 'Resource-Priority' header. "...header field." /a _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_VI1PR0701MB2304239864FCD877776690D8C7FE0VI1PR0701MB2304_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

If the PASSporT with extension ppt:rph only has aut= hority over the rph claim, does it mean that we need another PASSporT in th= e signaling to claim authority over the ‘orig’ number?

Should there be nested PASSporTs?=

 

Regards, Julio

 

From: Christer Holmberg [mailto:chri= ster.holmberg@ericsson.com]
Sent: den 5 februari 2018 07:38
To: Singh, Ray P <rsingh@vencorelabs.com>
Cc: DOLLY, MARTIN C <md3135@att.com>; Subir <subirdas21@gma= il.com>; stir@ietf.org; Adam Roach <adam@nostrum.com>; STIR Chairs= <stir-chairs@ietf.org>; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hi,

 

I think the reason why ‘orig’ and ‘= ;dest’ are required in every PASSPorT should be explained the the PAS= SPorT document, in my opinion. It is not specific to the RPH extension.

 

Not sure how ‘orig’ can be used to ident= ify a call. You can have multiple calls with the same ‘orig’ va= lue, can’t you? 

 

Regards,

 

Christer

 

 

Sent from my iPhone


On 4 Feb 2018, at 21.45, Singh, Ray P <rsingh@vencorelabs.com> wrote:

All,

Yes, the claim is only for the RPH. The"orig" and = "dest" is included so that the RPH claim can be correlated to the= call.  We can add some clarification text to indicate that "orig= " is only included so that the RPH claim can be correlated to a specific cal= l, and that the signer of the RPH claim may no have authority of the "= orig" TN.

Thanks

Ray

 

 

From:<= /span> stir [stir-= bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135@att= .com]
Sent: Sunday, February 04, 2018 7:05 PM
To: Subir; Christer Holmberg
Cc: stir@ietf.org; Adam Roach; = STIR Chairs; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

We only have one claim and that is the = RPH

 =

From: Subir = [mailto:subirdas21@gmail.com]
Sent: Sunday, February 04, 2018 5:56 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.= com>; STIR Chairs <stir-c= hairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 =


We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to  other = claims such as 'orig' and in other cases it may not have.  We can add = a may statement clarifying this or explicitly say that it is not required to have authority to other claims.<= /span>

 =

Thanks,

 =

Subir 
Sent from my iPhone


On Feb 4, 2018, at 10:03 PM, Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:

Hi,

 =

The text says:

 =

   “The credentials (= e.g., authority responsible for authorizing Resource-

   Priority) used to create= the signature must have authority over the

   namespace of the "r= ph" claim and there is only one authority per

   claim.”

 =

If the credentials don’t need t= o have authority of the other claims (e.g., “orig”) in the RPH = PASSPorT I think you should explicitly say so.

 =

Regards,

 =

Christer

 =

 =

From: Subir = Das [mailto:subir= das21@gmail.com]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 =

Hello Christer,

The signing entity does = not have always the authority to assert the caller identity in rph. We are = submitting ver-03 draft  and it is clarified  as follows:

"The credentials (e.g., authorit= y responsible for authorizing Resource-Priority) used to create the signatu= re must have authority over the namespace of the“rph" claim.."

 =

-Subir

 =

On Mon, Jan 22, 2018 at = 3:27 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:<= /o:p>

Hi,

 =

Another question for clarification.

 =

Section 3 contains the following exam= ple:

 =

    { "orig"= :{"tn":"12155551212"}

     "dest&q= uot;:{["tn":"12125551213"]},

     "iat&qu= ot;:1443208345,

     "rph&qu= ot;:{"auth":["ets.0","wps.0"]}

 =

…and the following text:=

 =

   “The credentials (= e.g., authority responsible for authorizing Resource-

   Priority) used to create= the signature must have authority over the

   "rph" claim= 230;”

<= /a> 

Since the claim also contains “= orig”, is the assumption that the signing entity always also has auth= ority to assert the callers identity? I think it would be good to explicitly mention it.

 =

Regards,

 =

Christer

 =

 =

 =

 =

 =

 =

From: stir [= mailto:stir-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org=
Subject: [stir] AD Review: draft-ietf-stir-rph-02

 =

I'm doing my AD review of draft-ietf-stir-rph-02. Thanks= to everyone who has worked on this document, and the authors and chairs in= particular.

The technical content here looks generally good to me. I= 'd like to see a few issues addressed before IETF LC. In short sumary:=

  • The v= alidation section needs to add a discussion of how to treat calls when the = priority values in "rph" passports and SIP "Resource-Priorit= y" header fields aren't 100% identical.
  • The examples need some adjustment.
  • There is a minor point of ambiguity in the Security Section, but= this should be easy to fix, as long as the WG knows what was intended.
  • The IANA actions need a little bit of adjustment.
  • There are a number of minor editorial issues to be cleaned up.

Detailed comments on these points are inline in the docu= ment below. I've removed some portions of the document on which I have no c= omments.

 


Abstract

   This document extends the STIR PASSporT specification to a= llow the

 

"...the Secure Telephone Identity Revisited (STIR) = Personal Assertion Token (PASSporT) specification defined in RFC 8122...&qu= ot;

(See <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for g= uidance on abbreviations)

 

&nb= sp;  inclusion of cryptographically-signed assertions of authorization= for
   the values populated in the SIP 'Resource-Priority' header= field,
   which is used for communications resource prioritization.<= /tt>

...

1.  Introduction

   PASSporT [I-D.ietf-stir-passport] is a token format based = on JWT
   [RFC7519] for conveying cryptographically-signed informati= on about
   the identities involved in personal communications; it is = used with
   STIR [I-D.ietf-stir-rfc4474bis] to convey a signed asserti= on of the
   identity of the participants in real-time communications e= stablished
   via a protocol like SIP.  This specification extends = PASSporT to

 

"...like SIP [RFC3261]..."

(We want to cite SIP the first time it is mentioned)

 

&nb= sp;  allow cryptographic-signing of the SIP 'Resource-Priority' header=
   field defined in [RFC4412].

   [RFC4412] defines the SIP 'Resource-Priority' header field= for
   communications Resource Priority.  As specified in [R= FC4412], the
   'Resource-Priority' header field may be used by SIP user a= gents
   [RFC3261], including, Public Switched Telephone Network (P= STN)

 

"...including Public Switched..."

(remove the comma)

 

&nb= sp;  gateways and terminals, and SIP proxy servers to influence=

 

"...and by SIP proxy servers, to influence..."=

(add "by" and comma)

 

&nb= sp;  prioritization afforded to communication sessions,including PSTN<= /span>

 =

"...sessions, including..."<= /p>

(space after comma)

 

&nb= sp;  calls.  However, the SIP 'Resource-Priority' header field co= uld be
   spoofed and abused by unauthorized entities.

   The STIR architecture [RFC7340]assumes that an authority o= n the

 

"...STIR architecture [RFC7340] assumes..."

(space before "assumes")

 

&nb= sp;  originating side of a call provides a cryptographic assurance of = the
   validity of the calling party number in order to prevent
   impersonation attacks.  The STIR architecture allows = extension that

 

"...allows extensions..."

 

&nb= sp;  can be utilized by authorities supporting real-time communication=
   services using the 'Resource-Priority' header field to
   cryptographically sign the SIP 'Resource-Priority' header = field and
   convey assertion of the authorization for 'Resource-Priori= ty'.  For
   example, the authority on the originating side verifying t= he
   authorization of a particular communication for Resource-P= riority can

 

Single quotes around 'Resource-Priority'.

 

&nb= sp;  use a PASSPorT claim to cryptographically-sign the SIP 'Resource-=

 

"...cryptographically sign..."

 

&nb= sp;  Priority' header field and convey an assertion of the authorizati= on
   for 'Resource-Priority'.  This will allow a receiving= entity
   (including entities located in different network domains/b= oundaries)
   to verify the validity of assertions authorizing Resource-= Priority.

 

Single quotes around 'Resource-Priority'.

 

&nb= sp;  Cryptographically-signed SIP 'Resource-Priority' headers will all= ow a

 

"...cryptographically signed SIP 'Resource-Priority= ' header fields..."

(remove hyphen, and replace "headers" with &qu= ot;header fields")

 

&nb= sp;  receiving entity to verify and act on the information with confid= ence
   that the information have not been spoofed or compromised.=

 

"...has not been spoofed or compromised."=

 


   This specification documents an optional extension to PASS= porT and
   the associated STIR mechanisms to provide a function to si= gn the SIP
   'Resource-Priority' header field.  This PASSporT obje= ct is used to
   provide attestation of a calling user authorization for pr= iority
   communications.  This is necessary in addition to the= PASSporT object
   that is used for calling user telephone number attestation= .  How the
   optional extension to PASSporT is used for real-time commu= nications
   supported using SIP 'Resource-Priority' header field is de= fined in
   other documents and is outside the scope of this document.=

 

I assume these other documents are under development? If= so, they should be cited here.

 


2.  Terminology

   The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [R= FC2119].

 

This document has several non-normative uses of "mu= st", "should," and "may," and so it needs to use t= he RFC8174 boilerplate instead of the RFC2119 boilerplate.

 


3.  PASSporT 'rph' Claim

   This specification defines a new JSON Web Token claim for = "rph",
   which provides an assertion for information in SIP 'Resour= ce-
   Priority'header.

 

"...Priority' header field."=

(space after closing quotation mark, "header field&= quot; instead of "header")

 


   The creator of a PASSporT object adds a "ppt" va= lue of "rph" to the
   header of a PASSporT object, in which case the PASSporT cl= aims MUST
   contain a "rph" claim, and any entities verifyin= g the PASSporT object
   will be required to understand the "ppt" extensi= on in order to
   process the PASSporT in question.  A PASSPorT header = with the "ppt"
   included will look as follows:

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.example.org/cert.cer"}

 

Ideally, this would be either pretty-printed or canonica= lized. Since it's too long to fit on a line in canonical form, I propose:

{
  "typ":"passport",
  "ppt":"rph",
  "alg":"ES256",
  "x5u":"https://www.example.= org/cert.cer"
}

 


   The "rph" claim will provide an assertion of aut= horization,"auth",

 

"...authorization, "auth", ..."=

(space between comma and opening quotation mark)

 

&nb= sp;  for information in the SIP "Resource-Priority" header f= ield (i.e.,
   Resource-Priority: namespace "." r-priority) bas= ed on [RFC4412].<= /p>

 

The use of the string 'namespace "." r-priorit= y' here and elsewhere in the document has a detrimental impact on readabili= ty. I strongly suggest replacing it with "r-value" (the name of this production in RFC4412) everywhere.

 

&nb= sp;  Specifically, the "rph" claim includes assertion of the= priority-
   level of the user to be used for a given communication ses= sion.  The
   value of the "rph" claim is an array containing = one or more of JSON
   objects for the content of the SIP 'Resource-Priority' hea= der that is
   being asserted of which one of the "rph" object,= is mandatory.

 

This last sentence is very hard to parse; and (based on = the example) the value is intended to be a JSON Object (curly braces) rathe= r than a JSON Array (square braces). I suggest: 'The value of the "rph" claim is an Object with one or more keys= . Each key is associated with a JSON Array. These arrays contain Strings th= at correspond to the r-values indicated in the SIP "Resource-Priority&= quot; header field.' (note: "header field", not "header"= ;)

 


   The following is an example "rph" claim for a SI= P "Resource-Priority"
   header field with a "namespace "." r-priori= ty" value of "ets.0" and
   with a "namespace "." r-priority" valu= e of "wps.0".

    { "orig":{"tn":"1= 2155551212"}
     "dest":{["tn":"<= /span>12125551213"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0= ","wps.0"]}

 

As above, I recommend pretty-printing this. It's also mi= ssing a comma after the "orig" value, and the top-level structure= is missing a closing brace. The value for "iat" needs to be enclosed in quotes.

The NANPA has allocated NPA55501xx for example use, not = NPA555xxxx, much of which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).<= /o:p>

Putting all this together, I believe what you want is:

{
  "orig":{"tn":"12155550112"},
  "dest":{["tn":"12125550113"]},<= span style=3D"font-size:10.0pt;font-family:"Courier New";color:bl= ack">
  "iat":"1443208345",
  "rph":{"auth":["ets.0","wps.0= "]}
}

 


   After the header and claims PASSporT objects have been con= structed,
   their signature is generated normally per the guidance in<= /tt>
   [I-D.ietf-stir-passport] using the full form of PASSPorT.&= nbsp; The
   credentials (e.g., authority responsible for authorizing R= esource-
   Priority) used to create the signature must have authority= over the
   "rph" claim and there is only one authority per = claim.  The authority
   MUST use its credentials (i.e., CERT) associated with the = specific
   service supported by the SIP namespace in the claim.<= br>
4.  'rph' in SIP

   This section specifies SIP-specific usage for the "rp= h" claim in
   PASSporT.

4.1.  Authentication Service Behavior

   The Authentication Service will create the "rph"= claim using the
   values discussed in section 3 based on [RFC4412].  Th= e construction
   of "rph" claim follows the steps described in Se= ction 4 of
   [I-D.ietf-stir-rfc4474bis].

   The resulting Identity header for "rph" might lo= ok as follows:

 

"...header field..."

 


   "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUo= wZVhBaU9pSnd
   ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKR= lV6STFO
   aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1Odm= JTOWpaW
   EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjB= iaUk2SW
   pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlN= VEkxTlR
   VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR= 2dpT25z
   aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6= VC8HM6D
   l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXv= s3fslM_
   oos2P2Dyw"; info=3D ;alg=3DES256;
   ppt=3D"rph"

 

This example has a number of issues:

  • In th= e Identity header field, the signed-identity-digest shouldn't be quoted.
  • In the Identity header field, info is enclosed in <> rathe= r than "".
  • In the Identity header field, ppt is a token rather than a quote= d string.
  • The signed-identity-digest header needs to indicate a "typ&= quot; of "passport" rather than JWT, and it needs to include both= a "ppt" and "x5u" field.
  • The signed-identity-digest body should contain only the passport= claim rather than a JSON object that itself contains a base64-encoded JWS = header concatenated with a claim.
  • I believe that, even when the body is included, values in the he= ader and body need to be be canonicalized (i.e., all on one line, no spaces= , in alphabetical order, etc.)

I would also recommend following the convention of indic= ating that line-wraps are only for readability, and including the header fi= eld name in the example. Putting all this together, I believe what you want is:

   For exampl= e, a Identity header field for "rph" might look=
   as follows (backslashes shown for line folding only):=

   Identity: = eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \https://www.example.org/cert.cer \
   >;alg=3DES256;ppt=3Drph

(Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550113, respectively)

 


   A SIP authentication service typically will derive the val= ue of "rph"
   from the 'Resource-Priority' header field based on policy = associated
   with service specific use of the "namespace ".&q= uot; r-priority" values
   based on [RFC4412].  The authentication service deriv= es the value of
   the PASSPorT claim by verifying the authorization for Reso= urce-
   Priority (i.e., verifying a calling user privilege for Res= ource-
   Priority based on its identity) which might be derived fro= m customer
   profile data or from access to external services.

   [RFC4412] allows multiple "namespace "." r-= priority" pairs, either in
   a single SIP Resource-Priority header or across multiple S= IP

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

&nb= sp;  Resource-Priority headers.  However, it is not necessary to = sign all

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

&nb= sp;  content of a SIP Resource-Priority header or all SIP Resource-

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

&nb= sp;  Priority headers in a given SIP message.  An authority is on= ly

 

Single quotes around 'Resource-Priority'.

"...header fields..."

 

&nb= sp;  responsible for signing the content of a SIP Resource-Priority he= ader

 

Single quotes around 'Resource-Priority'.

"...header field..."

 

&nb= sp;  for which it has authority (e.g., a specific "namespace &quo= t;."
   r-priority").

4.2.  Verification Service Behavior

   [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires tha= t
   specifications defining "ppt" values describe an= y additional verifier
   behavior.  The behavior specified for the "ppt&q= uot; values of "rph" is as
   follows:

   The verification service MUST extract the value associated= with the
   "auth" key in a full form PASSPorT with a "= ppt" value of "rph".  If
   the signature validates, then the verification service can= use the
   value of the "rph" claim as validation that the = calling party is
   authorized for Resource-Priority, which would in turn be u= sed for

 =

Single quotes around 'Resource-Priority'.

This text is ambiguous about whether the validation indi= cates that the calling party is authorized to use the priorities indicated = in the passport object, or the values in the SIP 'Resource-Priority' header field; and (taken on its face) implies the = latter, when the intention here should clearly be the former.

"...authorized for 'Resource-Priority' indicated in= the claim. This value would in turn be used for..."=

The text also needs to say something about comparing val= ues in the claim to values in the 'Resource-Priority' header field, and wha= t a mismatch might mean. The document says elsewhere that the signature might only cover some of the r-values, which makes it e= ntirely possible that the 'Resource-Priority' field might contain more valu= es than are signed. On the other hand, intermediaries might reasonably remo= ve r-values as the call is processed. This probably means that those removed priorities should not be used, even= if they are present in the passport. It seems reasonable to say that *typi= cal* processing by a receiving party would be to take the *union* of all RP= H passports that they trust, and *intersect* that with the priorities in 'Resource-Priority' header fields = to get the actual priority or priorities to be applied to the call (subject= to local policy).

 

&nb= sp;  priority treatment in accordance with local policy for the associ= ated
   communication service.

   In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4= requires
   "iat" value in "rph" claim to be verif= ied.

   The behavior of a SIP UAs upon receiving an INVITE contain= ing a

 

"...of a SIP UA upon..."

or

"...of SIP UAs upon..."

 

&nb= sp;  PASSporT object with a "rph" claim will largely remain = a matter of
   implementation policy for the specific communication servi= ce.  In
   most cases,implementations would act based on confidence i= n the

 

"...cases, implementations..."

(space after comma)

 

&nb= sp;  veracity of this information.  The use of the compact form o= f

 

Paragraph break before "The".

 

&nb= sp;  PASSporT is not specified in this document.

5.  Further Information Associated with Resource-Priority

 

Single quotes around 'Resource-Priority'.

 


   There may be additional information about the calling part= y or the
   call that could be relevant to authorization for Resource-= Priority.

 

Single quotes around 'Resource-Priority'.

 

&nb= sp;  This may include information related to the device subscription o= f
   the caller, or to any institutions that the caller or devi= ce is
   associated with, or even categories of institutions. = All of these
   data elements would benefit from the secure attestations p= rovided by
   the STIR and PASSporT frameworks.  The specification = of the "rph"
   claim could entail the optional presence of one or more su= ch
   additional information fields.

   A new IANA registry has been defined to hold potential val= ues of the
   "rph" array; see Section 6.2.  The definiti= on of the "rph" claim may
   have one or more such additional information field(s).&nbs= p; Details of
   such "rph" claim to encompass other data element= s are left for future
   version of this specification.

6.  IANA Considerations

6.1.  JSON Web Token Claims Registration

 

I think there's some confusion here. You're registering = a PASSporT ppt value, not a new JWT claim. That is to say, you're adding an= entry to this table:

https://www.iana.org/assignments= /passport/passport.xhtml

Not to this table:

https://www.iana.org/assignments/jwt/jwt.x= html

You would only use the second table if you had a new key= to add to the PASSporT header -- this specification does not do that.=

This section also needs some introductory text to let th= e IANA know exactly what to do; e.g. "This document registers a new va= lue for the "Personal Assertion Token (PASSporT) Extensions" table.


   o  ppt value: "rph"

   o  Specification Document(s): Section 3 of [RFCThis]<= /tt>

6.2.  PASSporT 'rph' Types

   This document requests that the IANA add a new entry to th= e PASSporT
   Types registry for the type "rph" which is speci= fied in [RFCThis].

 

There isn't an IANA table called "PASSporT Types.&q= uot; I presume this is the registration we just discussed in section 6.1, a= nd so the above two lines can be removed.

 

&nb= sp;  This specification also requests that the IANA create a new regis= try
   for PASSporT "rph" types.  Registration of = new PASSporT "rph" types
   shall be under the specification required policy.  Th= is registry is
   to be initially populated with a single value for "au= th" which is
   specified in [RFCThis].

 

This needs to be very clear about the fields to be inclu= ded in this new registry (e.g., "Registry entries must contain two fie= lds: the name of the 'rph' type and the specification in which the type is described").

 


7.  Security Considerations

   The security considerations discussed in [I-D.ietf-stir-rf= c4474bis]
   in Section 10 are applicable here.

7.1.  Avoidance of replay and cut and paste attacks

   The PASSporT extension with a "ppt" value of &qu= ot;rph" MUST only be sent
   with SIP INVITE when 'Resource-Priority' header is used to= convey the

 

"...header field..."

 

&nb= sp;  priority of the communication as defined in [RFC4412].  To a= void the
   replay, and cut and paste attacks, the procedures describe= d in
   Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followe= d.

7.2.  Solution Considerations

   The use of extension to PASSporT tokens with "ppt&quo= t; value "rph" based
   on the validation of the digital signature and the associa= ted
   certificate requires consideration of the authentication a= nd
   authority or reputation of the signer to attest to the ide= ntity being
   asserted.  The following considerations should be rec= ognized when
   using PASSporT extension with "ppt" value of &qu= ot;rph":

   o  An authority (signer) is only allowed to sign the = content of a SIP
      'Resource-Priority' header for which it = has the right authority.=

 

"...header field..."

 

&nb= sp;     The authority that signs the token MUST have a = secure method for
      authentication of the end user or the de= vice.

   o  The verification of the signature MUST include mea= ns of verifying
      that the signer is authoritative for the= signed content of the SIP

 

It's not clear what authority is being claimed here. Is = this supposed to mean something like "...verifying that the signer is = authoritative for the originating tn in the PASSporT..."? Or "...authoritative for the resource priority namespace in the PASSp= orT?" Whatever the server is purportedly authoritative for needs to be= clearly spelled out.

 

&nb= sp;     'Resource-Priority' header.

 

"...header field."

 

/a


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 =

--_000_VI1PR0701MB2304239864FCD877776690D8C7FE0VI1PR0701MB2304_-- From nobody Mon Feb 5 07:19:47 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E1512D82E for ; Mon, 5 Feb 2018 07:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 SOQprBrMttxw for ; Mon, 5 Feb 2018 07:19:40 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E37C12D810 for ; Mon, 5 Feb 2018 07:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517843977; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7dXDLsI0QzWc8gegxuTHHhE57RZIYgJJwf44BnHffic=; b=cr7oaKC25Zf9cJBQPnf2F+sWYhl5PXp0V20hTb+wQPc6rBB/mjg//D6HNUNcz8rI r53PeG78aMZu6SaoW8XdWZsqdeMMOYpUHb3pvP98I1yKTosf9DwJR5ux9J5u+PtD gqlQGrkYA7aAtH8eQcPnuMCKmbdoHM5kxnY7RHNPTQo=; X-AuditID: c1b4fb3a-35fff700000067b4-df-5a78760954b4 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.A9.26548.906787A5; Mon, 5 Feb 2018 16:19:37 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 5 Feb 2018 16:19:36 +0100 From: Christer Holmberg To: Julio Martinez-Minguito , "Singh, Ray P" , "stir@ietf.org" CC: "DOLLY, MARTIN C" , Subir , "Adam Roach" , STIR Chairs , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AdOTv2oSY/dEf4YfRra4GseuGeXVLAH6TDcAAIWJiHAAEQ/yAAACac0AAAWX2oAACjLjqgAP2WKAAAJOgIA= Date: Mon, 5 Feb 2018 15:19:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C156576@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C156576ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUyM2K7gS5nWUWUwbatUhZ7/i5it1h9/ByT xaEHT9ktzj98yWzxbMd6Vovla7cxWUw5sIzdgd3jZf8cRo+ds+6yeyxZ8pPJY9bOJyweXy5/ ZvNoPrWVOYAtissmJTUnsyy1SN8ugSuj5fZSpoJ/79grHr49x9TA+P8PWxcjJ4eEgIlER9sD li5GLg4hgcOMEjsubIZyFjNKTNjew9jFyMHBJmAh0f1PGyQuItDHKDFz4xR2EIdZ4BGjxJ9L f1hARgkLZEs82/IbzBYRyJE4+esvI4SdJHFnRQsTiM0ioCJxuXMqWA2vgK/EveVHmCC27WKR 2PRjCthNnAKJEm1b7oE1MwqISXw/tQasmVlAXOLWk/lMEHcLSCzZc54ZwhaVePn4HyuErSSx 9vB2Foj6fImnky+xQywTlDg58wnLBEaRWUhGzUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMH HjMhiy9gZF/FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERi7B7f8ttrBePC54yFGAQ5GJR5e /pSKKCHWxLLiytxDjBIczEoivE7Xy6OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zqlWUQJCaQn lqRmp6YWpBbBZJk4OKUaGC2fLhUUW+epvfGfCdNfs/J9v14Fr9EQkpKafvZLa6ygy8FVMubN u1cHeO3r31Ek4qv333BquO4M7SVe/noVPczbPrqdVj1jfmzpG/6Xp3KfVBbln3sjaBfQIHNH RnVzY1NbU0Wuh96KZT8nS66aYLdc6bdlj1dtwvIPh9kDfkb+fFpW5W8+V4mlOCPRUIu5qDgR AMOCoHjZAgAA Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 15:19:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C156576ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Related to this: how does the verifier know what claim(s) in a PASSPorT the= signer had authority to sign? Regards, Christer From: Julio Martinez-Minguito Sent: 05 February 2018 17:12 To: Christer Holmberg ; Singh, Ray P ; stir@ietf.org Cc: DOLLY, MARTIN C ; Subir ; Adam Ro= ach ; STIR Chairs ; draft-ietf-stir= -rph.all@tools.ietf.org Subject: RE: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hi, If the PASSporT with extension ppt:rph only has authority over the rph clai= m, does it mean that we need another PASSporT in the signaling to claim aut= hority over the 'orig' number? Should there be nested PASSporTs? Regards, Julio From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: den 5 februari 2018 07:38 To: Singh, Ray P > Cc: DOLLY, MARTIN C >; Subir >; stir@ietf.org; Adam Roach >; STIR Chairs = >; draft-ietf-stir-rph.al= l@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hi, I think the reason why 'orig' and 'dest' are required in every PASSPorT sho= uld be explained the the PASSPorT document, in my opinion. It is not specif= ic to the RPH extension. Not sure how 'orig' can be used to identify a call. You can have multiple c= alls with the same 'orig' value, can't you? Regards, Christer Sent from my iPhone On 4 Feb 2018, at 21.45, Singh, Ray P > wrote: All, Yes, the claim is only for the RPH. The"orig" and "dest" is included so tha= t the RPH claim can be correlated to the call. We can add some clarificati= on text to indicate that "orig" is only included so that the RPH claim can = be correlated to a specific call, and that the signer of the RPH claim may = no have authority of the "orig" TN. Thanks Ray ________________________________ From: stir [stir-bounces@ietf.org] on behalf = of DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, February 04, 2018 7:05 PM To: Subir; Christer Holmberg Cc: stir@ietf.org; Adam Roach; STIR Chairs; draft-iet= f-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We only have one claim and that is the RPH From: Subir [mailto:subirdas21@gmail.com] Sent: Sunday, February 04, 2018 5:56 PM To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to other claim= s such as 'orig' and in other cases it may not have. We can add a may stat= ement clarifying this or explicitly say that it is not required to have aut= hority to other claims. Thanks, Subir Sent from my iPhone On Feb 4, 2018, at 10:03 PM, Christer Holmberg > wrote: Hi, The text says: "The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the namespace of the "rph" claim and there is only one authority per claim." If the credentials don't need to have authority of the other claims (e.g., = "orig") in the RPH PASSPorT I think you should explicitly say so. Regards, Christer From: Subir Das [mailto:subirdas21@gmail.com] Sent: 02 February 2018 01:04 To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hello Christer, The signing entity does not have always the authority to assert the caller = identity in rph. We are submitting ver-03 draft and it is clarified as fo= llows: "The credentials (e.g., authority responsible for authorizing Resource-Prio= rity) used to create the signature must have authority over the namespace o= f the"rph" claim.." -Subir On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg > wrote: Hi, Another question for clarification. Section 3 contains the following example: { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} ...and the following text: "The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim..." Since the claim also contains "orig", is the assumption that the signing en= tity always also has authority to assert the callers identity? I think it w= ould be good to explicitly mention it. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On = Behalf Of Adam Roach Sent: 20 January 2018 00:15 To: STIR Chairs >; stir@i= etf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: [stir] AD Review: draft-ietf-stir-rph-02 I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who ha= s worked on this document, and the authors and chairs in particular. The technical content here looks generally good to me. I'd like to see a fe= w issues addressed before IETF LC. In short sumary: * The validation section needs to add a discussion of how to treat call= s when the priority values in "rph" passports and SIP "Resource-Priority" h= eader fields aren't 100% identical. * The examples need some adjustment. * There is a minor point of ambiguity in the Security Section, but this= should be easy to fix, as long as the WG knows what was intended. * The IANA actions need a little bit of adjustment. * There are a number of minor editorial issues to be cleaned up. Detailed comments on these points are inline in the document below. I've re= moved some portions of the document on which I have no comments. Abstract This document extends the STIR PASSporT specification to allow the "...the Secure Telephone Identity Revisited (STIR) Personal Assertion Token= (PASSporT) specification defined in RFC 8122..." (See for guidance on abbreviations) inclusion of cryptographically-signed assertions of authorization for the values populated in the SIP 'Resource-Priority' header field, which is used for communications resource prioritization. ... 1. Introduction PASSporT [I-D.ietf-stir-passport] is a token format based on JWT [RFC7519] for conveying cryptographically-signed information about the identities involved in personal communications; it is used with STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to "...like SIP [RFC3261]..." (We want to cite SIP the first time it is mentioned) allow cryptographic-signing of the SIP 'Resource-Priority' header field defined in [RFC4412]. [RFC4412] defines the SIP 'Resource-Priority' header field for communications Resource Priority. As specified in [RFC4412], the 'Resource-Priority' header field may be used by SIP user agents [RFC3261], including, Public Switched Telephone Network (PSTN) "...including Public Switched..." (remove the comma) gateways and terminals, and SIP proxy servers to influence "...and by SIP proxy servers, to influence..." (add "by" and comma) prioritization afforded to communication sessions,including PSTN "...sessions, including..." (space after comma) calls. However, the SIP 'Resource-Priority' header field could be spoofed and abused by unauthorized entities. The STIR architecture [RFC7340]assumes that an authority on the "...STIR architecture [RFC7340] assumes..." (space before "assumes") originating side of a call provides a cryptographic assurance of the validity of the calling party number in order to prevent impersonation attacks. The STIR architecture allows extension that "...allows extensions..." can be utilized by authorities supporting real-time communication services using the 'Resource-Priority' header field to cryptographically sign the SIP 'Resource-Priority' header field and convey assertion of the authorization for 'Resource-Priority'. For example, the authority on the originating side verifying the authorization of a particular communication for Resource-Priority can Single quotes around 'Resource-Priority'. use a PASSPorT claim to cryptographically-sign the SIP 'Resource- "...cryptographically sign..." Priority' header field and convey an assertion of the authorization for 'Resource-Priority'. This will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing Resource-Priority. Single quotes around 'Resource-Priority'. Cryptographically-signed SIP 'Resource-Priority' headers will allow a "...cryptographically signed SIP 'Resource-Priority' header fields..." (remove hyphen, and replace "headers" with "header fields") receiving entity to verify and act on the information with confidence that the information have not been spoofed or compromised. "...has not been spoofed or compromised." This specification documents an optional extension to PASSporT and the associated STIR mechanisms to provide a function to sign the SIP 'Resource-Priority' header field. This PASSporT object is used to provide attestation of a calling user authorization for priority communications. This is necessary in addition to the PASSporT object that is used for calling user telephone number attestation. How the optional extension to PASSporT is used for real-time communications supported using SIP 'Resource-Priority' header field is defined in other documents and is outside the scope of this document. I assume these other documents are under development? If so, they should be= cited here. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document has several non-normative uses of "must", "should," and "may,= " and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boi= lerplate. 3. PASSporT 'rph' Claim This specification defines a new JSON Web Token claim for "rph", which provides an assertion for information in SIP 'Resource- Priority'header. "...Priority' header field." (space after closing quotation mark, "header field" instead of "header") The creator of a PASSporT object adds a "ppt" value of "rph" to the header of a PASSporT object, in which case the PASSporT claims MUST contain a "rph" claim, and any entities verifying the PASSporT object will be required to understand the "ppt" extension in order to process the PASSporT in question. A PASSPorT header with the "ppt" included will look as follows: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer"} Ideally, this would be either pretty-printed or canonicalized. Since it's t= oo long to fit on a line in canonical form, I propose: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer" } The "rph" claim will provide an assertion of authorization,"auth", "...authorization, "auth", ..." (space between comma and opening quotation mark) for information in the SIP "Resource-Priority" header field (i.e., Resource-Priority: namespace "." r-priority) based on [RFC4412]. The use of the string 'namespace "." r-priority' here and elsewhere in the = document has a detrimental impact on readability. I strongly suggest replac= ing it with "r-value" (the name of this production in RFC4412) everywhere. Specifically, the "rph" claim includes assertion of the priority- level of the user to be used for a given communication session. The value of the "rph" claim is an array containing one or more of JSON objects for the content of the SIP 'Resource-Priority' header that is being asserted of which one of the "rph" object, is mandatory. This last sentence is very hard to parse; and (based on the example) the va= lue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object wit= h one or more keys. Each key is associated with a JSON Array. These arrays = contain Strings that correspond to the r-values indicated in the SIP "Resou= rce-Priority" header field.' (note: "header field", not "header") The following is an example "rph" claim for a SIP "Resource-Priority" header field with a "namespace "." r-priority" value of "ets.0" and with a "namespace "." r-priority" value of "wps.0". { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} As above, I recommend pretty-printing this. It's also missing a comma after= the "orig" value, and the top-level structure is missing a closing brace. = The value for "iat" needs to be enclosed in quotes. The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much of= which remains assignable (cf ). Putting all this together, I believe what you want is: { "orig":{"tn":"12155550112"}, "dest":{["tn":"12125550113"]}, "iat":"1443208345", "rph":{"auth":["ets.0","wps.0"]} } After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in [I-D.ietf-stir-passport] using the full form of PASSPorT. The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim and there is only one authority per claim. The authority MUST use its credentials (i.e., CERT) associated with the specific service supported by the SIP namespace in the claim. 4. 'rph' in SIP This section specifies SIP-specific usage for the "rph" claim in PASSporT. 4.1. Authentication Service Behavior The Authentication Service will create the "rph" claim using the values discussed in section 3 based on [RFC4412]. The construction of "rph" claim follows the steps described in Section 4 of [I-D.ietf-stir-rfc4474bis]. The resulting Identity header for "rph" might look as follows: "...header field..." "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256; ppt=3D"rph" This example has a number of issues: * In the Identity header field, the signed-identity-digest shouldn't be= quoted. * In the Identity header field, info is enclosed in <> rather than "". * In the Identity header field, ppt is a token rather than a quoted str= ing. * The signed-identity-digest header needs to indicate a "typ" of "passp= ort" rather than JWT, and it needs to include both a "ppt" and "x5u" field. * The signed-identity-digest body should contain only the passport clai= m rather than a JSON object that itself contains a base64-encoded JWS heade= r concatenated with a claim. * I believe that, even when the body is included, values in the header = and body need to be be canonicalized (i.e., all on one line, no spaces, in = alphabetical order, etc.) I would also recommend following the convention of indicating that line-wra= ps are only for readability, and including the header field name in the exa= mple. Putting all this together, I believe what you want is: For example, a Identity header field for "rph" might look as follows (backslashes shown for line folding only): Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D \ >;alg=3DES256;ppt=3Drph (Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550= 113, respectively) A SIP authentication service typically will derive the value of "rph" from the 'Resource-Priority' header field based on policy associated with service specific use of the "namespace "." r-priority" values based on [RFC4412]. The authentication service derives the value of the PASSPorT claim by verifying the authorization for Resource- Priority (i.e., verifying a calling user privilege for Resource- Priority based on its identity) which might be derived from customer profile data or from access to external services. [RFC4412] allows multiple "namespace "." r-priority" pairs, either in a single SIP Resource-Priority header or across multiple SIP Single quotes around 'Resource-Priority'. "...header field..." Resource-Priority headers. However, it is not necessary to sign all Single quotes around 'Resource-Priority'. "...header fields..." content of a SIP Resource-Priority header or all SIP Resource- Single quotes around 'Resource-Priority'. "...header field..." Priority headers in a given SIP message. An authority is only Single quotes around 'Resource-Priority'. "...header fields..." responsible for signing the content of a SIP Resource-Priority header Single quotes around 'Resource-Priority'. "...header field..." for which it has authority (e.g., a specific "namespace "." r-priority"). 4.2. Verification Service Behavior [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The behavior specified for the "ppt" values of "rph" is as follows: The verification service MUST extract the value associated with the "auth" key in a full form PASSPorT with a "ppt" value of "rph". If the signature validates, then the verification service can use the value of the "rph" claim as validation that the calling party is authorized for Resource-Priority, which would in turn be used for Single quotes around 'Resource-Priority'. This text is ambiguous about whether the validation indicates that the call= ing party is authorized to use the priorities indicated in the passport obj= ect, or the values in the SIP 'Resource-Priority' header field; and (taken = on its face) implies the latter, when the intention here should clearly be = the former. "...authorized for 'Resource-Priority' indicated in the claim. This value w= ould in turn be used for..." The text also needs to say something about comparing values in the claim to= values in the 'Resource-Priority' header field, and what a mismatch might = mean. The document says elsewhere that the signature might only cover some = of the r-values, which makes it entirely possible that the 'Resource-Priori= ty' field might contain more values than are signed. On the other hand, int= ermediaries might reasonably remove r-values as the call is processed. This= probably means that those removed priorities should not be used, even if t= hey are present in the passport. It seems reasonable to say that *typical* = processing by a receiving party would be to take the *union* of all RPH pas= sports that they trust, and *intersect* that with the priorities in 'Resour= ce-Priority' header fields to get the actual priority or priorities to be a= pplied to the call (subject to local policy). priority treatment in accordance with local policy for the associated communication service. In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires "iat" value in "rph" claim to be verified. The behavior of a SIP UAs upon receiving an INVITE containing a "...of a SIP UA upon..." or "...of SIP UAs upon..." PASSporT object with a "rph" claim will largely remain a matter of implementation policy for the specific communication service. In most cases,implementations would act based on confidence in the "...cases, implementations..." (space after comma) veracity of this information. The use of the compact form of Paragraph break before "The". PASSporT is not specified in this document. 5. Further Information Associated with Resource-Priority Single quotes around 'Resource-Priority'. There may be additional information about the calling party or the call that could be relevant to authorization for Resource-Priority. Single quotes around 'Resource-Priority'. This may include information related to the device subscription of the caller, or to any institutions that the caller or device is associated with, or even categories of institutions. All of these data elements would benefit from the secure attestations provided by the STIR and PASSporT frameworks. The specification of the "rph" claim could entail the optional presence of one or more such additional information fields. A new IANA registry has been defined to hold potential values of the "rph" array; see Section 6.2. The definition of the "rph" claim may have one or more such additional information field(s). Details of such "rph" claim to encompass other data elements are left for future version of this specification. 6. IANA Considerations 6.1. JSON Web Token Claims Registration I think there's some confusion here. You're registering a PASSporT ppt valu= e, not a new JWT claim. That is to say, you're adding an entry to this tabl= e: https://www.iana.org/assignments/passport/passport.xhtml Not to this table: https://www.iana.org/assignments/jwt/jwt.xhtml You would only use the second table if you had a new key to add to the PASS= porT header -- this specification does not do that. This section also needs some introductory text to let the IANA know exactly= what to do; e.g. "This document registers a new value for the "Personal As= sertion Token (PASSporT) Extensions" table. o ppt value: "rph" o Specification Document(s): Section 3 of [RFCThis] 6.2. PASSporT 'rph' Types This document requests that the IANA add a new entry to the PASSporT Types registry for the type "rph" which is specified in [RFCThis]. There isn't an IANA table called "PASSporT Types." I presume this is the re= gistration we just discussed in section 6.1, and so the above two lines can= be removed. This specification also requests that the IANA create a new registry for PASSporT "rph" types. Registration of new PASSporT "rph" types shall be under the specification required policy. This registry is to be initially populated with a single value for "auth" which is specified in [RFCThis]. This needs to be very clear about the fields to be included in this new reg= istry (e.g., "Registry entries must contain two fields: the name of the 'rp= h' type and the specification in which the type is described"). 7. Security Considerations The security considerations discussed in [I-D.ietf-stir-rfc4474bis] in Section 10 are applicable here. 7.1. Avoidance of replay and cut and paste attacks The PASSporT extension with a "ppt" value of "rph" MUST only be sent with SIP INVITE when 'Resource-Priority' header is used to convey the "...header field..." priority of the communication as defined in [RFC4412]. To avoid the replay, and cut and paste attacks, the procedures described in Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. 7.2. Solution Considerations The use of extension to PASSporT tokens with "ppt" value "rph" based on the validation of the digital signature and the associated certificate requires consideration of the authentication and authority or reputation of the signer to attest to the identity being asserted. The following considerations should be recognized when using PASSporT extension with "ppt" value of "rph": o An authority (signer) is only allowed to sign the content of a SIP 'Resource-Priority' header for which it has the right authority. "...header field..." The authority that signs the token MUST have a secure method for authentication of the end user or the device. o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the SIP It's not clear what authority is being claimed here. Is this supposed to me= an something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource pri= ority namespace in the PASSporT?" Whatever the server is purportedly author= itative for needs to be clearly spelled out. 'Resource-Priority' header. "...header field." /a _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_7594FB04B1934943A5C02806D1A2204B6C156576ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Related to= this: how does the verifier know what claim(s) in a PASSPorT the signer ha= d authority to sign?

 = ;

Regards,

 = ;

Christer

 

From: = Julio Martinez-Minguito
Sent: 05 February 2018 17:12
To: Christer Holmberg <christer.holmberg@ericsson.com>; Singh,= Ray P <rsingh@vencorelabs.com>; stir@ietf.org
Cc: DOLLY, MARTIN C <md3135@att.com>; Subir <subirdas21@gma= il.com>; Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chair= s@ietf.org>; draft-ietf-stir-rph.all@tools.ietf.org
Subject: RE: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hi,

 

If the PASSporT with extension ppt:r= ph only has authority over the rph claim, does it mean that we need another= PASSporT in the signaling to claim authority over the ‘orig’ number?

Should there be nested PASSporTs?

 

Regards, Julio

 

From: = Christer Holmberg [mailto= :christer.holmberg@ericsson.com]
Sent: den 5 februari 2018 07:38
To: Singh, Ray P <rsing= h@vencorelabs.com>
Cc: DOLLY, MARTIN C <md3135@att= .com>; Subir <subirdas21@= gmail.com>; stir@ietf.org; Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hi,

 

I think the reason why ‘o= rig’ and ‘dest’ are required in every PASSPorT should be = explained the the PASSPorT document, in my opinion. It is not specific to t= he RPH extension.

 

Not sure how ‘orig’= can be used to identify a call. You can have multiple calls with the same = ‘orig’ value, can’t you? 

 

Regards,

 

Christer

 

=  

Sent from my iPhone<= /span>

=
On 4 Feb 2018, at 21.45, Singh, Ray P <rsingh@vencorelabs.com> wrote:

All,

Yes, the claim is only for the RPH. The"= orig" and "dest" is included so that the RPH claim can be co= rrelated to the call.  We can add some clarification text to indicate that "orig" is only included so that the RPH claim can be correl= ated to a specific call, and that the signer of the RPH claim may no have a= uthority of the "orig" TN.

Thanks

Ray

 

 

From: stir [stir-bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135@att= .com]
Sent: Sunday, February 04, 2018 7:05 PM
To: Subir; Christer Holmberg
Cc: stir@ietf.org; Adam Roach; = STIR Chairs; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

We only have one claim a= nd that is the RPH

 

From: Subir [mail= to:subirdas21@gmail.com]
Sent: Sunday, February 04, 2018 5:56 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.= com>; STIR Chairs <stir-c= hairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 


We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to  other = claims such as 'orig' and in other cases it may not have.  We can add = a may statement clarifying this or explicitly say that it is not required to have authority to other claims.<= /span>

 

Thanks,

 

Subir&nbs= p;
Sent from my iPhone


On Feb 4, 2018, at 10:03 PM, Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:

Hi,

 

The text says:<= span lang=3D"EN-US" style=3D"color:black">

 

   “Th= e credentials (e.g., authority responsible for authorizing Resource-=

   Priority)= used to create the signature must have authority over the

   namespace= of the "rph" claim and there is only one authority per

   claim.= 221;

 

If the credentials don= ’t need to have authority of the other claims (e.g., “orig̶= 1;) in the RPH PASSPorT I think you should explicitly say so.

 

Regards,

 

Christer

 

 

From: Subir Das [mailto:subirdas21@gmail.com]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hello Chr= ister,

The signi= ng entity does not have always the authority to assert the caller identity = in rph. We are submitting ver-03 draft  and it is clarified  as f= ollows:

"The credentials = (e.g., authority responsible for authorizing Resource-Priority) used to cre= ate the signature must have authority over the namespace of the“rph" claim.."

 

-Subir

 

On Mon, J= an 22, 2018 at 3:27 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:

Hi,

 

Another question for c= larification.<= /span>

 

Section 3 contains the= following example:<= /o:p>

 

    { &= quot;orig":{"tn":"1215555121= 2"}

   &nbs= p; "dest":{["tn":"12125= 551213"]},

   &nbs= p; "iat":1443208345,

   &nbs= p; "rph":{"auth":["ets.0","wps.0"]}=

 

…and the followi= ng text:

 

   “Th= e credentials (e.g., authority responsible for authorizing Resource-=

   Priority)= used to create the signature must have authority over the

   "rph= " claim…”

<= /a> 

Since the claim also c= ontains “orig”, is the assumption that the signing entity alway= s also has authority to assert the callers identity? I think it would be good to explicitly mention it.

 

Regards,

 

Christer

 

 

 

 

 

 

From: stir [mailto:sti= r-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ie= tf.org>; stir@ietf.org; draft-ietf-stir-rph.all= @tools.ietf.org
Subject: [stir] AD Review: draft-ietf-stir-rph-02

 

I'm doing my AD review of dra= ft-ietf-stir-rph-02. Thanks to everyone who has worked on this document, an= d the authors and chairs in particular.

The technical content here lo= oks generally good to me. I'd like to see a few issues addressed before IET= F LC. In short sumary:

  • The validation section needs to add a discussion of how to = treat calls when the priority values in "rph" passports and SIP &= quot;Resource-Priority" header fields aren't 100% identical.
  • The examples need some adjustment.
  • There is a minor point of ambiguity = in the Security Section, but this should be easy to fix, as long as the WG = knows what was intended.
  • The IANA actions need a little bit o= f adjustment.
  • There are a number of minor editoria= l issues to be cleaned up.

Detailed comments on these po= ints are inline in the document below. I've removed some portions of the do= cument on which I have no comments.

 


Abstract

   This document extends the STIR PASSporT specification to a= llow the<= /span>

 

"...the Secure Telephone= Identity Revisited (STIR) Personal Assertion Token (PASSporT) specificatio= n defined in RFC 8122..."

(See <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for g= uidance on abbreviations)

 

   inclusion of cryptographically-signed assertions o= f authorization for
   the values populated in the SIP 'Resource-Priority' header= field,
   which is used for communications resource prioritization.<= /tt>

...

1.  Introduction

   PASSporT [I-D.ietf-stir-passport] is a token format based = on JWT
   [RFC7519] for conveying cryptographically-signed informati= on about
   the identities involved in personal communications; it is = used with
   STIR [I-D.ietf-stir-rfc4474bis] to convey a signed asserti= on of the
   identity of the participants in real-time communications e= stablished
   via a protocol like SIP.  This specification extends = PASSporT to

 

"...like SIP [RFC3261]..= ."

(We want to cite SIP the firs= t time it is mentioned)

 

   allow cryptographic-signing of the SIP 'Resource-P= riority' header
   field defined in [RFC4412].

   [RFC4412] defines the SIP 'Resource-Priority' header field= for
   communications Resource Priority.  As specified in [R= FC4412], the
   'Resource-Priority' header field may be used by SIP user a= gents
   [RFC3261], including, Public Switched Telephone Network (P= STN)

 

"...including Public Swi= tched..."

(remove the comma)=

 

   gateways and terminals, and SIP proxy servers to i= nfluence<= /span>

 

"...and by SIP proxy ser= vers, to influence..."

(add "by" and comma= )

 

   prioritization afforded to communication sessions,= including PSTN<= /o:p>

 

"...sessions, including.= .."

(space after comma)

 

   calls.  However, the SIP 'Resource-Priority' = header field could be
   spoofed and abused by unauthorized entities.

   The STIR architecture [RFC7340]assumes that an authority o= n the

 

"...STIR architecture [R= FC7340] assumes..."

(space before "assumes&q= uot;)

 

   originating side of a call provides a cryptographi= c assurance of the
   validity of the calling party number in order to prevent
   impersonation attacks.  The STIR architecture allows = extension that<= /o:p>

 

"...allows extensions...= "

 

   can be utilized by authorities supporting real-tim= e communication
   services using the 'Resource-Priority' header field to
   cryptographically sign the SIP 'Resource-Priority' header = field and
   convey assertion of the authorization for 'Resource-Priori= ty'.  For
   example, the authority on the originating side verifying t= he
   authorization of a particular communication for Resource-P= riority can

 

Single quotes around 'Resourc= e-Priority'.

 

   use a PASSPorT claim to cryptographically-sign the= SIP 'Resource-=

 

"...cryptographically si= gn..."

 

   Priority' header field and convey an assertion of = the authorization
   for 'Resource-Priority'.  This will allow a receiving= entity
   (including entities located in different network domains/b= oundaries)
   to verify the validity of assertions authorizing Resource-= Priority.=

 

Single quotes around 'Resourc= e-Priority'.

 

   Cryptographically-signed SIP 'Resource-Priority' h= eaders will allow a<= o:p>

 

"...cryptographically si= gned SIP 'Resource-Priority' header fields..."

(remove hyphen, and replace &= quot;headers" with "header fields")

 

   receiving entity to verify and act on the informat= ion with confidence
   that the information have not been spoofed or compromised.=

 

"...has not been spoofed= or compromised."

 


   This specification documents an optional extension to PASS= porT and
   the associated STIR mechanisms to provide a function to si= gn the SIP
   'Resource-Priority' header field.  This PASSporT obje= ct is used to
   provide attestation of a calling user authorization for pr= iority
   communications.  This is necessary in addition to the= PASSporT object
   that is used for calling user telephone number attestation= .  How the
   optional extension to PASSporT is used for real-time commu= nications
   supported using SIP 'Resource-Priority' header field is de= fined in
   other documents and is outside the scope of this document.=

 

I assume these other document= s are under development? If so, they should be cited here.

 


2.  Terminology

   The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [R= FC2119].<= /span>

 

This document has several non= -normative uses of "must", "should," and "may,&quo= t; and so it needs to use the RFC8174 boilerplate instead of the RFC2119 bo= ilerplate.

 


3.  PASSporT 'rph' Claim

   This specification defines a new JSON Web Token claim for = "rph",
   which provides an assertion for information in SIP 'Resour= ce-
   Priority'header.

 

"...Priority' header fie= ld."

(space after closing quotatio= n mark, "header field" instead of "header")<= /span>

 


   The creator of a PASSporT object adds a "ppt" va= lue of "rph" to the
   header of a PASSporT object, in which case the PASSporT cl= aims MUST
   contain a "rph" claim, and any entities verifyin= g the PASSporT object
   will be required to understand the "ppt" extensi= on in order to
   process the PASSporT in question.  A PASSPorT header = with the "ppt"
   included will look as follows:

   {  "typ":"passport",
     "ppt":"rph",
     "alg":"ES256",
     "x5u":"https://www.example.org/cert.cer"<= /span>}

 

Ideally, this would be either= pretty-printed or canonicalized. Since it's too long to fit on a line in c= anonical form, I propose:

{=
  "typ":"passport",
  "ppt":"rph",
  "alg":"ES256",
  "x5u":
}

 


   The "rph" claim will provide an assertion of aut= horization,"auth",

 

"...authorization, "= ;auth", ..."

(space between comma and open= ing quotation mark)

 

   for information in the SIP "Resource-Priority= " header field (i.e.,
   Resource-Priority: namespace "." r-priority) bas= ed on [RFC4412].

 

The use of the string 'namesp= ace "." r-priority' here and elsewhere in the document has a detr= imental impact on readability. I strongly suggest replacing it with "r= -value" (the name of this production in RFC4412) everywhere.

 

   Specifically, the "rph" claim includes a= ssertion of the priority-
   level of the user to be used for a given communication ses= sion.  The
   value of the "rph" claim is an array containing = one or more of JSON
   objects for the content of the SIP 'Resource-Priority' hea= der that is
   being asserted of which one of the "rph" object,= is mandatory.<= /o:p>

 

This last sentence is very ha= rd to parse; and (based on the example) the value is intended to be a JSON = Object (curly braces) rather than a JSON Array (square braces). I suggest: = 'The value of the "rph" claim is an Object with one or more keys. Each key is associated with a JSON Array. Th= ese arrays contain Strings that correspond to the r-values indicated in the= SIP "Resource-Priority" header field.' (note: "header field= ", not "header")

 


   The following is an example "rph" claim for a SI= P "Resource-Priority"
   header field with a "namespace "." r-priori= ty" value of "ets.0" and
   with a "namespace "." r-priority" valu= e of "wps.0".

    { "orig":{"tn":"12155551212"}<= br>      "dest":{["tn":"<= /span>12125551213"]},
     "iat":1443208345,
     "rph":{"auth":["ets.0= ","wps.0"]}

 

As above, I recommend pretty-= printing this. It's also missing a comma after the "orig" value, = and the top-level structure is missing a closing brace. The value for "= ;iat" needs to be enclosed in quotes.

The NANPA has allocated NPA55= 501xx for example use, not NPA555xxxx, much of which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).<= /o:p>

Putting all this together, I = believe what you want is:

{=
  "orig":{"tn":"= 12155550112"},
  "dest":{["tn":"12125550113"]},
  "iat":"1443208345",
  "rph":{"auth":["ets.0","wps.0= "]}
}

 


   After the header and claims PASSporT objects have been con= structed,
   their signature is generated normally per the guidance in<= /tt>
   [I-D.ietf-stir-passport] using the full form of PASSPorT.&= nbsp; The
   credentials (e.g., authority responsible for authorizing R= esource-
   Priority) used to create the signature must have authority= over the
   "rph" claim and there is only one authority per = claim.  The authority
   MUST use its credentials (i.e., CERT) associated with the = specific
   service supported by the SIP namespace in the claim.<= br>
4.  'rph' in SIP

   This section specifies SIP-specific usage for the "rp= h" claim in
   PASSporT.

4.1.  Authentication Service Behavior

   The Authentication Service will create the "rph"= claim using the
   values discussed in section 3 based on [RFC4412].  Th= e construction
   of "rph" claim follows the steps described in Se= ction 4 of
   [I-D.ietf-stir-rfc4474bis].

   The resulting Identity header for "rph" might lo= ok as follows:<= /o:p>

 

"...header field..."= ;

 


   "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUo= wZVhBaU9pSnd
   ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKR= lV6STFO
   aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1Odm= JTOWpaW
   EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjB= iaUk2SW
   pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlN= VEkxTlR
   VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR= 2dpT25z
   aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6= VC8HM6D
   l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXv= s3fslM_
   oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3D= ES256;
   ppt=3D"rph"

 

This example has a number of = issues:

  • In the Identity header field, the signed-identity-digest sh= ouldn't be quoted.
  • In the Identity header field, info i= s enclosed in <> rather than "".
  • In the Identity header field, ppt is= a token rather than a quoted string.
  • The signed-identity-digest header ne= eds to indicate a "typ" of "passport" rather than JWT, = and it needs to include both a "ppt" and "x5u" field.
  • The signed-identity-digest body shou= ld contain only the passport claim rather than a JSON object that itself co= ntains a base64-encoded JWS header concatenated with a claim.
  • I believe that, even when the body i= s included, values in the header and body need to be be canonicalized (i.e.= , all on one line, no spaces, in alphabetical order, etc.)

I would also recommend follow= ing the convention of indicating that line-wraps are only for readability, = and including the header field name in the example. Putting all this togeth= er, I believe what you want is:

 &n= bsp; For example, a Identity header field for "rph" might look
   as follows (backslashes shown for line folding only):=

 &n= bsp; Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \<= /span>
   iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo= .eyJkZXN0 \
   Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Ii= wib3JpZyI \
   6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wI= iwid3BzLj \
   AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl= -n8MIhoCr \
   18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D<https://www.example.org/cert.cer \
   >;alg=3DES256;ppt=3Drph

(Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550113, respectively)

 


   A SIP authentication service typically will derive the val= ue of "rph"
   from the 'Resource-Priority' header field based on policy = associated
   with service specific use of the "namespace ".&q= uot; r-priority" values
   based on [RFC4412].  The authentication service deriv= es the value of
   the PASSPorT claim by verifying the authorization for Reso= urce-
   Priority (i.e., verifying a calling user privilege for Res= ource-
   Priority based on its identity) which might be derived fro= m customer
   profile data or from access to external services.

   [RFC4412] allows multiple "namespace "." r-= priority" pairs, either in
   a single SIP Resource-Priority header or across multiple S= IP=

 

Single quotes around 'Resourc= e-Priority'.

"...header field..."= ;

 

   Resource-Priority headers.  However, it is no= t necessary to sign all

 

Single quotes around 'Resourc= e-Priority'.

"...header fields...&quo= t;

 

   content of a SIP Resource-Priority header or all S= IP Resource-

 

Single quotes around 'Resourc= e-Priority'.

"...header field..."= ;

 

   Priority headers in a given SIP message.  An = authority is only

 

Single quotes around 'Resourc= e-Priority'.

"...header fields...&quo= t;

 

   responsible for signing the content of a SIP Resou= rce-Priority header<= o:p>

 

Single quotes around 'Resourc= e-Priority'.

"...header field..."= ;

 

   for which it has authority (e.g., a specific "= ;namespace "."
   r-priority").

4.2.  Verification Service Behavior

   [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires tha= t
   specifications defining "ppt" values describe an= y additional verifier
   behavior.  The behavior specified for the "ppt&q= uot; values of "rph" is as
   follows:

   The verification service MUST extract the value associated= with the
   "auth" key in a full form PASSPorT with a "= ppt" value of "rph".  If
   the signature validates, then the verification service can= use the
   value of the "rph" claim as validation that the = calling party is
   authorized for Resource-Priority, which would in turn be u= sed for

 

Single quotes around 'Resourc= e-Priority'.

This text is ambiguous about = whether the validation indicates that the calling party is authorized to us= e the priorities indicated in the passport object, or the values in the SIP= 'Resource-Priority' header field; and (taken on its face) implies the latter, when the intention here should cle= arly be the former.

"...authorized for 'Reso= urce-Priority' indicated in the claim. This value would in turn be used for= ..."

The text also needs to say so= mething about comparing values in the claim to values in the 'Resource-Prio= rity' header field, and what a mismatch might mean. The document says elsew= here that the signature might only cover some of the r-values, which makes it entirely possible that the 'Resource-= Priority' field might contain more values than are signed. On the other han= d, intermediaries might reasonably remove r-values as the call is processed= . This probably means that those removed priorities should not be used, even if they are present in the pas= sport. It seems reasonable to say that *typical* processing by a receiving = party would be to take the *union* of all RPH passports that they trust, an= d *intersect* that with the priorities in 'Resource-Priority' header fields to get the actual priority or priorit= ies to be applied to the call (subject to local policy).<= /p>

 

   priority treatment in accordance with local policy= for the associated
   communication service.

   In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4= requires
   "iat" value in "rph" claim to be verif= ied.

   The behavior of a SIP UAs upon receiving an INVITE contain= ing a

 

"...of a SIP UA upon...&= quot;

or

"...of SIP UAs upon...&q= uot;

 

   PASSporT object with a "rph" claim will = largely remain a matter of
   implementation policy for the specific communication servi= ce.  In
   most cases,implementations would act based on confidence i= n the

 

"...cases, implementatio= ns..."

(space after comma)

 

   veracity of this information.  The use of the= compact form of

 

Paragraph break before "= The".

 

   PASSporT is not specified in this document.=

5.  Further Information Associated with Resource-Priority

 

Single quotes around 'Resourc= e-Priority'.

 


   There may be additional information about the calling part= y or the
   call that could be relevant to authorization for Resource-= Priority.=

 

Single quotes around 'Resourc= e-Priority'.

 

   This may include information related to the device= subscription of
   the caller, or to any institutions that the caller or devi= ce is
   associated with, or even categories of institutions. = All of these
   data elements would benefit from the secure attestations p= rovided by
   the STIR and PASSporT frameworks.  The specification = of the "rph"
   claim could entail the optional presence of one or more su= ch
   additional information fields.

   A new IANA registry has been defined to hold potential val= ues of the
   "rph" array; see Section 6.2.  The definiti= on of the "rph" claim may
   have one or more such additional information field(s).&nbs= p; Details of
   such "rph" claim to encompass other data element= s are left for future
   version of this specification.

6.  IANA Considerations

6.1.  JSON Web Token Claims Registration

 

I think there's some confusio= n here. You're registering a PASSporT ppt value, not a new JWT claim. That = is to say, you're adding an entry to this table:

https= ://www.iana.org/assignments/passport/passport.xhtml

Not to this table:=

https://www.ian= a.org/assignments/jwt/jwt.xhtml

You would only use the second= table if you had a new key to add to the PASSporT header -- this specifica= tion does not do that.

This section also needs some = introductory text to let the IANA know exactly what to do; e.g. "This = document registers a new value for the "Personal Assertion Token (PASS= porT) Extensions" table.


   o  ppt value: "rph"

   o  Specification Document(s): Section 3 of [RFCThis]<= /tt>

6.2.  PASSporT 'rph' Types

   This document requests that the IANA add a new entry to th= e PASSporT
   Types registry for the type "rph" which is speci= fied in [RFCThis].

 

There isn't an IANA table cal= led "PASSporT Types." I presume this is the registration we just = discussed in section 6.1, and so the above two lines can be removed.

 

   This specification also requests that the IANA cre= ate a new registry
   for PASSporT "rph" types.  Registration of = new PASSporT "rph" types
   shall be under the specification required policy.  Th= is registry is
   to be initially populated with a single value for "au= th" which is
   specified in [RFCThis].

 

This needs to be very clear a= bout the fields to be included in this new registry (e.g., "Registry e= ntries must contain two fields: the name of the 'rph' type and the specific= ation in which the type is described").

 


7.  Security Considerations

   The security considerations discussed in [I-D.ietf-stir-rf= c4474bis]
   in Section 10 are applicable here.

7.1.  Avoidance of replay and cut and paste attacks

   The PASSporT extension with a "ppt" value of &qu= ot;rph" MUST only be sent
   with SIP INVITE when 'Resource-Priority' header is used to= convey the

 

"...header field..."= ;

 

   priority of the communication as defined in [RFC44= 12].  To avoid the
   replay, and cut and paste attacks, the procedures describe= d in
   Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followe= d.

7.2.  Solution Considerations

   The use of extension to PASSporT tokens with "ppt&quo= t; value "rph" based
   on the validation of the digital signature and the associa= ted
   certificate requires consideration of the authentication a= nd
   authority or reputation of the signer to attest to the ide= ntity being
   asserted.  The following considerations should be rec= ognized when
   using PASSporT extension with "ppt" value of &qu= ot;rph":

   o  An authority (signer) is only allowed to sign the = content of a SIP
      'Resource-Priority' header for which it = has the right authority.

 

"...header field..."= ;

 

      The authority that signs the tok= en MUST have a secure method for
      authentication of the end user or the de= vice.

   o  The verification of the signature MUST include mea= ns of verifying
      that the signer is authoritative for the= signed content of the SIP

 

It's not clear what authority= is being claimed here. Is this supposed to mean something like "...ve= rifying that the signer is authoritative for the originating tn in the PASS= porT..."? Or "...authoritative for the resource priority namespace in the PASSporT?" Whatever the server is purported= ly authoritative for needs to be clearly spelled out.

 

      'Resource-Priority' header.

 

"...header field."<= o:p>

 

/a <= /o:p>


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 

--_000_7594FB04B1934943A5C02806D1A2204B6C156576ESESSMB109erics_-- From nobody Mon Feb 5 07:38:42 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A1A126D73; Mon, 5 Feb 2018 07:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 u3eZEyxxWM_2; Mon, 5 Feb 2018 07:38:34 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5AB12D80F; Mon, 5 Feb 2018 07:38:34 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w15FcMAI022880; Mon, 5 Feb 2018 10:38:30 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 2fxqgj39jj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Feb 2018 10:38:28 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w15FcNMU002730; Mon, 5 Feb 2018 10:38:24 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w15Fc8NI002435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Feb 2018 10:38:16 -0500 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 5 Feb 2018 15:37:56 GMT Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id 786B240006C2; Mon, 5 Feb 2018 15:37:56 +0000 (GMT) Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27127.vci.att.com (Service) with ESMTPS id 37B7140002BE; Mon, 5 Feb 2018 15:37:56 +0000 (GMT) Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.35]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0361.001; Mon, 5 Feb 2018 10:37:55 -0500 From: "DOLLY, MARTIN C" To: Julio Martinez-Minguito , "Christer Holmberg" , "Singh, Ray P" , "stir@ietf.org" CC: Subir , Adam Roach , STIR Chairs , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AQHTngtiY/dEf4YfRra4GseuGeXVLKOV6XowgAAIDyA= Date: Mon, 5 Feb 2018 15:37:55 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.225.27] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365668A5B136MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050199 Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 15:38:40 -0000 --_000_E42CCDDA6722744CB241677169E8365668A5B136MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Julio, No. This is because ppt:rph is authenticating/authorizing that this is a pr= iority user with a priority value of x, which is a higher level of authenti= cating/authorization. Where the latter (orig) validates the subscribers use of the TN. Regards, Martin From: Julio Martinez-Minguito [mailto:julio.martinez-minguito@ericsson.com] Sent: Monday, February 05, 2018 10:12 AM To: Christer Holmberg ; Singh, Ray P ; stir@ietf.org Cc: DOLLY, MARTIN C ; Subir ; Adam Ro= ach ; STIR Chairs ; draft-ietf-stir= -rph.all@tools.ietf.org Subject: RE: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hi, If the PASSporT with extension ppt:rph only has authority over the rph clai= m, does it mean that we need another PASSporT in the signaling to claim aut= hority over the 'orig' number? Should there be nested PASSporTs? Regards, Julio From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: den 5 februari 2018 07:38 To: Singh, Ray P > Cc: DOLLY, MARTIN C >; Subir >; stir@ietf.org; Adam Roach >; STIR Chairs = >; draft-ietf-stir-rph.al= l@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hi, I think the reason why 'orig' and 'dest' are required in every PASSPorT sho= uld be explained the the PASSPorT document, in my opinion. It is not specif= ic to the RPH extension. Not sure how 'orig' can be used to identify a call. You can have multiple c= alls with the same 'orig' value, can't you? Regards, Christer Sent from my iPhone On 4 Feb 2018, at 21.45, Singh, Ray P > wrote: All, Yes, the claim is only for the RPH. The"orig" and "dest" is included so tha= t the RPH claim can be correlated to the call. We can add some clarificati= on text to indicate that "orig" is only included so that the RPH claim can = be correlated to a specific call, and that the signer of the RPH claim may = no have authority of the "orig" TN. Thanks Ray ________________________________ From: stir [stir-bounces@ietf.org] on behalf = of DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, February 04, 2018 7:05 PM To: Subir; Christer Holmberg Cc: stir@ietf.org; Adam Roach; STIR Chairs; draft-iet= f-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We only have one claim and that is the RPH From: Subir [mailto:subirdas21@gmail.com] Sent: Sunday, February 04, 2018 5:56 PM To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to other claim= s such as 'orig' and in other cases it may not have. We can add a may stat= ement clarifying this or explicitly say that it is not required to have aut= hority to other claims. Thanks, Subir Sent from my iPhone On Feb 4, 2018, at 10:03 PM, Christer Holmberg > wrote: Hi, The text says: "The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the namespace of the "rph" claim and there is only one authority per claim." If the credentials don't need to have authority of the other claims (e.g., = "orig") in the RPH PASSPorT I think you should explicitly say so. Regards, Christer From: Subir Das [mailto:subirdas21@gmail.com] Sent: 02 February 2018 01:04 To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hello Christer, The signing entity does not have always the authority to assert the caller = identity in rph. We are submitting ver-03 draft and it is clarified as fo= llows: "The credentials (e.g., authority responsible for authorizing Resource-Prio= rity) used to create the signature must have authority over the namespace o= f the"rph" claim.." -Subir On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg > wrote: Hi, Another question for clarification. Section 3 contains the following example: { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} ...and the following text: "The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim..." Since the claim also contains "orig", is the assumption that the signing en= tity always also has authority to assert the callers identity? I think it w= ould be good to explicitly mention it. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On = Behalf Of Adam Roach Sent: 20 January 2018 00:15 To: STIR Chairs >; stir@i= etf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: [stir] AD Review: draft-ietf-stir-rph-02 I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who ha= s worked on this document, and the authors and chairs in particular. The technical content here looks generally good to me. I'd like to see a fe= w issues addressed before IETF LC. In short sumary: * The validation section needs to add a discussion of how to treat call= s when the priority values in "rph" passports and SIP "Resource-Priority" h= eader fields aren't 100% identical. * The examples need some adjustment. * There is a minor point of ambiguity in the Security Section, but this= should be easy to fix, as long as the WG knows what was intended. * The IANA actions need a little bit of adjustment. * There are a number of minor editorial issues to be cleaned up. Detailed comments on these points are inline in the document below. I've re= moved some portions of the document on which I have no comments. Abstract This document extends the STIR PASSporT specification to allow the "...the Secure Telephone Identity Revisited (STIR) Personal Assertion Token= (PASSporT) specification defined in RFC 8122..." (See for guidance on abbreviations) inclusion of cryptographically-signed assertions of authorization for the values populated in the SIP 'Resource-Priority' header field, which is used for communications resource prioritization. ... 1. Introduction PASSporT [I-D.ietf-stir-passport] is a token format based on JWT [RFC7519] for conveying cryptographically-signed information about the identities involved in personal communications; it is used with STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to "...like SIP [RFC3261]..." (We want to cite SIP the first time it is mentioned) allow cryptographic-signing of the SIP 'Resource-Priority' header field defined in [RFC4412]. [RFC4412] defines the SIP 'Resource-Priority' header field for communications Resource Priority. As specified in [RFC4412], the 'Resource-Priority' header field may be used by SIP user agents [RFC3261], including, Public Switched Telephone Network (PSTN) "...including Public Switched..." (remove the comma) gateways and terminals, and SIP proxy servers to influence "...and by SIP proxy servers, to influence..." (add "by" and comma) prioritization afforded to communication sessions,including PSTN "...sessions, including..." (space after comma) calls. However, the SIP 'Resource-Priority' header field could be spoofed and abused by unauthorized entities. The STIR architecture [RFC7340]assumes that an authority on the "...STIR architecture [RFC7340] assumes..." (space before "assumes") originating side of a call provides a cryptographic assurance of the validity of the calling party number in order to prevent impersonation attacks. The STIR architecture allows extension that "...allows extensions..." can be utilized by authorities supporting real-time communication services using the 'Resource-Priority' header field to cryptographically sign the SIP 'Resource-Priority' header field and convey assertion of the authorization for 'Resource-Priority'. For example, the authority on the originating side verifying the authorization of a particular communication for Resource-Priority can Single quotes around 'Resource-Priority'. use a PASSPorT claim to cryptographically-sign the SIP 'Resource- "...cryptographically sign..." Priority' header field and convey an assertion of the authorization for 'Resource-Priority'. This will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing Resource-Priority. Single quotes around 'Resource-Priority'. Cryptographically-signed SIP 'Resource-Priority' headers will allow a "...cryptographically signed SIP 'Resource-Priority' header fields..." (remove hyphen, and replace "headers" with "header fields") receiving entity to verify and act on the information with confidence that the information have not been spoofed or compromised. "...has not been spoofed or compromised." This specification documents an optional extension to PASSporT and the associated STIR mechanisms to provide a function to sign the SIP 'Resource-Priority' header field. This PASSporT object is used to provide attestation of a calling user authorization for priority communications. This is necessary in addition to the PASSporT object that is used for calling user telephone number attestation. How the optional extension to PASSporT is used for real-time communications supported using SIP 'Resource-Priority' header field is defined in other documents and is outside the scope of this document. I assume these other documents are under development? If so, they should be= cited here. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document has several non-normative uses of "must", "should," and "may,= " and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boi= lerplate. 3. PASSporT 'rph' Claim This specification defines a new JSON Web Token claim for "rph", which provides an assertion for information in SIP 'Resource- Priority'header. "...Priority' header field." (space after closing quotation mark, "header field" instead of "header") The creator of a PASSporT object adds a "ppt" value of "rph" to the header of a PASSporT object, in which case the PASSporT claims MUST contain a "rph" claim, and any entities verifying the PASSporT object will be required to understand the "ppt" extension in order to process the PASSporT in question. A PASSPorT header with the "ppt" included will look as follows: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer"} Ideally, this would be either pretty-printed or canonicalized. Since it's t= oo long to fit on a line in canonical form, I propose: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer" } The "rph" claim will provide an assertion of authorization,"auth", "...authorization, "auth", ..." (space between comma and opening quotation mark) for information in the SIP "Resource-Priority" header field (i.e., Resource-Priority: namespace "." r-priority) based on [RFC4412]. The use of the string 'namespace "." r-priority' here and elsewhere in the = document has a detrimental impact on readability. I strongly suggest replac= ing it with "r-value" (the name of this production in RFC4412) everywhere. Specifically, the "rph" claim includes assertion of the priority- level of the user to be used for a given communication session. The value of the "rph" claim is an array containing one or more of JSON objects for the content of the SIP 'Resource-Priority' header that is being asserted of which one of the "rph" object, is mandatory. This last sentence is very hard to parse; and (based on the example) the va= lue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object wit= h one or more keys. Each key is associated with a JSON Array. These arrays = contain Strings that correspond to the r-values indicated in the SIP "Resou= rce-Priority" header field.' (note: "header field", not "header") The following is an example "rph" claim for a SIP "Resource-Priority" header field with a "namespace "." r-priority" value of "ets.0" and with a "namespace "." r-priority" value of "wps.0". { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} As above, I recommend pretty-printing this. It's also missing a comma after= the "orig" value, and the top-level structure is missing a closing brace. = The value for "iat" needs to be enclosed in quotes. The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much of= which remains assignable (cf ). Putting all this together, I believe what you want is: { "orig":{"tn":"12155550112"}, "dest":{["tn":"12125550113"]}, "iat":"1443208345", "rph":{"auth":["ets.0","wps.0"]} } After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in [I-D.ietf-stir-passport] using the full form of PASSPorT. The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim and there is only one authority per claim. The authority MUST use its credentials (i.e., CERT) associated with the specific service supported by the SIP namespace in the claim. 4. 'rph' in SIP This section specifies SIP-specific usage for the "rph" claim in PASSporT. 4.1. Authentication Service Behavior The Authentication Service will create the "rph" claim using the values discussed in section 3 based on [RFC4412]. The construction of "rph" claim follows the steps described in Section 4 of [I-D.ietf-stir-rfc4474bis]. The resulting Identity header for "rph" might look as follows: "...header field..." "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256; ppt=3D"rph" This example has a number of issues: * In the Identity header field, the signed-identity-digest shouldn't be= quoted. * In the Identity header field, info is enclosed in <> rather than "". * In the Identity header field, ppt is a token rather than a quoted str= ing. * The signed-identity-digest header needs to indicate a "typ" of "passp= ort" rather than JWT, and it needs to include both a "ppt" and "x5u" field. * The signed-identity-digest body should contain only the passport clai= m rather than a JSON object that itself contains a base64-encoded JWS heade= r concatenated with a claim. * I believe that, even when the body is included, values in the header = and body need to be be canonicalized (i.e., all on one line, no spaces, in = alphabetical order, etc.) I would also recommend following the convention of indicating that line-wra= ps are only for readability, and including the header field name in the exa= mple. Putting all this together, I believe what you want is: For example, a Identity header field for "rph" might look as follows (backslashes shown for line folding only): Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D \ >;alg=3DES256;ppt=3Drph (Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550= 113, respectively) A SIP authentication service typically will derive the value of "rph" from the 'Resource-Priority' header field based on policy associated with service specific use of the "namespace "." r-priority" values based on [RFC4412]. The authentication service derives the value of the PASSPorT claim by verifying the authorization for Resource- Priority (i.e., verifying a calling user privilege for Resource- Priority based on its identity) which might be derived from customer profile data or from access to external services. [RFC4412] allows multiple "namespace "." r-priority" pairs, either in a single SIP Resource-Priority header or across multiple SIP Single quotes around 'Resource-Priority'. "...header field..." Resource-Priority headers. However, it is not necessary to sign all Single quotes around 'Resource-Priority'. "...header fields..." content of a SIP Resource-Priority header or all SIP Resource- Single quotes around 'Resource-Priority'. "...header field..." Priority headers in a given SIP message. An authority is only Single quotes around 'Resource-Priority'. "...header fields..." responsible for signing the content of a SIP Resource-Priority header Single quotes around 'Resource-Priority'. "...header field..." for which it has authority (e.g., a specific "namespace "." r-priority"). 4.2. Verification Service Behavior [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The behavior specified for the "ppt" values of "rph" is as follows: The verification service MUST extract the value associated with the "auth" key in a full form PASSPorT with a "ppt" value of "rph". If the signature validates, then the verification service can use the value of the "rph" claim as validation that the calling party is authorized for Resource-Priority, which would in turn be used for Single quotes around 'Resource-Priority'. This text is ambiguous about whether the validation indicates that the call= ing party is authorized to use the priorities indicated in the passport obj= ect, or the values in the SIP 'Resource-Priority' header field; and (taken = on its face) implies the latter, when the intention here should clearly be = the former. "...authorized for 'Resource-Priority' indicated in the claim. This value w= ould in turn be used for..." The text also needs to say something about comparing values in the claim to= values in the 'Resource-Priority' header field, and what a mismatch might = mean. The document says elsewhere that the signature might only cover some = of the r-values, which makes it entirely possible that the 'Resource-Priori= ty' field might contain more values than are signed. On the other hand, int= ermediaries might reasonably remove r-values as the call is processed. This= probably means that those removed priorities should not be used, even if t= hey are present in the passport. It seems reasonable to say that *typical* = processing by a receiving party would be to take the *union* of all RPH pas= sports that they trust, and *intersect* that with the priorities in 'Resour= ce-Priority' header fields to get the actual priority or priorities to be a= pplied to the call (subject to local policy). priority treatment in accordance with local policy for the associated communication service. In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires "iat" value in "rph" claim to be verified. The behavior of a SIP UAs upon receiving an INVITE containing a "...of a SIP UA upon..." or "...of SIP UAs upon..." PASSporT object with a "rph" claim will largely remain a matter of implementation policy for the specific communication service. In most cases,implementations would act based on confidence in the "...cases, implementations..." (space after comma) veracity of this information. The use of the compact form of Paragraph break before "The". PASSporT is not specified in this document. 5. Further Information Associated with Resource-Priority Single quotes around 'Resource-Priority'. There may be additional information about the calling party or the call that could be relevant to authorization for Resource-Priority. Single quotes around 'Resource-Priority'. This may include information related to the device subscription of the caller, or to any institutions that the caller or device is associated with, or even categories of institutions. All of these data elements would benefit from the secure attestations provided by the STIR and PASSporT frameworks. The specification of the "rph" claim could entail the optional presence of one or more such additional information fields. A new IANA registry has been defined to hold potential values of the "rph" array; see Section 6.2. The definition of the "rph" claim may have one or more such additional information field(s). Details of such "rph" claim to encompass other data elements are left for future version of this specification. 6. IANA Considerations 6.1. JSON Web Token Claims Registration I think there's some confusion here. You're registering a PASSporT ppt valu= e, not a new JWT claim. That is to say, you're adding an entry to this tabl= e: https://www.iana.org/assignments/passport/passport.xhtml Not to this table: https://www.iana.org/assignments/jwt/jwt.xhtml You would only use the second table if you had a new key to add to the PASS= porT header -- this specification does not do that. This section also needs some introductory text to let the IANA know exactly= what to do; e.g. "This document registers a new value for the "Personal As= sertion Token (PASSporT) Extensions" table. o ppt value: "rph" o Specification Document(s): Section 3 of [RFCThis] 6.2. PASSporT 'rph' Types This document requests that the IANA add a new entry to the PASSporT Types registry for the type "rph" which is specified in [RFCThis]. There isn't an IANA table called "PASSporT Types." I presume this is the re= gistration we just discussed in section 6.1, and so the above two lines can= be removed. This specification also requests that the IANA create a new registry for PASSporT "rph" types. Registration of new PASSporT "rph" types shall be under the specification required policy. This registry is to be initially populated with a single value for "auth" which is specified in [RFCThis]. This needs to be very clear about the fields to be included in this new reg= istry (e.g., "Registry entries must contain two fields: the name of the 'rp= h' type and the specification in which the type is described"). 7. Security Considerations The security considerations discussed in [I-D.ietf-stir-rfc4474bis] in Section 10 are applicable here. 7.1. Avoidance of replay and cut and paste attacks The PASSporT extension with a "ppt" value of "rph" MUST only be sent with SIP INVITE when 'Resource-Priority' header is used to convey the "...header field..." priority of the communication as defined in [RFC4412]. To avoid the replay, and cut and paste attacks, the procedures described in Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. 7.2. Solution Considerations The use of extension to PASSporT tokens with "ppt" value "rph" based on the validation of the digital signature and the associated certificate requires consideration of the authentication and authority or reputation of the signer to attest to the identity being asserted. The following considerations should be recognized when using PASSporT extension with "ppt" value of "rph": o An authority (signer) is only allowed to sign the content of a SIP 'Resource-Priority' header for which it has the right authority. "...header field..." The authority that signs the token MUST have a secure method for authentication of the end user or the device. o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the SIP It's not clear what authority is being claimed here. Is this supposed to me= an something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource pri= ority namespace in the PASSporT?" Whatever the server is purportedly author= itative for needs to be clearly spelled out. 'Resource-Priority' header. "...header field." /a _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_E42CCDDA6722744CB241677169E8365668A5B136MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Julio,

 

No. This is because ppt:rph is authenticating/autho= rizing that this is a priority user with a priority value of x, which is a = higher level of authenticating/authorization.

 

Where the latter (orig) validates the subscribers u= se of the TN.

 

Regards,

 

Martin

 

From: Julio Martinez-Minguito [mailt= o:julio.martinez-minguito@ericsson.com]
Sent: Monday, February 05, 2018 10:12 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>; Singh,= Ray P <rsingh@vencorelabs.com>; stir@ietf.org
Cc: DOLLY, MARTIN C <md3135@att.com>; Subir <subirdas21@gma= il.com>; Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chair= s@ietf.org>; draft-ietf-stir-rph.all@tools.ietf.org
Subject: RE: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hi,

 

If the PASSporT with extension ppt:rph only has aut= hority over the rph claim, does it mean that we need another PASSporT in th= e signaling to claim authority over the ‘orig’ number?

Should there be nested PASSporTs?=

 

Regards, Julio

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.co= m]
Sent: den 5 februari 2018 07:38
To: Singh, Ray P <rsing= h@vencorelabs.com>
Cc: DOLLY, MARTIN C <md3135@att= .com>; Subir <subirdas21@= gmail.com>; stir@ietf.org; Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hi,

 

I think the reason why ‘orig’ and ‘= ;dest’ are required in every PASSPorT should be explained the the PAS= SPorT document, in my opinion. It is not specific to the RPH extension.

 

Not sure how ‘orig’ can be used to ident= ify a call. You can have multiple calls with the same ‘orig’ va= lue, can’t you? 

 

Regards,

 

Christer

 

 

Sent from my iPhone


On 4 Feb 2018, at 21.45, Singh, Ray P <rsingh@vencorelabs.com> wrote:

All,

Yes, the claim is only for the RPH. The"orig" and = "dest" is included so that the RPH claim can be correlated to the= call.  We can add some clarification text to indicate that "orig= " is only included so that the RPH claim can be correlated to a specific cal= l, and that the signer of the RPH claim may no have authority of the "= orig" TN.

Thanks

Ray

 

 

From:<= /span> stir [stir-= bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135@att= .com]
Sent: Sunday, February 04, 2018 7:05 PM
To: Subir; Christer Holmberg
Cc: stir@ietf.org; Adam Roach; = STIR Chairs; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

We only have one claim and that is the = RPH

 =

From: Subir = [mailto:subirdas21@gmail.com]
Sent: Sunday, February 04, 2018 5:56 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.= com>; STIR Chairs <stir-c= hairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 =


We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to  other = claims such as 'orig' and in other cases it may not have.  We can add = a may statement clarifying this or explicitly say that it is not required to have authority to other claims.<= /span>

 =

Thanks,

 =

Subir 
Sent from my iPhone


On Feb 4, 2018, at 10:03 PM, Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:

Hi,

 =

The text says:

 =

   “The credentials (= e.g., authority responsible for authorizing Resource-

   Priority) used to create= the signature must have authority over the

   namespace of the "r= ph" claim and there is only one authority per

   claim.”

 =

If the credentials don’t need t= o have authority of the other claims (e.g., “orig”) in the RPH = PASSPorT I think you should explicitly say so.

 =

Regards,

 =

Christer

 =

 =

From: Subir = Das [mailto:subir= das21@gmail.com]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 =

Hello Christer,

The signing entity does = not have always the authority to assert the caller identity in rph. We are = submitting ver-03 draft  and it is clarified  as follows:

"The credentials (e.g., authorit= y responsible for authorizing Resource-Priority) used to create the signatu= re must have authority over the namespace of the“rph" claim.."

 =

-Subir

 =

On Mon, Jan 22, 2018 at = 3:27 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:<= /o:p>

Hi,

 =

Another question for clarification.

 =

Section 3 contains the following exam= ple:

 =

    { "orig"= :{"tn":"12155551212"}

     "dest&q= uot;:{["tn":"12125551213"]},

     "iat&qu= ot;:1443208345,

     "rph&qu= ot;:{"auth":["ets.0","wps.0"]}

 =

…and the following text:=

 =

   “The credentials (= e.g., authority responsible for authorizing Resource-

   Priority) used to create= the signature must have authority over the

   "rph" claim= 230;”

<= /a> 

Since the claim also contains “= orig”, is the assumption that the signing entity always also has auth= ority to assert the callers identity? I think it would be good to explicitly mention it.

 =

Regards,

 =

Christer

 =

 =

 =

 =

 =

 =

From: stir [= mailto:stir-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org=
Subject: [stir] AD Review: draft-ietf-stir-rph-02

 =

I'm doing my AD review of draft-ietf-stir-rp= h-02. Thanks to everyone who has worked on this document, and the authors a= nd chairs in particular.

The technical content here looks generally g= ood to me. I'd like to see a few issues addressed before IETF LC. In short = sumary:

  • The validation section needs to add a discussion of how to treat calls when= the priority values in "rph" passports and SIP "Resource-Pr= iority" header fields aren't 100% identical.
  • The examples need some adjustment.
  • There is a minor point of ambiguity in the Security Section, but this shoul= d be easy to fix, as long as the WG knows what was intended.
  • The IANA actions need a little bit of adjustment.
  • Detailed comments on these points are inline= in the document below. I've removed some portions of the document on which= I have no comments.

     


    Abstract

       This document extends the STIR PASSporT specification to a= llow the

     

    "...the Secure Telephone Identity Revis= ited (STIR) Personal Assertion Token (PASSporT) specification defined in RF= C 8122..."

    (See <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for g= uidance on abbreviations)

     

    &nb= sp;  inclusion of cryptographically-signed assertions of authorization= for
       the values populated in the SIP 'Resource-Priority' header= field,
       which is used for communications resource prioritization.<= /tt>

    ...

    1.  Introduction

       PASSporT [I-D.ietf-stir-passport] is a token format based = on JWT
       [RFC7519] for conveying cryptographically-signed informati= on about
       the identities involved in personal communications; it is = used with
       STIR [I-D.ietf-stir-rfc4474bis] to convey a signed asserti= on of the
       identity of the participants in real-time communications e= stablished
       via a protocol like SIP.  This specification extends = PASSporT to

     

    "...like SIP [RFC3261]..."

    (We want to cite SIP the first time it is me= ntioned)

     

    &nb= sp;  allow cryptographic-signing of the SIP 'Resource-Priority' header=
       field defined in [RFC4412].

       [RFC4412] defines the SIP 'Resource-Priority' header field= for
       communications Resource Priority.  As specified in [R= FC4412], the
       'Resource-Priority' header field may be used by SIP user a= gents
       [RFC3261], including, Public Switched Telephone Network (P= STN)

     

    "...including Public Switched..."<= o:p>

    (remove the comma)

     

    &nb= sp;  gateways and terminals, and SIP proxy servers to influence=

     

    "...and by SIP proxy servers, to influe= nce..."

    (add "by" and comma)

     

    &nb= sp;  prioritization afforded to communication sessions,including PSTN<= /span>

     =

    "...sessions, including..."

    (space after comma)

     

    &nb= sp;  calls.  However, the SIP 'Resource-Priority' header field co= uld be
       spoofed and abused by unauthorized entities.

       The STIR architecture [RFC7340]assumes that an authority o= n the

     

    "...STIR architecture [RFC7340] assumes= ..."

    (space before "assumes")

     

    &nb= sp;  originating side of a call provides a cryptographic assurance of = the
       validity of the calling party number in order to prevent
       impersonation attacks.  The STIR architecture allows = extension that

     

    "...allows extensions..."

     

    &nb= sp;  can be utilized by authorities supporting real-time communication=
       services using the 'Resource-Priority' header field to
       cryptographically sign the SIP 'Resource-Priority' header = field and
       convey assertion of the authorization for 'Resource-Priori= ty'.  For
       example, the authority on the originating side verifying t= he
       authorization of a particular communication for Resource-P= riority can

     

    Single quotes around 'Resource-Priority'.

     

    &nb= sp;  use a PASSPorT claim to cryptographically-sign the SIP 'Resource-=

     

    "...cryptographically sign..."

     

    &nb= sp;  Priority' header field and convey an assertion of the authorizati= on
       for 'Resource-Priority'.  This will allow a receiving= entity
       (including entities located in different network domains/b= oundaries)
       to verify the validity of assertions authorizing Resource-= Priority.

     

    Single quotes around 'Resource-Priority'.

     

    &nb= sp;  Cryptographically-signed SIP 'Resource-Priority' headers will all= ow a

     

    "...cryptographically signed SIP 'Resou= rce-Priority' header fields..."

    (remove hyphen, and replace "headers&qu= ot; with "header fields")

     

    &nb= sp;  receiving entity to verify and act on the information with confid= ence
       that the information have not been spoofed or compromised.=

     

    "...has not been spoofed or compromised= ."

     


       This specification documents an optional extension to PASS= porT and
       the associated STIR mechanisms to provide a function to si= gn the SIP
       'Resource-Priority' header field.  This PASSporT obje= ct is used to
       provide attestation of a calling user authorization for pr= iority
       communications.  This is necessary in addition to the= PASSporT object
       that is used for calling user telephone number attestation= .  How the
       optional extension to PASSporT is used for real-time commu= nications
       supported using SIP 'Resource-Priority' header field is de= fined in
       other documents and is outside the scope of this document.=

     

    I assume these other documents are under dev= elopment? If so, they should be cited here.

     


    2.  Terminology

       The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in RFC 2119 [R= FC2119].

     

    This document has several non-normative uses= of "must", "should," and "may," and so it ne= eds to use the RFC8174 boilerplate instead of the RFC2119 boilerplate.=

     


    3.  PASSporT 'rph' Claim

       This specification defines a new JSON Web Token claim for = "rph",
       which provides an assertion for information in SIP 'Resour= ce-
       Priority'header.

     

    "...Priority' header field."<= /o:p>

    (space after closing quotation mark, "h= eader field" instead of "header")

     


       The creator of a PASSporT object adds a "ppt" va= lue of "rph" to the
       header of a PASSporT object, in which case the PASSporT cl= aims MUST
       contain a "rph" claim, and any entities verifyin= g the PASSporT object
       will be required to understand the "ppt" extensi= on in order to
       process the PASSporT in question.  A PASSPorT header = with the "ppt"
       included will look as follows:

       {  "typ":"passport",
         "ppt":"rph",
         "alg":"ES256",
         "x5u":    "https://www.example.org/cert.cer"}

     

    Ideally, this would be either pretty-printed= or canonicalized. Since it's too long to fit on a line in canonical form, = I propose:

    {
      "typ":"passport",
      "ppt":"rph",
      "alg":"ES256",
      "x5u":    "https:/= /www.example.org/cert.cer"
    }

     


       The "rph" claim will provide an assertion of aut= horization,"auth",

     

    "...authorization, "auth", ..= ."

    (space between comma and opening quotation m= ark)

     

    &nb= sp;  for information in the SIP "Resource-Priority" header f= ield (i.e.,
       Resource-Priority: namespace "." r-priority) bas= ed on [RFC4412].    <= /p>

     

    The use of the string 'namespace ".&quo= t; r-priority' here and elsewhere in the document has a detrimental impact = on readability. I strongly suggest replacing it with "r-value" (t= he name of this production in RFC4412) everywhere.

     

    &nb= sp;  Specifically, the "rph" claim includes assertion of the= priority-
       level of the user to be used for a given communication ses= sion.  The
       value of the "rph" claim is an array containing = one or more of JSON
       objects for the content of the SIP 'Resource-Priority' hea= der that is
       being asserted of which one of the "rph" object,= is mandatory.

     

    This last sentence is very hard to parse; an= d (based on the example) the value is intended to be a JSON Object (curly b= races) rather than a JSON Array (square braces). I suggest: 'The value of t= he "rph" claim is an Object with one or more keys. Each key is associated with a JSON Array. These arrays conta= in Strings that correspond to the r-values indicated in the SIP "Resou= rce-Priority" header field.' (note: "header field", not &quo= t;header")

     


       The following is an example "rph" claim for a SI= P "Resource-Priority"
       header field with a "namespace "." r-priori= ty" value of "ets.0" and
       with a "namespace "." r-priority" valu= e of "wps.0".

        { "orig":{"tn":"1= 2155551212"}
         "dest":{["tn":"<= /span>12125551213"]},
         "iat":1443208345,
         "rph":{"auth":["ets.0= ","wps.0"]}

     

    As above, I recommend pretty-printing this. = It's also missing a comma after the "orig" value, and the top-lev= el structure is missing a closing brace. The value for "iat" need= s to be enclosed in quotes.

    The NANPA has allocated NPA55501xx for examp= le use, not NPA555xxxx, much of which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).<= /o:p>

    Putting all this together, I believe what yo= u want is:

    {
      "orig":{"tn":"    12155550112"},
      "dest":{["tn":"    12125550113"]},<= /span>
      "iat":"1443208345",
      "rph":{"auth":["ets.0","wps.0= "]}
    }

     


       After the header and claims PASSporT objects have been con= structed,
       their signature is generated normally per the guidance in<= /tt>
       [I-D.ietf-stir-passport] using the full form of PASSPorT.&= nbsp; The
       credentials (e.g., authority responsible for authorizing R= esource-
       Priority) used to create the signature must have authority= over the
       "rph" claim and there is only one authority per = claim.  The authority
       MUST use its credentials (i.e., CERT) associated with the = specific
       service supported by the SIP namespace in the claim.<= br>
    4.  'rph' in SIP

       This section specifies SIP-specific usage for the "rp= h" claim in
       PASSporT.

    4.1.  Authentication Service Behavior

       The Authentication Service will create the "rph"= claim using the
       values discussed in section 3 based on [RFC4412].  Th= e construction
       of "rph" claim follows the steps described in Se= ction 4 of
       [I-D.ietf-stir-rfc4474bis].

       The resulting Identity header for "rph" might lo= ok as follows:

     

    "...header field..."

     


       "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUo= wZVhBaU9pSnd
       ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKR= lV6STFO
       aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1Odm= JTOWpaW
       EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjB= iaUk2SW
       pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlN= VEkxTlR
       VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR= 2dpT25z
       aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6= VC8HM6D
       l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXv= s3fslM_
       oos2P2Dyw"; info=3D     ;alg=3DES256;
       ppt=3D"rph"

     

    This example has a number of issues:

    • In the Identity header field, the signed-identity-digest shouldn't be quote= d.
    • In the Identity header field, info is enclosed in <> rather than &quo= t;".
    • In the Identity header field, ppt is a token rather than a quoted string. <= o:p>
    • The signed-identity-digest header needs to indicate a "typ" of &q= uot;passport" rather than JWT, and it needs to include both a "pp= t" and "x5u" field.
    • The signed-identity-digest body should contain only the passport claim rath= er than a JSON object that itself contains a base64-encoded JWS header conc= atenated with a claim.
    • I believe that, even when the body is included, values in the header and bo= dy need to be be canonicalized (i.e., all on one line, no spaces, in alphab= etical order, etc.)

    I would also recommend following the convent= ion of indicating that line-wraps are only for readability, and including t= he header field name in the example. Putting all this together, I believe w= hat you want is:

       For exampl= e, a Identity header field for "rph" might look=
       as follows (backslashes shown for line folding only):=

       Identity: = eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \https://www.example.org/cert.cer \
       >;alg=3DES256;ppt=3Drph

    (Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550113, respectively)

     


       A SIP authentication service typically will derive the val= ue of "rph"
       from the 'Resource-Priority' header field based on policy = associated
       with service specific use of the "namespace ".&q= uot; r-priority" values
       based on [RFC4412].  The authentication service deriv= es the value of
       the PASSPorT claim by verifying the authorization for Reso= urce-
       Priority (i.e., verifying a calling user privilege for Res= ource-
       Priority based on its identity) which might be derived fro= m customer
       profile data or from access to external services.

       [RFC4412] allows multiple "namespace "." r-= priority" pairs, either in
       a single SIP Resource-Priority header or across multiple S= IP

     

    Single quotes around 'Resource-Priority'.

    "...header field..."

     

    &nb= sp;  Resource-Priority headers.  However, it is not necessary to = sign all

     

    Single quotes around 'Resource-Priority'.

    "...header fields..."

     

    &nb= sp;  content of a SIP Resource-Priority header or all SIP Resource-

     

    Single quotes around 'Resource-Priority'.

    "...header field..."

     

    &nb= sp;  Priority headers in a given SIP message.  An authority is on= ly

     

    Single quotes around 'Resource-Priority'.

    "...header fields..."

     

    &nb= sp;  responsible for signing the content of a SIP Resource-Priority he= ader

     

    Single quotes around 'Resource-Priority'.

    "...header field..."

     

    &nb= sp;  for which it has authority (e.g., a specific "namespace &quo= t;."
       r-priority").

    4.2.  Verification Service Behavior

       [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires tha= t
       specifications defining "ppt" values describe an= y additional verifier
       behavior.  The behavior specified for the "ppt&q= uot; values of "rph" is as
       follows:

       The verification service MUST extract the value associated= with the
       "auth" key in a full form PASSPorT with a "= ppt" value of "rph".  If
       the signature validates, then the verification service can= use the
       value of the "rph" claim as validation that the = calling party is
       authorized for Resource-Priority, which would in turn be u= sed for

     =

    Single quotes around 'Resource-Priority'.

    This text is ambiguous about whether the val= idation indicates that the calling party is authorized to use the prioritie= s indicated in the passport object, or the values in the SIP 'Resource-Prio= rity' header field; and (taken on its face) implies the latter, when the intention here should clearly be th= e former.

    "...authorized for 'Resource-Priority' = indicated in the claim. This value would in turn be used for..."<= /o:p>

    The text also needs to say something about c= omparing values in the claim to values in the 'Resource-Priority' header fi= eld, and what a mismatch might mean. The document says elsewhere that the s= ignature might only cover some of the r-values, which makes it entirely possible that the 'Resource-Priority= ' field might contain more values than are signed. On the other hand, inter= mediaries might reasonably remove r-values as the call is processed. This p= robably means that those removed priorities should not be used, even if they are present in the passport. I= t seems reasonable to say that *typical* processing by a receiving party wo= uld be to take the *union* of all RPH passports that they trust, and *inter= sect* that with the priorities in 'Resource-Priority' header fields to get the actual priority or priorities= to be applied to the call (subject to local policy).

     

    &nb= sp;  priority treatment in accordance with local policy for the associ= ated
       communication service.

       In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4= requires
       "iat" value in "rph" claim to be verif= ied.

       The behavior of a SIP UAs upon receiving an INVITE contain= ing a

     

    "...of a SIP UA upon..."

    or

    "...of SIP UAs upon..."=

     

    &nb= sp;  PASSporT object with a "rph" claim will largely remain = a matter of
       implementation policy for the specific communication servi= ce.  In
       most cases,implementations would act based on confidence i= n the

     

    "...cases, implementations..."

    (space after comma)

     

    &nb= sp;  veracity of this information.  The use of the compact form o= f

     

    Paragraph break before "The".=

     

    &nb= sp;  PASSporT is not specified in this document.

    5.  Further Information Associated with Resource-Priority

     

    Single quotes around 'Resource-Priority'.

     


       There may be additional information about the calling part= y or the
       call that could be relevant to authorization for Resource-= Priority.

     

    Single quotes around 'Resource-Priority'.

     

    &nb= sp;  This may include information related to the device subscription o= f
       the caller, or to any institutions that the caller or devi= ce is
       associated with, or even categories of institutions. = All of these
       data elements would benefit from the secure attestations p= rovided by
       the STIR and PASSporT frameworks.  The specification = of the "rph"
       claim could entail the optional presence of one or more su= ch
       additional information fields.

       A new IANA registry has been defined to hold potential val= ues of the
       "rph" array; see Section 6.2.  The definiti= on of the "rph" claim may
       have one or more such additional information field(s).&nbs= p; Details of
       such "rph" claim to encompass other data element= s are left for future
       version of this specification.

    6.  IANA Considerations

    6.1.  JSON Web Token Claims Registration

     

    I think there's some confusion here. You're = registering a PASSporT ppt value, not a new JWT claim. That is to say, you'= re adding an entry to this table:

    https://www.iana.org= /assignments/passport/passport.xhtml

    Not to this table:

    https://www.iana.org/assignmen= ts/jwt/jwt.xhtml

    You would only use the second table if you h= ad a new key to add to the PASSporT header -- this specification does not d= o that.

    This section also needs some introductory te= xt to let the IANA know exactly what to do; e.g. "This document regist= ers a new value for the "Personal Assertion Token (PASSporT) Extension= s" table.


       o  ppt value: "rph"

       o  Specification Document(s): Section 3 of [RFCThis]<= /tt>

    6.2.  PASSporT 'rph' Types

       This document requests that the IANA add a new entry to th= e PASSporT
       Types registry for the type "rph" which is speci= fied in [RFCThis].

     

    There isn't an IANA table called "PASSp= orT Types." I presume this is the registration we just discussed in se= ction 6.1, and so the above two lines can be removed.

     

    &nb= sp;  This specification also requests that the IANA create a new regis= try
       for PASSporT "rph" types.  Registration of = new PASSporT "rph" types
       shall be under the specification required policy.  Th= is registry is
       to be initially populated with a single value for "au= th" which is
       specified in [RFCThis].

     

    This needs to be very clear about the fields= to be included in this new registry (e.g., "Registry entries must con= tain two fields: the name of the 'rph' type and the specification in which = the type is described").

     


    7.  Security Considerations

       The security considerations discussed in [I-D.ietf-stir-rf= c4474bis]
       in Section 10 are applicable here.

    7.1.  Avoidance of replay and cut and paste attacks

       The PASSporT extension with a "ppt" value of &qu= ot;rph" MUST only be sent
       with SIP INVITE when 'Resource-Priority' header is used to= convey the

     

    "...header field..."

     

    &nb= sp;  priority of the communication as defined in [RFC4412].  To a= void the
       replay, and cut and paste attacks, the procedures describe= d in
       Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followe= d.

    7.2.  Solution Considerations

       The use of extension to PASSporT tokens with "ppt&quo= t; value "rph" based
       on the validation of the digital signature and the associa= ted
       certificate requires consideration of the authentication a= nd
       authority or reputation of the signer to attest to the ide= ntity being
       asserted.  The following considerations should be rec= ognized when
       using PASSporT extension with "ppt" value of &qu= ot;rph":

       o  An authority (signer) is only allowed to sign the = content of a SIP
          'Resource-Priority' header for which it = has the right authority.    =

     

    "...header field..."

     

    &nb= sp;     The authority that signs the token MUST have a = secure method for
          authentication of the end user or the de= vice.

       o  The verification of the signature MUST include mea= ns of verifying
          that the signer is authoritative for the= signed content of the SIP

     

    It's not clear what authority is being claim= ed here. Is this supposed to mean something like "...verifying that th= e signer is authoritative for the originating tn in the PASSporT..."? = Or "...authoritative for the resource priority namespace in the PASSporT?" Whatever the server is purportedly author= itative for needs to be clearly spelled out.

     

    &nb= sp;     'Resource-Priority' header.

     

    "...header field."

     

    /a


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 =

--_000_E42CCDDA6722744CB241677169E8365668A5B136MISOUT7MSGUSRDB_-- From nobody Mon Feb 5 07:59:15 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27E412D851; Mon, 5 Feb 2018 07:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fPvSVp6iupku; Mon, 5 Feb 2018 07:58:54 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D22E1270A7; Mon, 5 Feb 2018 07:58:54 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w15FthBk016800; Mon, 5 Feb 2018 10:58:50 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2fxsa3hk8g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Feb 2018 10:58:42 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w15FwVOa028019; Mon, 5 Feb 2018 10:58:36 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w15FwNBB027571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Feb 2018 10:58:25 -0500 Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [135.66.87.42]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 5 Feb 2018 15:58:11 GMT Received: from zlp27129.vci.att.com (zlp27129.vci.att.com [127.0.0.1]) by zlp27129.vci.att.com (Service) with ESMTP id 427C740006B4; Mon, 5 Feb 2018 15:58:11 +0000 (GMT) Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (unknown [130.9.129.150]) by zlp27129.vci.att.com (Service) with ESMTPS id 0D24440006A1; Mon, 5 Feb 2018 15:58:11 +0000 (GMT) Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.35]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0361.001; Mon, 5 Feb 2018 10:58:10 -0500 From: "DOLLY, MARTIN C" To: Christer Holmberg , "Julio Martinez-Minguito" , "Singh, Ray P" , "stir@ietf.org" CC: Subir , Adam Roach , STIR Chairs , "draft-ietf-stir-rph.all@tools.ietf.org" Thread-Topic: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? Thread-Index: AQHTngtiY/dEf4YfRra4GseuGeXVLKOV6XowgABXtwD//7F2AA== Date: Mon, 5 Feb 2018 15:58:09 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C135F8E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C153849@ESESSMB109.ericsson.se> <0981B4BB-98C6-4DBB-8E13-A702944ACC3E@gmail.com>, , <7594FB04B1934943A5C02806D1A2204B6C156576@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C156576@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.225.27] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365668A5B224MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050201 Archived-At: Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert the callers identity assumed? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 15:59:13 -0000 --_000_E42CCDDA6722744CB241677169E8365668A5B224MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christer, It does not need to. Regards, Martin From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, February 05, 2018 10:20 AM To: Julio Martinez-Minguito ; Singh, = Ray P ; stir@ietf.org Cc: DOLLY, MARTIN C ; Subir ; Adam Ro= ach ; STIR Chairs ; draft-ietf-stir= -rph.all@tools.ietf.org Subject: RE: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hi, Related to this: how does the verifier know what claim(s) in a PASSPorT the= signer had authority to sign? Regards, Christer From: Julio Martinez-Minguito Sent: 05 February 2018 17:12 To: Christer Holmberg >; Singh, Ray P >; stir@ietf.org Cc: DOLLY, MARTIN C >; Subir >; Adam Roach >; STIR Chairs >; draft-ietf-stir-rph.all@tools.ietf.org Subject: RE: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hi, If the PASSporT with extension ppt:rph only has authority over the rph clai= m, does it mean that we need another PASSporT in the signaling to claim aut= hority over the 'orig' number? Should there be nested PASSporTs? Regards, Julio From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: den 5 februari 2018 07:38 To: Singh, Ray P > Cc: DOLLY, MARTIN C >; Subir >; stir@ietf.org; Adam Roach >; STIR Chairs = >; draft-ietf-stir-rph.al= l@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hi, I think the reason why 'orig' and 'dest' are required in every PASSPorT sho= uld be explained the the PASSPorT document, in my opinion. It is not specif= ic to the RPH extension. Not sure how 'orig' can be used to identify a call. You can have multiple c= alls with the same 'orig' value, can't you? Regards, Christer Sent from my iPhone On 4 Feb 2018, at 21.45, Singh, Ray P > wrote: All, Yes, the claim is only for the RPH. The"orig" and "dest" is included so tha= t the RPH claim can be correlated to the call. We can add some clarificati= on text to indicate that "orig" is only included so that the RPH claim can = be correlated to a specific call, and that the signer of the RPH claim may = no have authority of the "orig" TN. Thanks Ray ________________________________ From: stir [stir-bounces@ietf.org] on behalf = of DOLLY, MARTIN C [md3135@att.com] Sent: Sunday, February 04, 2018 7:05 PM To: Subir; Christer Holmberg Cc: stir@ietf.org; Adam Roach; STIR Chairs; draft-iet= f-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We only have one claim and that is the RPH From: Subir [mailto:subirdas21@gmail.com] Sent: Sunday, February 04, 2018 5:56 PM To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to other claim= s such as 'orig' and in other cases it may not have. We can add a may stat= ement clarifying this or explicitly say that it is not required to have aut= hority to other claims. Thanks, Subir Sent from my iPhone On Feb 4, 2018, at 10:03 PM, Christer Holmberg > wrote: Hi, The text says: "The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the namespace of the "rph" claim and there is only one authority per claim." If the credentials don't need to have authority of the other claims (e.g., = "orig") in the RPH PASSPorT I think you should explicitly say so. Regards, Christer From: Subir Das [mailto:subirdas21@gmail.com] Sent: 02 February 2018 01:04 To: Christer Holmberg > Cc: Adam Roach >; STIR Chairs >; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to assert= the callers identity assumed? Hello Christer, The signing entity does not have always the authority to assert the caller = identity in rph. We are submitting ver-03 draft and it is clarified as fo= llows: "The credentials (e.g., authority responsible for authorizing Resource-Prio= rity) used to create the signature must have authority over the namespace o= f the"rph" claim.." -Subir On Mon, Jan 22, 2018 at 3:27 PM, Christer Holmberg > wrote: Hi, Another question for clarification. Section 3 contains the following example: { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} ...and the following text: "The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim..." Since the claim also contains "orig", is the assumption that the signing en= tity always also has authority to assert the callers identity? I think it w= ould be good to explicitly mention it. Regards, Christer From: stir [mailto:stir-bounces@ietf.org] On = Behalf Of Adam Roach Sent: 20 January 2018 00:15 To: STIR Chairs >; stir@i= etf.org; draft-ietf-stir-rph.all@tools.ietf.org Subject: [stir] AD Review: draft-ietf-stir-rph-02 I'm doing my AD review of draft-ietf-stir-rph-02. Thanks to everyone who ha= s worked on this document, and the authors and chairs in particular. The technical content here looks generally good to me. I'd like to see a fe= w issues addressed before IETF LC. In short sumary: * The validation section needs to add a discussion of how to treat call= s when the priority values in "rph" passports and SIP "Resource-Priority" h= eader fields aren't 100% identical. * The examples need some adjustment. * There is a minor point of ambiguity in the Security Section, but this= should be easy to fix, as long as the WG knows what was intended. * The IANA actions need a little bit of adjustment. * There are a number of minor editorial issues to be cleaned up. Detailed comments on these points are inline in the document below. I've re= moved some portions of the document on which I have no comments. Abstract This document extends the STIR PASSporT specification to allow the "...the Secure Telephone Identity Revisited (STIR) Personal Assertion Token= (PASSporT) specification defined in RFC 8122..." (See for guidance on abbreviations) inclusion of cryptographically-signed assertions of authorization for the values populated in the SIP 'Resource-Priority' header field, which is used for communications resource prioritization. ... 1. Introduction PASSporT [I-D.ietf-stir-passport] is a token format based on JWT [RFC7519] for conveying cryptographically-signed information about the identities involved in personal communications; it is used with STIR [I-D.ietf-stir-rfc4474bis] to convey a signed assertion of the identity of the participants in real-time communications established via a protocol like SIP. This specification extends PASSporT to "...like SIP [RFC3261]..." (We want to cite SIP the first time it is mentioned) allow cryptographic-signing of the SIP 'Resource-Priority' header field defined in [RFC4412]. [RFC4412] defines the SIP 'Resource-Priority' header field for communications Resource Priority. As specified in [RFC4412], the 'Resource-Priority' header field may be used by SIP user agents [RFC3261], including, Public Switched Telephone Network (PSTN) "...including Public Switched..." (remove the comma) gateways and terminals, and SIP proxy servers to influence "...and by SIP proxy servers, to influence..." (add "by" and comma) prioritization afforded to communication sessions,including PSTN "...sessions, including..." (space after comma) calls. However, the SIP 'Resource-Priority' header field could be spoofed and abused by unauthorized entities. The STIR architecture [RFC7340]assumes that an authority on the "...STIR architecture [RFC7340] assumes..." (space before "assumes") originating side of a call provides a cryptographic assurance of the validity of the calling party number in order to prevent impersonation attacks. The STIR architecture allows extension that "...allows extensions..." can be utilized by authorities supporting real-time communication services using the 'Resource-Priority' header field to cryptographically sign the SIP 'Resource-Priority' header field and convey assertion of the authorization for 'Resource-Priority'. For example, the authority on the originating side verifying the authorization of a particular communication for Resource-Priority can Single quotes around 'Resource-Priority'. use a PASSPorT claim to cryptographically-sign the SIP 'Resource- "...cryptographically sign..." Priority' header field and convey an assertion of the authorization for 'Resource-Priority'. This will allow a receiving entity (including entities located in different network domains/boundaries) to verify the validity of assertions authorizing Resource-Priority. Single quotes around 'Resource-Priority'. Cryptographically-signed SIP 'Resource-Priority' headers will allow a "...cryptographically signed SIP 'Resource-Priority' header fields..." (remove hyphen, and replace "headers" with "header fields") receiving entity to verify and act on the information with confidence that the information have not been spoofed or compromised. "...has not been spoofed or compromised." This specification documents an optional extension to PASSporT and the associated STIR mechanisms to provide a function to sign the SIP 'Resource-Priority' header field. This PASSporT object is used to provide attestation of a calling user authorization for priority communications. This is necessary in addition to the PASSporT object that is used for calling user telephone number attestation. How the optional extension to PASSporT is used for real-time communications supported using SIP 'Resource-Priority' header field is defined in other documents and is outside the scope of this document. I assume these other documents are under development? If so, they should be= cited here. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document has several non-normative uses of "must", "should," and "may,= " and so it needs to use the RFC8174 boilerplate instead of the RFC2119 boi= lerplate. 3. PASSporT 'rph' Claim This specification defines a new JSON Web Token claim for "rph", which provides an assertion for information in SIP 'Resource- Priority'header. "...Priority' header field." (space after closing quotation mark, "header field" instead of "header") The creator of a PASSporT object adds a "ppt" value of "rph" to the header of a PASSporT object, in which case the PASSporT claims MUST contain a "rph" claim, and any entities verifying the PASSporT object will be required to understand the "ppt" extension in order to process the PASSporT in question. A PASSPorT header with the "ppt" included will look as follows: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer"} Ideally, this would be either pretty-printed or canonicalized. Since it's t= oo long to fit on a line in canonical form, I propose: { "typ":"passport", "ppt":"rph", "alg":"ES256", "x5u":"https://www.example.org/cert.cer" } The "rph" claim will provide an assertion of authorization,"auth", "...authorization, "auth", ..." (space between comma and opening quotation mark) for information in the SIP "Resource-Priority" header field (i.e., Resource-Priority: namespace "." r-priority) based on [RFC4412]. The use of the string 'namespace "." r-priority' here and elsewhere in the = document has a detrimental impact on readability. I strongly suggest replac= ing it with "r-value" (the name of this production in RFC4412) everywhere. Specifically, the "rph" claim includes assertion of the priority- level of the user to be used for a given communication session. The value of the "rph" claim is an array containing one or more of JSON objects for the content of the SIP 'Resource-Priority' header that is being asserted of which one of the "rph" object, is mandatory. This last sentence is very hard to parse; and (based on the example) the va= lue is intended to be a JSON Object (curly braces) rather than a JSON Array= (square braces). I suggest: 'The value of the "rph" claim is an Object wit= h one or more keys. Each key is associated with a JSON Array. These arrays = contain Strings that correspond to the r-values indicated in the SIP "Resou= rce-Priority" header field.' (note: "header field", not "header") The following is an example "rph" claim for a SIP "Resource-Priority" header field with a "namespace "." r-priority" value of "ets.0" and with a "namespace "." r-priority" value of "wps.0". { "orig":{"tn":"12155551212"} "dest":{["tn":"12125551213"]}, "iat":1443208345, "rph":{"auth":["ets.0","wps.0"]} As above, I recommend pretty-printing this. It's also missing a comma after= the "orig" value, and the top-level structure is missing a closing brace. = The value for "iat" needs to be enclosed in quotes. The NANPA has allocated NPA55501xx for example use, not NPA555xxxx, much of= which remains assignable (cf ). Putting all this together, I believe what you want is: { "orig":{"tn":"12155550112"}, "dest":{["tn":"12125550113"]}, "iat":"1443208345", "rph":{"auth":["ets.0","wps.0"]} } After the header and claims PASSporT objects have been constructed, their signature is generated normally per the guidance in [I-D.ietf-stir-passport] using the full form of PASSPorT. The credentials (e.g., authority responsible for authorizing Resource- Priority) used to create the signature must have authority over the "rph" claim and there is only one authority per claim. The authority MUST use its credentials (i.e., CERT) associated with the specific service supported by the SIP namespace in the claim. 4. 'rph' in SIP This section specifies SIP-specific usage for the "rph" claim in PASSporT. 4.1. Authentication Service Behavior The Authentication Service will create the "rph" claim using the values discussed in section 3 based on [RFC4412]. The construction of "rph" claim follows the steps described in Section 4 of [I-D.ietf-stir-rfc4474bis]. The resulting Identity header for "rph" might look as follows: "...header field..." "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUowZVhBaU9pSnd ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKRlV6STFO aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1OdmJTOWpaW EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjBiaUk2SW pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlNVEkxTlR VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR2dpT25z aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6VC8HM6D l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXvs3fslM_ oos2P2Dyw"; info=3D "https://www.example.org/cert.cer";alg=3DES256; ppt=3D"rph" This example has a number of issues: * In the Identity header field, the signed-identity-digest shouldn't be= quoted. * In the Identity header field, info is enclosed in <> rather than "". * In the Identity header field, ppt is a token rather than a quoted str= ing. * The signed-identity-digest header needs to indicate a "typ" of "passp= ort" rather than JWT, and it needs to include both a "ppt" and "x5u" field. * The signed-identity-digest body should contain only the passport clai= m rather than a JSON object that itself contains a base64-encoded JWS heade= r concatenated with a claim. * I believe that, even when the body is included, values in the header = and body need to be be canonicalized (i.e., all on one line, no spaces, in = alphabetical order, etc.) I would also recommend following the convention of indicating that line-wra= ps are only for readability, and including the header field name in the exa= mple. Putting all this together, I believe what you want is: For example, a Identity header field for "rph" might look as follows (backslashes shown for line folding only): Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \ iwieDV1IjoiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQo.eyJkZXN0 \ Ijp7WyJ0biI6IjEyMTI1NTUwMTEzIl19LCJpYXQiOiIxNDQzMjA4MzQ1Iiwib3JpZyI \ 6eyJ0biI6IjEyMTU1NTUwMTEyIn0sInJwaCI6eyJhdXRoIjpbImV0cy4wIiwid3BzLj \ AiXX19Cg.s37S6VC8HM6Dl6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr \ 18vYYFy3blXvs3fslM_oos2P2Dyw;info=3D \ >;alg=3DES256;ppt=3Drph (Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550= 113, respectively) A SIP authentication service typically will derive the value of "rph" from the 'Resource-Priority' header field based on policy associated with service specific use of the "namespace "." r-priority" values based on [RFC4412]. The authentication service derives the value of the PASSPorT claim by verifying the authorization for Resource- Priority (i.e., verifying a calling user privilege for Resource- Priority based on its identity) which might be derived from customer profile data or from access to external services. [RFC4412] allows multiple "namespace "." r-priority" pairs, either in a single SIP Resource-Priority header or across multiple SIP Single quotes around 'Resource-Priority'. "...header field..." Resource-Priority headers. However, it is not necessary to sign all Single quotes around 'Resource-Priority'. "...header fields..." content of a SIP Resource-Priority header or all SIP Resource- Single quotes around 'Resource-Priority'. "...header field..." Priority headers in a given SIP message. An authority is only Single quotes around 'Resource-Priority'. "...header fields..." responsible for signing the content of a SIP Resource-Priority header Single quotes around 'Resource-Priority'. "...header field..." for which it has authority (e.g., a specific "namespace "." r-priority"). 4.2. Verification Service Behavior [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires that specifications defining "ppt" values describe any additional verifier behavior. The behavior specified for the "ppt" values of "rph" is as follows: The verification service MUST extract the value associated with the "auth" key in a full form PASSPorT with a "ppt" value of "rph". If the signature validates, then the verification service can use the value of the "rph" claim as validation that the calling party is authorized for Resource-Priority, which would in turn be used for Single quotes around 'Resource-Priority'. This text is ambiguous about whether the validation indicates that the call= ing party is authorized to use the priorities indicated in the passport obj= ect, or the values in the SIP 'Resource-Priority' header field; and (taken = on its face) implies the latter, when the intention here should clearly be = the former. "...authorized for 'Resource-Priority' indicated in the claim. This value w= ould in turn be used for..." The text also needs to say something about comparing values in the claim to= values in the 'Resource-Priority' header field, and what a mismatch might = mean. The document says elsewhere that the signature might only cover some = of the r-values, which makes it entirely possible that the 'Resource-Priori= ty' field might contain more values than are signed. On the other hand, int= ermediaries might reasonably remove r-values as the call is processed. This= probably means that those removed priorities should not be used, even if t= hey are present in the passport. It seems reasonable to say that *typical* = processing by a receiving party would be to take the *union* of all RPH pas= sports that they trust, and *intersect* that with the priorities in 'Resour= ce-Priority' header fields to get the actual priority or priorities to be a= pplied to the call (subject to local policy). priority treatment in accordance with local policy for the associated communication service. In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4 requires "iat" value in "rph" claim to be verified. The behavior of a SIP UAs upon receiving an INVITE containing a "...of a SIP UA upon..." or "...of SIP UAs upon..." PASSporT object with a "rph" claim will largely remain a matter of implementation policy for the specific communication service. In most cases,implementations would act based on confidence in the "...cases, implementations..." (space after comma) veracity of this information. The use of the compact form of Paragraph break before "The". PASSporT is not specified in this document. 5. Further Information Associated with Resource-Priority Single quotes around 'Resource-Priority'. There may be additional information about the calling party or the call that could be relevant to authorization for Resource-Priority. Single quotes around 'Resource-Priority'. This may include information related to the device subscription of the caller, or to any institutions that the caller or device is associated with, or even categories of institutions. All of these data elements would benefit from the secure attestations provided by the STIR and PASSporT frameworks. The specification of the "rph" claim could entail the optional presence of one or more such additional information fields. A new IANA registry has been defined to hold potential values of the "rph" array; see Section 6.2. The definition of the "rph" claim may have one or more such additional information field(s). Details of such "rph" claim to encompass other data elements are left for future version of this specification. 6. IANA Considerations 6.1. JSON Web Token Claims Registration I think there's some confusion here. You're registering a PASSporT ppt valu= e, not a new JWT claim. That is to say, you're adding an entry to this tabl= e: https://www.iana.org/assignments/passport/passport.xhtml Not to this table: https://www.iana.org/assignments/jwt/jwt.xhtml You would only use the second table if you had a new key to add to the PASS= porT header -- this specification does not do that. This section also needs some introductory text to let the IANA know exactly= what to do; e.g. "This document registers a new value for the "Personal As= sertion Token (PASSporT) Extensions" table. o ppt value: "rph" o Specification Document(s): Section 3 of [RFCThis] 6.2. PASSporT 'rph' Types This document requests that the IANA add a new entry to the PASSporT Types registry for the type "rph" which is specified in [RFCThis]. There isn't an IANA table called "PASSporT Types." I presume this is the re= gistration we just discussed in section 6.1, and so the above two lines can= be removed. This specification also requests that the IANA create a new registry for PASSporT "rph" types. Registration of new PASSporT "rph" types shall be under the specification required policy. This registry is to be initially populated with a single value for "auth" which is specified in [RFCThis]. This needs to be very clear about the fields to be included in this new reg= istry (e.g., "Registry entries must contain two fields: the name of the 'rp= h' type and the specification in which the type is described"). 7. Security Considerations The security considerations discussed in [I-D.ietf-stir-rfc4474bis] in Section 10 are applicable here. 7.1. Avoidance of replay and cut and paste attacks The PASSporT extension with a "ppt" value of "rph" MUST only be sent with SIP INVITE when 'Resource-Priority' header is used to convey the "...header field..." priority of the communication as defined in [RFC4412]. To avoid the replay, and cut and paste attacks, the procedures described in Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followed. 7.2. Solution Considerations The use of extension to PASSporT tokens with "ppt" value "rph" based on the validation of the digital signature and the associated certificate requires consideration of the authentication and authority or reputation of the signer to attest to the identity being asserted. The following considerations should be recognized when using PASSporT extension with "ppt" value of "rph": o An authority (signer) is only allowed to sign the content of a SIP 'Resource-Priority' header for which it has the right authority. "...header field..." The authority that signs the token MUST have a secure method for authentication of the end user or the device. o The verification of the signature MUST include means of verifying that the signer is authoritative for the signed content of the SIP It's not clear what authority is being claimed here. Is this supposed to me= an something like "...verifying that the signer is authoritative for the or= iginating tn in the PASSporT..."? Or "...authoritative for the resource pri= ority namespace in the PASSporT?" Whatever the server is purportedly author= itative for needs to be clearly spelled out. 'Resource-Priority' header. "...header field." /a _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir --_000_E42CCDDA6722744CB241677169E8365668A5B224MISOUT7MSGUSRDB_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christer,

 

It does not need to.

 

Regards,

 

Martin

 

From: Christer Holmberg [mailto:chri= ster.holmberg@ericsson.com]
Sent: Monday, February 05, 2018 10:20 AM
To: Julio Martinez-Minguito <julio.martinez-minguito@ericsson.com= >; Singh, Ray P <rsingh@vencorelabs.com>; stir@ietf.org
Cc: DOLLY, MARTIN C <md3135@att.com>; Subir <subirdas21@gma= il.com>; Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chair= s@ietf.org>; draft-ietf-stir-rph.all@tools.ietf.org
Subject: RE: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hi,<= /p>

 

Related to this: how d= oes the verifier know what claim(s) in a PASSPorT the signer had authority = to sign?

 

Regards,

 

Christer

 

From: Julio Martinez-Minguito
Sent: 05 February 2018 17:12
To: Christer Holmberg <christer.holmberg@ericsson.com>; Singh, Ray P <rsingh@vencorelabs.com>; stir@ietf.org
Cc: DOLLY, MARTIN C <md3135@att= .com>; Subir <subirdas21@= gmail.com>; Adam Roach <adam@= nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: RE: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hi,

 

If the PASSporT with extension ppt:rph only has aut= hority over the rph claim, does it mean that we need another PASSporT in th= e signaling to claim authority over the ‘orig’ number?

Should there be nested PASSporTs?=

 

Regards, Julio

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.co= m]
Sent: den 5 februari 2018 07:38
To: Singh, Ray P <rsing= h@vencorelabs.com>
Cc: DOLLY, MARTIN C <md3135@att= .com>; Subir <subirdas21@= gmail.com>; stir@ietf.org; Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 

Hi,

 

I think the reason why ‘orig’ and ‘= ;dest’ are required in every PASSPorT should be explained the the PAS= SPorT document, in my opinion. It is not specific to the RPH extension.

 

Not sure how ‘orig’ can be used to ident= ify a call. You can have multiple calls with the same ‘orig’ va= lue, can’t you? 

 

Regards,

 

Christer

 

 

Sent from my iPhone


On 4 Feb 2018, at 21.45, Singh, Ray P <rsingh@vencorelabs.com> wrote:

All,

Yes, the claim is only for the RPH. The"orig" and = "dest" is included so that the RPH claim can be correlated to the= call.  We can add some clarification text to indicate that "orig= " is only included so that the RPH claim can be correlated to a specific cal= l, and that the signer of the RPH claim may no have authority of the "= orig" TN.

Thanks

Ray

 

 

From:<= /span> stir [stir-= bounces@ietf.org] on behalf of DOLLY, MARTIN C [md3135@att= .com]
Sent: Sunday, February 04, 2018 7:05 PM
To: Subir; Christer Holmberg
Cc: stir@ietf.org; Adam Roach; = STIR Chairs; draft-ietf-stir-r= ph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

We only have one claim and that is the = RPH

 =

From: Subir = [mailto:subirdas21@gmail.com]
Sent: Sunday, February 04, 2018 5:56 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.= com>; STIR Chairs <stir-c= hairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 =


We can add some texts to clarify that in the next version. The point is tha= t in some use cases service provider may have the authority to  other = claims such as 'orig' and in other cases it may not have.  We can add = a may statement clarifying this or explicitly say that it is not required to have authority to other claims.<= /span>

 =

Thanks,

 =

Subir 
Sent from my iPhone


On Feb 4, 2018, at 10:03 PM, Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:

Hi,

 =

The text says:

 =

   “The credentials (= e.g., authority responsible for authorizing Resource-

   Priority) used to create= the signature must have authority over the

   namespace of the "r= ph" claim and there is only one authority per

   claim.”

 =

If the credentials don’t need t= o have authority of the other claims (e.g., “orig”) in the RPH = PASSPorT I think you should explicitly say so.

 =

Regards,

 =

Christer

 =

 =

From: Subir = Das [mailto:subir= das21@gmail.com]
Sent: 02 February 2018 01:04
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>; STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org
Subject: Re: [stir] AD Review: draft-ietf-stir-rph-02 - authority to= assert the callers identity assumed?

 =

Hello Christer,

The signing entity does = not have always the authority to assert the caller identity in rph. We are = submitting ver-03 draft  and it is clarified  as follows:

"The credentials (e.g., authorit= y responsible for authorizing Resource-Priority) used to create the signatu= re must have authority over the namespace of the“rph" claim.."

 =

-Subir

 =

On Mon, Jan 22, 2018 at = 3:27 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:<= /o:p>

Hi,

 =

Another question for clarification.

 =

Section 3 contains the following exam= ple:

 =

    { "orig"= :{"tn":"12155551212"}

     "dest&q= uot;:{["tn":"12125551213"]},

     "iat&qu= ot;:1443208345,

     "rph&qu= ot;:{"auth":["ets.0","wps.0"]}

 =

…and the following text:=

 =

   “The credentials (= e.g., authority responsible for authorizing Resource-

   Priority) used to create= the signature must have authority over the

   "rph" claim= 230;”

<= /a> 

Since the claim also contains “= orig”, is the assumption that the signing entity always also has auth= ority to assert the callers identity? I think it would be good to explicitly mention it.

 =

Regards,

 =

Christer

 =

 =

 =

 =

 =

 =

From: stir [= mailto:stir-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 20 January 2018 00:15
To: STIR Chairs <stir-chairs@ietf.org>; stir@ietf.org; draft-ietf-stir-rph.all@tools.ietf.org=
Subject: [stir] AD Review: draft-ietf-stir-rph-02

 =

I'm doing my AD review of draft-ietf-stir-rp= h-02. Thanks to everyone who has worked on this document, and the authors a= nd chairs in particular.

The technical content here looks generally g= ood to me. I'd like to see a few issues addressed before IETF LC. In short = sumary:

  • The validation section needs to add a discussion of how to treat calls when= the priority values in "rph" passports and SIP "Resource-Pr= iority" header fields aren't 100% identical.
  • The examples need some adjustment.
  • There is a minor point of ambiguity in the Security Section, but this shoul= d be easy to fix, as long as the WG knows what was intended.
  • The IANA actions need a little bit of adjustment.
  • Detailed comments on these points are inline= in the document below. I've removed some portions of the document on which= I have no comments.

     


    Abstract

       This document extends the STIR PASSporT specification to a= llow the

     

    "...the Secure Telephone Identity Revis= ited (STIR) Personal Assertion Token (PASSporT) specification defined in RF= C 8122..."

    (See <https://www.rfc-editor.org/materials/abbrev.expansion.txt> for g= uidance on abbreviations)

     

    &nb= sp;  inclusion of cryptographically-signed assertions of authorization= for
       the values populated in the SIP 'Resource-Priority' header= field,
       which is used for communications resource prioritization.<= /tt>

    ...

    1.  Introduction

       PASSporT [I-D.ietf-stir-passport] is a token format based = on JWT
       [RFC7519] for conveying cryptographically-signed informati= on about
       the identities involved in personal communications; it is = used with
       STIR [I-D.ietf-stir-rfc4474bis] to convey a signed asserti= on of the
       identity of the participants in real-time communications e= stablished
       via a protocol like SIP.  This specification extends = PASSporT to

     

    "...like SIP [RFC3261]..."

    (We want to cite SIP the first time it is me= ntioned)

     

    &nb= sp;  allow cryptographic-signing of the SIP 'Resource-Priority' header=
       field defined in [RFC4412].

       [RFC4412] defines the SIP 'Resource-Priority' header field= for
       communications Resource Priority.  As specified in [R= FC4412], the
       'Resource-Priority' header field may be used by SIP user a= gents
       [RFC3261], including, Public Switched Telephone Network (P= STN)

     

    "...including Public Switched..."<= o:p>

    (remove the comma)

     

    &nb= sp;  gateways and terminals, and SIP proxy servers to influence=

     

    "...and by SIP proxy servers, to influe= nce..."

    (add "by" and comma)

     

    &nb= sp;  prioritization afforded to communication sessions,including PSTN<= /span>

     =

    "...sessions, including..."

    (space after comma)

     

    &nb= sp;  calls.  However, the SIP 'Resource-Priority' header field co= uld be
       spoofed and abused by unauthorized entities.

       The STIR architecture [RFC7340]assumes that an authority o= n the

     

    "...STIR architecture [RFC7340] assumes= ..."

    (space before "assumes")

     

    &nb= sp;  originating side of a call provides a cryptographic assurance of = the
       validity of the calling party number in order to prevent
       impersonation attacks.  The STIR architecture allows = extension that

     

    "...allows extensions..."

     

    &nb= sp;  can be utilized by authorities supporting real-time communication=
       services using the 'Resource-Priority' header field to
       cryptographically sign the SIP 'Resource-Priority' header = field and
       convey assertion of the authorization for 'Resource-Priori= ty'.  For
       example, the authority on the originating side verifying t= he
       authorization of a particular communication for Resource-P= riority can

     

    Single quotes around 'Resource-Priority'.

     

    &nb= sp;  use a PASSPorT claim to cryptographically-sign the SIP 'Resource-=

     

    "...cryptographically sign..."

     

    &nb= sp;  Priority' header field and convey an assertion of the authorizati= on
       for 'Resource-Priority'.  This will allow a receiving= entity
       (including entities located in different network domains/b= oundaries)
       to verify the validity of assertions authorizing Resource-= Priority.

     

    Single quotes around 'Resource-Priority'.

     

    &nb= sp;  Cryptographically-signed SIP 'Resource-Priority' headers will all= ow a

     

    "...cryptographically signed SIP 'Resou= rce-Priority' header fields..."

    (remove hyphen, and replace "headers&qu= ot; with "header fields")

     

    &nb= sp;  receiving entity to verify and act on the information with confid= ence
       that the information have not been spoofed or compromised.=

     

    "...has not been spoofed or compromised= ."

     


       This specification documents an optional extension to PASS= porT and
       the associated STIR mechanisms to provide a function to si= gn the SIP
       'Resource-Priority' header field.  This PASSporT obje= ct is used to
       provide attestation of a calling user authorization for pr= iority
       communications.  This is necessary in addition to the= PASSporT object
       that is used for calling user telephone number attestation= .  How the
       optional extension to PASSporT is used for real-time commu= nications
       supported using SIP 'Resource-Priority' header field is de= fined in
       other documents and is outside the scope of this document.=

     

    I assume these other documents are under dev= elopment? If so, they should be cited here.

     


    2.  Terminology

       The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in RFC 2119 [R= FC2119].

     

    This document has several non-normative uses= of "must", "should," and "may," and so it ne= eds to use the RFC8174 boilerplate instead of the RFC2119 boilerplate.=

     


    3.  PASSporT 'rph' Claim

       This specification defines a new JSON Web Token claim for = "rph",
       which provides an assertion for information in SIP 'Resour= ce-
       Priority'header.

     

    "...Priority' header field."<= /o:p>

    (space after closing quotation mark, "h= eader field" instead of "header")

     


       The creator of a PASSporT object adds a "ppt" va= lue of "rph" to the
       header of a PASSporT object, in which case the PASSporT cl= aims MUST
       contain a "rph" claim, and any entities verifyin= g the PASSporT object
       will be required to understand the "ppt" extensi= on in order to
       process the PASSporT in question.  A PASSPorT header = with the "ppt"
       included will look as follows:

       {  "typ":"passport",
         "ppt":"rph",
         "alg":"ES256",
         "x5u":    "https://www.example.org/cert.cer"}

     

    Ideally, this would be either pretty-printed= or canonicalized. Since it's too long to fit on a line in canonical form, = I propose:

    {
      "typ":"passport",
      "ppt":"rph",
      "alg":"ES256",
      "x5u":    "https:/= /www.example.org/cert.cer"
    }

     


       The "rph" claim will provide an assertion of aut= horization,"auth",

     

    "...authorization, "auth", ..= ."

    (space between comma and opening quotation m= ark)

     

    &nb= sp;  for information in the SIP "Resource-Priority" header f= ield (i.e.,
       Resource-Priority: namespace "." r-priority) bas= ed on [RFC4412].    <= /p>

     

    The use of the string 'namespace ".&quo= t; r-priority' here and elsewhere in the document has a detrimental impact = on readability. I strongly suggest replacing it with "r-value" (t= he name of this production in RFC4412) everywhere.

     

    &nb= sp;  Specifically, the "rph" claim includes assertion of the= priority-
       level of the user to be used for a given communication ses= sion.  The
       value of the "rph" claim is an array containing = one or more of JSON
       objects for the content of the SIP 'Resource-Priority' hea= der that is
       being asserted of which one of the "rph" object,= is mandatory.

     

    This last sentence is very hard to parse; an= d (based on the example) the value is intended to be a JSON Object (curly b= races) rather than a JSON Array (square braces). I suggest: 'The value of t= he "rph" claim is an Object with one or more keys. Each key is associated with a JSON Array. These arrays conta= in Strings that correspond to the r-values indicated in the SIP "Resou= rce-Priority" header field.' (note: "header field", not &quo= t;header")

     


       The following is an example "rph" claim for a SI= P "Resource-Priority"
       header field with a "namespace "." r-priori= ty" value of "ets.0" and
       with a "namespace "." r-priority" valu= e of "wps.0".

        { "orig":{"tn":"1= 2155551212"}
         "dest":{["tn":"<= /span>12125551213"]},
         "iat":1443208345,
         "rph":{"auth":["ets.0= ","wps.0"]}

     

    As above, I recommend pretty-printing this. = It's also missing a comma after the "orig" value, and the top-lev= el structure is missing a closing brace. The value for "iat" need= s to be enclosed in quotes.

    The NANPA has allocated NPA55501xx for examp= le use, not NPA555xxxx, much of which remains assignable (cf <https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf>).<= /o:p>

    Putting all this together, I believe what yo= u want is:

    {
      "orig":{"tn":"    12155550112"},
      "dest":{["tn":"    12125550113"]},<= /span>
      "iat":"1443208345",
      "rph":{"auth":["ets.0","wps.0= "]}
    }

     


       After the header and claims PASSporT objects have been con= structed,
       their signature is generated normally per the guidance in<= /tt>
       [I-D.ietf-stir-passport] using the full form of PASSPorT.&= nbsp; The
       credentials (e.g., authority responsible for authorizing R= esource-
       Priority) used to create the signature must have authority= over the
       "rph" claim and there is only one authority per = claim.  The authority
       MUST use its credentials (i.e., CERT) associated with the = specific
       service supported by the SIP namespace in the claim.<= br>
    4.  'rph' in SIP

       This section specifies SIP-specific usage for the "rp= h" claim in
       PASSporT.

    4.1.  Authentication Service Behavior

       The Authentication Service will create the "rph"= claim using the
       values discussed in section 3 based on [RFC4412].  Th= e construction
       of "rph" claim follows the steps described in Se= ction 4 of
       [I-D.ietf-stir-rfc4474bis].

       The resulting Identity header for "rph" might lo= ok as follows:

     

    "...header field..."

     


       "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJleUo= wZVhBaU9pSnd
       ZWE56Y0c5eWRDSXNEUW9pY0hCMElqb2ljbkJvSWl3TkNpSmhiR2NpT2lKR= lV6STFO
       aUlzRFFvaWVEVjFJanBvZEhSd2N6b3ZMM2QzZHk1bGVHRnRjR3hsTG1Odm= JTOWpaW
       EowTG1ObGNuME5DZzBLIHx84oCZLuKAmXx8IGV5QWliM0pwWnlJNmV5SjB= iaUk2SW
       pFeU1UVTFOVFV4TWpFeUluME5DaUprWlhOMElqcDdXeUowYmlJNklqRXlN= VEkxTlR
       VeE1qRXpJbDE5TEEwS0ltbGhkQ0k2TVRRME16SXdPRE0wTlN3TkNpSnljR= 2dpT25z
       aVlYVjBhQ0k2V3lKbGRITXVNQ0lzSW5kd2N5NHdJbDE5RFFvPSJ9.s37S6= VC8HM6D
       l6YzJeQDsrZcwJ0lizxhUrA7f_98oWBHvo-cl-n8MIhoCr18vYYFy3blXv= s3fslM_
       oos2P2Dyw"; info=3D     ;alg=3DES256;
       ppt=3D"rph"

     

    This example has a number of issues:

    • In the Identity header field, the signed-identity-digest shouldn't be quote= d.
    • In the Identity header field, info is enclosed in <> rather than &quo= t;".
    • In the Identity header field, ppt is a token rather than a quoted string. <= o:p>
    • The signed-identity-digest header needs to indicate a "typ" of &q= uot;passport" rather than JWT, and it needs to include both a "pp= t" and "x5u" field.
    • The signed-identity-digest body should contain only the passport claim rath= er than a JSON object that itself contains a base64-encoded JWS header conc= atenated with a claim.
    • I believe that, even when the body is included, values in the header and bo= dy need to be be canonicalized (i.e., all on one line, no spaces, in alphab= etical order, etc.)

    I would also recommend following the convent= ion of indicating that line-wraps are only for readability, and including t= he header field name in the example. Putting all this together, I believe w= hat you want is:

       For exampl= e, a Identity header field for "rph" might look=
       as follows (backslashes shown for line folding only):=

       Identity: = eyJhbGciOiJFUzI1NiIsInBwdCI6InJwaCIsInR5cCI6InBhc3Nwb3J0I \https://www.example.org/cert.cer \
       >;alg=3DES256;ppt=3Drph

    (Note: this example assumes the calling and called party numbers in the pre= vious example are changed to 12155550112 and 12155550113, respectively)

     


       A SIP authentication service typically will derive the val= ue of "rph"
       from the 'Resource-Priority' header field based on policy = associated
       with service specific use of the "namespace ".&q= uot; r-priority" values
       based on [RFC4412].  The authentication service deriv= es the value of
       the PASSPorT claim by verifying the authorization for Reso= urce-
       Priority (i.e., verifying a calling user privilege for Res= ource-
       Priority based on its identity) which might be derived fro= m customer
       profile data or from access to external services.

       [RFC4412] allows multiple "namespace "." r-= priority" pairs, either in
       a single SIP Resource-Priority header or across multiple S= IP

     

    Single quotes around 'Resource-Priority'.

    "...header field..."

     

    &nb= sp;  Resource-Priority headers.  However, it is not necessary to = sign all

     

    Single quotes around 'Resource-Priority'.

    "...header fields..."

     

    &nb= sp;  content of a SIP Resource-Priority header or all SIP Resource-

     

    Single quotes around 'Resource-Priority'.

    "...header field..."

     

    &nb= sp;  Priority headers in a given SIP message.  An authority is on= ly

     

    Single quotes around 'Resource-Priority'.

    "...header fields..."

     

    &nb= sp;  responsible for signing the content of a SIP Resource-Priority he= ader

     

    Single quotes around 'Resource-Priority'.

    "...header field..."

     

    &nb= sp;  for which it has authority (e.g., a specific "namespace &quo= t;."
       r-priority").

    4.2.  Verification Service Behavior

       [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 5 requires tha= t
       specifications defining "ppt" values describe an= y additional verifier
       behavior.  The behavior specified for the "ppt&q= uot; values of "rph" is as
       follows:

       The verification service MUST extract the value associated= with the
       "auth" key in a full form PASSPorT with a "= ppt" value of "rph".  If
       the signature validates, then the verification service can= use the
       value of the "rph" claim as validation that the = calling party is
       authorized for Resource-Priority, which would in turn be u= sed for

     =

    Single quotes around 'Resource-Priority'.

    This text is ambiguous about whether the val= idation indicates that the calling party is authorized to use the prioritie= s indicated in the passport object, or the values in the SIP 'Resource-Prio= rity' header field; and (taken on its face) implies the latter, when the intention here should clearly be th= e former.

    "...authorized for 'Resource-Priority' = indicated in the claim. This value would in turn be used for..."<= /o:p>

    The text also needs to say something about c= omparing values in the claim to values in the 'Resource-Priority' header fi= eld, and what a mismatch might mean. The document says elsewhere that the s= ignature might only cover some of the r-values, which makes it entirely possible that the 'Resource-Priority= ' field might contain more values than are signed. On the other hand, inter= mediaries might reasonably remove r-values as the call is processed. This p= robably means that those removed priorities should not be used, even if they are present in the passport. I= t seems reasonable to say that *typical* processing by a receiving party wo= uld be to take the *union* of all RPH passports that they trust, and *inter= sect* that with the priorities in 'Resource-Priority' header fields to get the actual priority or priorities= to be applied to the call (subject to local policy).

     

    &nb= sp;  priority treatment in accordance with local policy for the associ= ated
       communication service.

       In addition, [I-D.ietf-stir-rfc4474bis] Section 6.2 Step 4= requires
       "iat" value in "rph" claim to be verif= ied.

       The behavior of a SIP UAs upon receiving an INVITE contain= ing a

     

    "...of a SIP UA upon..."

    or

    "...of SIP UAs upon..."=

     

    &nb= sp;  PASSporT object with a "rph" claim will largely remain = a matter of
       implementation policy for the specific communication servi= ce.  In
       most cases,implementations would act based on confidence i= n the

     

    "...cases, implementations..."

    (space after comma)

     

    &nb= sp;  veracity of this information.  The use of the compact form o= f

     

    Paragraph break before "The".=

     

    &nb= sp;  PASSporT is not specified in this document.

    5.  Further Information Associated with Resource-Priority

     

    Single quotes around 'Resource-Priority'.

     


       There may be additional information about the calling part= y or the
       call that could be relevant to authorization for Resource-= Priority.

     

    Single quotes around 'Resource-Priority'.

     

    &nb= sp;  This may include information related to the device subscription o= f
       the caller, or to any institutions that the caller or devi= ce is
       associated with, or even categories of institutions. = All of these
       data elements would benefit from the secure attestations p= rovided by
       the STIR and PASSporT frameworks.  The specification = of the "rph"
       claim could entail the optional presence of one or more su= ch
       additional information fields.

       A new IANA registry has been defined to hold potential val= ues of the
       "rph" array; see Section 6.2.  The definiti= on of the "rph" claim may
       have one or more such additional information field(s).&nbs= p; Details of
       such "rph" claim to encompass other data element= s are left for future
       version of this specification.

    6.  IANA Considerations

    6.1.  JSON Web Token Claims Registration

     

    I think there's some confusion here. You're = registering a PASSporT ppt value, not a new JWT claim. That is to say, you'= re adding an entry to this table:

    https://www.iana.org= /assignments/passport/passport.xhtml

    Not to this table:

    https://www.iana.org/assignmen= ts/jwt/jwt.xhtml

    You would only use the second table if you h= ad a new key to add to the PASSporT header -- this specification does not d= o that.

    This section also needs some introductory te= xt to let the IANA know exactly what to do; e.g. "This document regist= ers a new value for the "Personal Assertion Token (PASSporT) Extension= s" table.


       o  ppt value: "rph"

       o  Specification Document(s): Section 3 of [RFCThis]<= /tt>

    6.2.  PASSporT 'rph' Types

       This document requests that the IANA add a new entry to th= e PASSporT
       Types registry for the type "rph" which is speci= fied in [RFCThis].

     

    There isn't an IANA table called "PASSp= orT Types." I presume this is the registration we just discussed in se= ction 6.1, and so the above two lines can be removed.

     

    &nb= sp;  This specification also requests that the IANA create a new regis= try
       for PASSporT "rph" types.  Registration of = new PASSporT "rph" types
       shall be under the specification required policy.  Th= is registry is
       to be initially populated with a single value for "au= th" which is
       specified in [RFCThis].

     

    This needs to be very clear about the fields= to be included in this new registry (e.g., "Registry entries must con= tain two fields: the name of the 'rph' type and the specification in which = the type is described").

     


    7.  Security Considerations

       The security considerations discussed in [I-D.ietf-stir-rf= c4474bis]
       in Section 10 are applicable here.

    7.1.  Avoidance of replay and cut and paste attacks

       The PASSporT extension with a "ppt" value of &qu= ot;rph" MUST only be sent
       with SIP INVITE when 'Resource-Priority' header is used to= convey the

     

    "...header field..."

     

    &nb= sp;  priority of the communication as defined in [RFC4412].  To a= void the
       replay, and cut and paste attacks, the procedures describe= d in
       Section 10.1 of [I-D.ietf-stir-rfc4474bis] MUST be followe= d.

    7.2.  Solution Considerations

       The use of extension to PASSporT tokens with "ppt&quo= t; value "rph" based
       on the validation of the digital signature and the associa= ted
       certificate requires consideration of the authentication a= nd
       authority or reputation of the signer to attest to the ide= ntity being
       asserted.  The following considerations should be rec= ognized when
       using PASSporT extension with "ppt" value of &qu= ot;rph":

       o  An authority (signer) is only allowed to sign the = content of a SIP
          'Resource-Priority' header for which it = has the right authority.    =

     

    "...header field..."

     

    &nb= sp;     The authority that signs the token MUST have a = secure method for
          authentication of the end user or the de= vice.

       o  The verification of the signature MUST include mea= ns of verifying
          that the signer is authoritative for the= signed content of the SIP

     

    It's not clear what authority is being claim= ed here. Is this supposed to mean something like "...verifying that th= e signer is authoritative for the originating tn in the PASSporT..."? = Or "...authoritative for the resource priority namespace in the PASSporT?" Whatever the server is purportedly author= itative for needs to be clearly spelled out.

     

    &nb= sp;     'Resource-Priority' header.

     

    "...header field."

     

    /a


_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org/mailman/listinfo/stir

 =

--_000_E42CCDDA6722744CB241677169E8365668A5B224MISOUT7MSGUSRDB_-- From nobody Mon Feb 5 23:01:35 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B84126CD6 for ; Mon, 5 Feb 2018 23:01:35 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar 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 rs2aF8YEkh_a for ; Mon, 5 Feb 2018 23:01:32 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D438126CD8 for ; Mon, 5 Feb 2018 23:01:32 -0800 (PST) Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w166qtBE010479; Tue, 6 Feb 2018 02:01:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=cjahLOMGZtQHH83J95OuArgiSrD4L4R5zR9xqznsPZw=; b=CUqagmuBbT51ZFn8oHE11Ed0YIkTklRRq65A97PJcQv41XtTRduxqthJutgA6g1Xmam4 ab6tbKFxkkQeHmhkoVULmIm5o//CFoJNDyIEDFfjYo0+KYNARGV+NeiuwCeQpXvxv4Ho pSRa95DAxOd12UJ/FZ6q8/O8uoTpJzo5wy/vCUbR+2+ZI5kMftDT/yWHFp5Ky+TbfKUu t6iZjlL9baA3ng9UGlQW7Q0ZI3Jx34Urz4bvyAqf5WzqJpKZhrQQRq488hsfi18a1iLY xiEosZc1REMjHP+KAhhF5KE0L3bfyaJKy6JM6nSzkdKdZuVmD7uJt6n3FKXW/zH2cR/5 sg== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2fwa9cw082-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 06 Feb 2018 02:01:28 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.236]) by stntexhc10.cis.neustar.com ([169.254.4.133]) with mapi id 14.03.0279.002; Tue, 6 Feb 2018 02:01:28 -0500 From: "Peterson, Jon" To: Christer Holmberg , "Peterson, Jon" , Julio Martinez-Minguito , Chris Wendt CC: "stir@ietf.org" Thread-Topic: [EXTERNAL] Re: [stir] PASSPorT: "orig" and "dest" mandatory in all PASSPorTs? Thread-Index: AQHTmhhNxwncwLCIhkCTLcv50WoH5KOUS3IggAJ+rAA= Date: Tue, 6 Feb 2018 07:01:27 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C153603@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C153603@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.13.146] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-06_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802060084 Archived-At: Subject: Re: [stir] [EXTERNAL] Re: PASSPorT: "orig" and "dest" mandatory in all PASSPorTs? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 07:01:35 -0000 DQoNCk9uIDIvNC8xOCwgNzoyNyBBTSwgIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPg0Kd3JvdGU6DQoNCj5FdmVuIGlmIHlvdSBoYW5kIHRoZSB2ZXJp ZmljYXRpb24gc2VydmljZSBhIHNpbmdsZSBJZGVudGl0eSBoZWFkZXINCj5maWVsZHMsIHdoaWNo IGNvbnRhaW5zIGVtYmVkZGVkIGNsYWltcyBmcm9tIE4gSWRlbnRpdHkgaGVhZGVyIGZpZWxkcywg dGhlDQo+dmVyaWZpY2F0aW9uIHNlcnZpY2Ugc3RpbGwgaGF2ZSB0byBmaWd1cmUgb3V0IHdoYXQg Z29lcyB3aXRoIHdoYXQsDQo+ZG9lc24ndCBpdD8NCg0KVGhlIHBvaW50IG9mIG5lc3RpbmcgaXMg dG8gb3JkZXIgdGhlIHN0YWNrLCBhbmQgY29ycmVsYXRlIHJldGFyZ2V0cyB3aXRoDQpwcmV2aW91 cyB0YXJnZXRzLiBTbyBJIGhvcGUgdGhhdCBpdCBpcyBleHBsaWNpdCBhYm91dCB3aGF0IGdvZXMg d2l0aCB3aGF0Lg0KDQo+DQo+Pi0gYnV0IHRoZXJlIGFyZSBhIGZldyBwb3RlbnRpYWwgcGl0ZmFs bHMgdGhlcmUgd2UgbmVlZCB0byBhdm9pZCwgb3IgYXQNCj4+bGVhc3QgY2FyZWZ1bGx5IG1hcmsu DQo+DQo+QXNzdW1lIHRoZSBmb2xsb3dpbmc6DQoNClllYWggdGhpcyB0aGUgc29ydCBvZiB0aGlu ZyBJIG1lYW50IGJ5IHBpdGZhbGxzLg0KDQo+IA0KPjEgLiBUaGUgIm9yaWdpbmFsIiAocHJlLTN4 eCkgSU5WSVRFIHRyYXZlcnNlcyBwcm94aWVzIFAxIGFuZCBQMi4gRWFjaCBvZg0KPnRob3NlIHBy b3hpZXMgaW5zZXJ0IGEgY2xhaW0uDQoNCi4uIGluIHNlcGFyYXRlIElkZW50aXR5IGhlYWRlcnMs IEkgYXNzdW1lLg0KDQo+Mi4gIFRoZSBJTlZJVEUgdGhlbiByZWFjaGVzIFAzLCB3aGljaCBkZWNp ZGVzIHRvIHNlbmQgYSAzeHggcmVzcG9uc2UuIEl0DQo+aW5jbHVkZXMgYSBuZXN0ZWQgUEFTU3Bv clQsIHdpdGggdGhlIGNsYWltcyBmcm9tIFAxIGFuZCBQMiAoYW5kIHBvc3NpYmx5DQo+UDMpIGlu IHRoZSByZXNwb25zZXMuDQoNCi4uLiBpbiB0aGlzIGNhc2UgdGhlIHJlZGlyZWN0aW5nIHNlcnZp Y2Ugd291bGQgbmVlZCB0byBoYXZlIGEgd2F5IHRvIHNlbmQNCnR3byBuZXN0ZWQgUEFTU3BvclRz IGluIHRoZSBiYWNrd2FyZHMgZGlyZWN0aW9uIChvbmUgZm9yIHRoZSBQMSBQQVNTcG9yVA0KYW5k IG9uZSBmb3IgdGhlIFAyIFBBU1Nwb3JUKTsgd2UgZG8gbmVlZCBhIHdheSB0byBkbyB0aGF0Lg0K DQo+My4gIFRoZSAzeHggcmVhY2hlcyB0aGUgVUEsIHdoaWNoIHNlbmRzIGEgIm5ldyIgSU5WSVRF LCB3aGljaCBjb250YWlucw0KPnRoZSBuZXN0ZWQgUEFTU3BvclQgcHJvdmlkZWQgaW4gdGhlIDN4 eC4NCg0KLi4uIGluIGdlbmVyYWwsIGNhc2VzIHdoZXJlIHRoZSAzeHggYWN0dWFsbHkgcmVhY2hl cyB0aGUgVUEgZG9uJ3Qgd29ycnkgbWUNCmFzIG11Y2ggYXMgb25lcyB3aGVyZSBhIGhlbHBmdWwg aW50ZXJtZWRpYXJ5IGludGVydmVuZXMuIElmIHRoZSAzeHgNCnJlYWNoZXMgdGhlIFVBLCB0aGUg VUEgY2FuIGp1c3Qgc2VuZCBhIG5ldyBJTlZJVEUgd2hpY2ggd2lsbCBnbyBiYWNrDQp0aHJvdWdo IFAxIGFuZCBQMiAob3IgbWF5YmUgYXMgeW91IGhhdmUgaXQgYmVsb3cgc29tZSBvdGhlciBBUykg YW5kIHRoZXkNCmNhbiBtZXJyaWx5IGFkZCBmcmVzaCBJZGVudGl0eSBoZWFkZXJzIHRvIGl0IHJl ZmxlY3RpbmcgdGhlIG5ldyB0YXJnZXQuDQpUaGUgcmVhc29uIHdoeSBJJ20gbm90IHN1cGVyIGNv bmNlcm5lZCBhYm91dCB0aGlzIGNhc2UgaXMgYmVjYXVzZSB0aGUgU1RJUg0Kc2NvcGUgaXMgbGlt aXRlZCB0byB0cnlpbmcgdG8gY29udmV5IHRoZSBpZGVudGl0eSBvZiB0aGUgb3JpZ2luYXRvciB0 bw0KcHJldmVudCBzcG9vZmluZywgbm90IHRvIHJlY29yZCBzZXJ2aWNlIGxvZ2ljIGxpa2UgSGlz dG9yeS1JbmZvIGRvZXMuIElmDQp0aGUgVUFDIGdldHMgdGhlIGNoYW5jZSB0byBzZW5kIGEgbmV3 IElOVklURSwgaXQgd2lsbCBnZXQgYSBuZXcgSWRlbnRpdHkNCnNpZ25hdHVyZSBxdWl0ZSByb3V0 aW5lbHkuDQoNCj40LiAgVGhlIG5ldyBJTlZJVEUgcmVhY2hlcyBQMyBhbmQgUDQsIGFuZCBldmVu dHVhbGx5IGEgdmVyaWZpZXIuIFRoZQ0KPklkZW50aXR5IGhlYWRlciB3aWxsIGNvbnRhaW4gdGhl IGNsYWltcyBvZiBQMSBhbmQgUDIuIElzIHRoYXQgdGhlDQo+aW50ZW50aW9uPyBJcyB0aGUgdmVy aWZpZXIgc3VwcG9zZWQgdG8gdmVyaWZ5IHRob3NlPyBXaGF0IGlmIHRoZQ0KPnZlcmlmaWNhdGlv biBmYWlscz8gU2hvdWxkIHRoZSB2ZXJpZmllciByZWplY3QgdGhlIHJlcXVlc3QsIGV2ZW4gaWYg UDENCj5hbmQgUDIgYXJlIG5vIGxvbmdlciBhc3NvY2lhdGVkIHdpdGggdGhlIGNhbGw/DQoNCk9y ZGluYXJpbHkgdGhlcmUgd291bGQgYmUgbm8gcmVhc29uIGZvciBhIG5ldyBJTlZJVEUgLSBvbmUg cmVzdWx0aW5nIGZyb20NCmEgM3h4IHRoYXQgaGFkIHJlYWNoZWQgdGhlIFVBQyAtIHRvIGNhcnJ5 IHRoZSBjbGFpbXMgb2YgUDEgYW5kIFAyLg0KDQo+SWYgdGhpcyB3aWxsIGJlIGNsYXJpZmllZCBp biB0aGUgbmV4dCB2ZXJzaW9uLCBJIGNhbiB3YWl0IGZvciB0aGUgYW5zd2VyDQo+OikNCg0KVGhl IGFib3ZlIGlzIGJhc2ljYWxseSB3aGF0IEkgaGF2ZSBpbiBtaW5kLCBhbnl3YXksIGZvciB0aGUg cmV2aXNpb24uIFRvDQp0cnkgdG8ga2VlcCB0aGlzIHNpbXBsZSwgZm9jdXNlZCBvbiB0aGUgaW1w ZXJzb25hdGlvbiBhdHRhY2ssIHJhdGhlciB0aGFuDQp0cnlpbmcgdG8gc2lnbiBzZXJ2aWNlIGxv Z2ljIGRlY2lzaW9ucy4gVGhlIG5ldyByZWRpcmVjdGlvbiB0ZXh0IGlzDQpiYXNpY2FsbHkgdG8g aGFuZGxlIHRoZSBjYXNlIHdoZXJlIHRoZSBJTlZJVEUgZG9lcyBub3QgcmVhY2ggdGhlIFVBLCB3 aGVyZQ0Kc29tZSBpbnRlcm1lZGlhcnkgZXhwbG9yZXMgYSBuZXcgdGFyZ2V0LCB0aGF0IHRob3Nl IG5lc3RlZCBQQVNTcG9yVHMgYXJlDQpyZWxldmFudCBoZXJlLg0KDQpJZiB0aGF0IHNjb3BlIHNl ZW1zIGluc3VmZmljaWVudCBvciBtaXNndWlkZWQsIGxldCdzIHRhbGsgYWJvdXQgaXQgbW9yZS4N Cg0KPkluIGFkZGl0aW9uLCBQMyBhbmQgUDQgbWF5IGFkZCB0aGVpciBvd24gY2xhaW1zLCBpbiBz ZXBhcmF0ZSBJZGVudGl0eQ0KPmhlYWRlciBmaWVsZHMsIHNvIHRoZXJlIHdvdWxkIGJlIG9uZSBJ ZGVudGl0eSBoZWFkZXIgZmllbGQgd2l0aCB0aGUNCj5uZXN0ZWQgY2xhaW0gKHJlY2VpdmVkIGlu IHRoZSAzeHggcmVzcG9uc2UpLCBmb2xsb3dlZCBieSB0aGUgSWRlbnRpdHkNCj5oZWFkZXIgZmll bGRzIGFkZGVkIGJ5IFAzIGFuZCBQNC4gUGVyaGFwcyB0aGF0IGlzIG5vdCBhIHByb2JsZW0sIGJ1 dCBJDQo+anVzdCBob3BlIHdlIGRvbid0IG1ha2UgYXNzdW1wdGlvbnMgcmVnYXJkaW5nIHRoZSBu dW1iZXIgYW5kIGNvbWJpbmF0aW9ucw0KPm9mIElkZW50aXR5IGhlYWRlciBmaWVsZHMuLi4NCg0K SW4gZ2VuZXJhbCwgSSBkb24ndCBrbm93IHdoeSBjaGFuZ2luZyB0aGUgdGFyZ2V0IHNob3VsZCBy ZXN1bHQgaW4NCmRpZmZlcmVudCBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlcyB3YW50aW5nIHRvIGFk ZCBQQVNTcG9yVHMgdG8gYSBjYWxsLCBhbmQNCkknbSBraW5kIG9mIGFmcmFpZCB0byBoZWFyIHRo ZSByYXRpb25hbGUgZm9yIGl0LiBJIG1lYW4sIEkgY2FuIGNvbnN0cnVlIGENCnJlYXNvbiBmb3Ig c29tZSBjb3JuZXIgY2FzZXMsIGJ1dCBpbiBvcmRpbmFyeSBvcGVyYXRpb25zLCB3ZSBob3BlIHRo ZQ0KYWRtaW5pc3RyYXRpdmUgZG9tYWluIG9mIHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBjYWxsIHdp bGwgYmUgYWJsZSB0byBzaWduDQpQQVNTcG9yVHMgZm9yIGl0LCBhbmQgdGhhdCBpdCB3b24ndCBi ZSBzbyBkZXN0aW5hdGlvbi1kZXBlbmRlbnQuDQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5j Lg0KDQo+DQo+UmVnYXJkcywNCj4NCj5DaHJpc3Rlcg0KPg0KPg0KPg0KPk9uIDEvMjYvMTgsIDk6 MjcgQU0sICJzdGlyIG9uIGJlaGFsZiBvZiBKdWxpbyBNYXJ0aW5lei1NaW5ndWl0byINCj48c3Rp ci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqdWxpby5tYXJ0aW5lei1taW5ndWl0b0Bl cmljc3Nvbi5jb20+DQo+d3JvdGU6DQo+DQo+PkhpLA0KPj4NCj4+SSBzZWUgaW4gdGhlIG5lc3Rl ZCBkaXZlcnQgdGhhdCB0aGUgbmV3IFBBU1Nwb3JUIGhhcyBhIGNsYWltICJvcHQiDQo+PndoaWNo IGluY2x1ZGVzIHRoZSBQQVNTcG9yVCBvZiB0aGUgb3JpZ2luYXRpbmcgbmV0d29yaywgaW5jbHVk aW5nIHRoZQ0KPj5zaWduYXR1cmUuDQo+PlRoZSBQQVNTcG9yVCBhZGRlZCBieSB0aGUgZGl2ZXJ0 aW5nIG5ldHdvcmsgaW5jbHVkZXMgYSBjbGFpbSAib3JpZyIsDQo+PndoaWNoIGlzIGNvcGllZCBm cm9tIHRoZSAnb3JpZ2luYWwnIFBBU1Nwb3JULg0KPj5JbiB0aGlzIGNhc2UgLCBmb3IgYSBQQVNT cG9yVCBwcHQ6ZGl2LCB0aGUgZGl2ZXJ0aW5nIG5ldHdvcmsgbWF5cyBub3QNCj4+aGF2ZSBhdXRo b3JpdHkgb3ZlciB0aGUgY2xhaW0gIm9yaWciLCBidXQgb25seSBvdmVyIHRoZSBjbGFpbSAnZGl2 Jy4gQQ0KPj52ZXJpZmllciB3aWxsIGhhdmUgdG8gY2hlY2sgdGhlIGVtYmVkZGVkIFBBU1Nwb3JU LCB2ZXJpZnkgdGhlIHNpZ25hdHVyZQ0KPj5hbmQgY2hlY2sgdGhhdCB0aGUgb3JpZyBpbiB0aGUg ZGlmZmVyZW50IFBBU1Nwb3JUIG1hdGNoZXMuDQo+Pg0KPj5UaG91Z2ggaW4gYW5vdGhlciBjYXNl cywgaWYgdGhlIG9yaWdpbmF0aW5nIG51bWJlciBhbmQgdGhlIGRpdmVydGluZw0KPj5hcmUgc2Vy dmVkIGJ5IHRoZSBzYW1lIG9wZXJhdG9yLCB0aGUgb3BlcmF0b3IgaGFzIGF1dGhvcml0eSBvdmVy IGJvdGgNCj4+b3JpZyBhbmQgZGl2IGNsYWltcy4gQSBuZXN0ZWQgUEFTU3BvclQgd291bGQgbm90 IGJlIG5lZWRlZCBpbiB0aGlzIGNhc2UuDQo+Pg0KPj5UaGUgZW5kIHJlc3VsdCBpcyBxdWl0ZSBz aW1pbGFyIGFzIGlmIHdlIGhhdmUgbXVsdGlwbGUgSWRlbnRpdHkgaGVhZGVycy4NCj4+SW4gdGhl IGVuZCB0aGVyZSBhcmUgbXVsdGlwbGUgUEFTU3BvclQgb2JqZWN0cywgdGhlIGRpZmZlcmVuY2Ug aXMgaG93DQo+PnRoZXkgYXJlIGNvbnZleWVkIGluIHRoZSBzaWduYWxpbmcuDQo+Pg0KPj5JIGFz c3VtZSB0aGUgbWFpbiByZWFzb24gZm9yIHRoZSBlbWJlZGRpbmcgaXMgYmVjYXVzZSBvZiB0aGUg b29iDQo+PnNvbHV0aW9uLCBvcj8NCj4+DQo+PlJlZ2FyZHMsIEp1bGlvDQo+Pg0KPj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQo+Pj4gU2VudDogZGVuIDI0IGphbnVh cmkgMjAxOCAxNTowNg0KPj4+IFRvOiBDaHJpcyBXZW5kdCA8Y2hyaXMtaWV0ZkBjaHJpc3dlbmR0 Lm5ldD4NCj4+PiBDYzogc3RpckBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbc3Rpcl0gUEFT U1BvclQ6ICJvcmlnIiBhbmQgImRlc3QiIG1hbmRhdG9yeSBpbiBhbGwNCj4+PlBBU1NQb3JUcz8N Cj4+PiANCj4+PiBIaSwNCj4+PiANCj4+PiA+SSBndWVzcyBpqfZtIG5vdCBmb2xsb3dpbmcgd2hh dKn2cyBub3QgY2xlYXIsIGlmIHlvdSBNVVNUIG9ubHkgaGF2ZQ0KPj4+ID5vbmUgb3JpZyBjbGFp bSBhbmQgb25lIGlkZW50aXR5IGluIHRoYXQgY2xhaW0sIHRoYXQgc2VlbXMgdG8gYmUNCj4+PiA+ cHJldHR5IGNsZWFyIHRvIG1lIHRoYXQgeW91IGNhbm5vdCBlaXRoZXIgbm90IGhhdmUgYW4gb3Jp ZyBjbGFpbSBvcg0KPj4+ID5oYXZlIG1vcmUgdGhhbiBvbmUuICBJIGd1ZXNzIG1heWJlIGmp9m0g bWlzc2luZyBzb21ldGhpbmcgc3VidGxlIGluDQo+Pj55b3VyIHBvaW50Lg0KPj4+IA0KPj4+IEl0 IGlzIGNsZWFyIHRoYXQgeW91IGNhbm5vdCBoYXZlIG1vcmUgdGhhbiBvbmUgY2xhaW0sIGJ1dCBJ IHRoaW5rIGl0DQo+Pj5jb3VsZCBiZSAgbWFkZSBtb3JlIGNsZWFyIHRoYXQgeW91IGFsd2F5cyBt dXN0IGhhdmUgYSBjbGFpbSB0byBiZWdpbg0KPj4+d2l0aCA6KQ0KPj4+IA0KPj4+ID5Gb3IgZXh0 ZW5zaW9ucywgYW5kIGluIGdlbmVyYWwgd2l0aCBhbnkgUEFTU3BvclQsIG9uY2UgdGhlIFBBU1Nw b3JUDQo+Pj4gPmlzIHNpZ25lZCwgdGhhdKn2cyBpdCwgeW91IGNhbm5vdCBtb2RpZnkgY2xhaW1z IG9yICJyZS1zaWduIi4gIElmIHlvdQ0KPj4+ID53YW50IG5ldyBQQVNTcG9yVCBjbGFpbSBpbmZv cm1hdGlvbiB0aGF0IHlvdSB3YW50IHRvIHNpZ24sIHlvdSBtdXN0DQo+Pj4gPmhhdmUgYSBuZXcg UEFTU3BvclQgb3IgbmV3IGlkZW50aXR5IGhlYWRlci4NCj4+PiANCj4+PiBDb3JyZWN0LCBJIHNo b3VsZCBoYXZlIG1hZGUgdGhhdCBjbGVhci4NCj4+PiANCj4+PiBTbywgaWYgeW91IGhhdmUgdHdv IChvciBtb3JlKSBJZGVudGl0eSBoZWFkZXIgZmllbGRzLCBkbyB0aGV5IGFsbA0KPj4+aGF2ZSB0 byAgY29udGFpbiB0aGUgc2FtZSCp+G9yaWep9yB2YWx1ZT8gT3IsIGlzIG9uZSBhbGxvd2VkIHRv IGNoYW5nZQ0KPj4+aXQ/DQo+Pj4gDQo+Pj4gRG9lcyB0aGUgc2FtZSBhcHBseSBmb3IgqfhkZXN0 qfc/IEFuZCwgaWYgeW91IHdhbnQgdG8gY2hhbmdlIHRoZSCp+GRlc3Sp9w0KPj4+eW91ICBuZWVk IHRvIHVzZSB0aGUgZGl2ZXJ0IGV4dGVuc2lvbj8gWW91IGNhbqn2dCBqdXN0IGFkZCBhIG5ldw0K Pj4+cGFzc3BvcnQgd2l0aCBhICBuZXcgqfhkZXN0qfcgdmFsdWUuIE9yPw0KPj4+IA0KPj4+ID5D dXJyZW50bHkgZm9yIGRpdmVydCwgdGhlIGFwcHJvYWNoIGlzIHRvIGVtYmVkIGEgUEFTU3BvclQg aW5zaWRlIGENCj4+PiA+bmV3IFBBU1Nwb3JULCB3aGljaCBpcyBhIHZhbGlkIHRlY2huaXF1ZSBh bHNvIGFuZCByZXN1bHQgaW4gYSBuZXcNCj4+PiA+aWRlbnRpdHkgaGVhZGVyIGFsc28gKGJ1dCB5 b3Ugc2hvdWxkIHJlbW92ZSB0aGUgb2xkIGlkZW50aXR5IGhlYWRlcg0KPj4+ID5pbiB0aGlzDQo+ Pj5jYXNlKS4NCj4+PiANCj4+PiBNeSBjb2xsZWFndWUgSnVsaW8gc2VudCBzb21lIHF1ZXN0aW9u cyBhbmQgaXNzdWVzIHJlZ2FyZGluZyB0aGUNCj4+PiCp+GVtYmVkZGluZ6n3L6n4bmVzdGluZ6n3 IGFwcHJvYWNoLiBJIHdvdWxkIGJlIGhhcHB5IGlmIHlvdSBsb29rIGF0IHRob3NlDQo+Pj4gOikN Cj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IA0KPj4+IENocmlzdGVyDQo+Pj4gDQo+Pj4gDQo+Pj4g Pg0KPj4+ID4tQ2hyaXMNCj4+PiA+DQo+Pj4gPj4gT24gSmFuIDIzLCAyMDE4LCBhdCAyOjE5IFBN LCBDaHJpc3RlciBIb2xtYmVyZw0KPj4+ID4+PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4gd3JvdGU6DQo+Pj4gPj4NCj4+PiA+PiBIaSBDaHJpcywNCj4+PiA+Pg0KPj4+ID4+Pj4gUXVl c3Rpb24gZm9yIGNsYXJpZmljYXRpb246DQo+Pj4gPj4+Pg0KPj4+ID4+Pj4gU2VjdGlvbiA1LjIu MSBvZiBkcmFmdC1wYXNzcG9ydCBzYXlzOg0KPj4+ID4+Pj4NCj4+PiA+Pj4+ICAgICAgIlRoZXJl IE1VU1QgYmUgZXhhY3RseSBvbmUgIm9yaWciIGNsYWltIHdpdGggZXhhY3RseSBvbmUNCj4+PiA+ Pj4+aWRlbnRpdHkgY2xhaW0gb2JqZWN0IGluIGEgUEFTU3BvclQgb2JqZWN0LiINCj4+PiA+Pj4+ DQo+Pj4gPj4+PiBRMTogRG9lcyB0aGUgdGV4dCBhYm92ZSBtZWFuIHRoYXQNCj4+PiA+Pj4+DQo+ Pj4gPj4+PiAgICAgIGEpIGEgcGFzc3BvcnQgbXVzdCBhbHdheXMgY29udGFpbiBvbmUsIG9uZSBv bmx5IG9uZSwgIm9yaWciDQo+Pj4gPj4+PmNsYWltOyBvcg0KPj4+ID4+Pj4gICAgICBiKSB0aGF0 IGlmIGEgcGFzc3BvcnQgY29udGFpbnMgYW4gIm9yaWciIGNsYWltLCBpZiBjYW4gb25seQ0KPj4+ ID4+Pj5jb250YWlucyBvbmU/DQo+Pj4gPj4+DQo+Pj4gPj4+IEl0IGNhbiBvbmx5IGNvbnRhaW4g b25lIGtleSB2YWx1ZSBwYWlyIHdpdGggdGhlIGtleSCp+G9yaWep9yBhbmQNCj4+PiA+Pj50aGUg Y2xhaW0gdmFsdWUgY2FuIG9ubHkgYmUgb25lIGlkZW50aXR5Lg0KPj4+ID4+Pg0KPj4+ID4+PiBJ biBvdGhlciB3b3JkcyB5b3UgY2Fubm90IGNsYWltIHRvIG9yaWdpbmF0ZSBtdWx0aXBsZSBpZGVu dGl0aWVzDQo+Pj4gPj4+d2l0aCBhIHNpbmdsZSBwYXNzcG9ydCBvYmplY3QuDQo+Pj4gPj4NCj4+ PiA+PiBDb3JyZWN0LiBUaGUgcXVlc3Rpb24gaXMgd2hldGhlciAib3JpZyIgaXMgbWFuZGF0b3J5 IChhbHRlcm5hdGl2ZQ0KPj4+ID4+YSkgb3Igbm90IChhbHRlcm5hdGl2ZSBiKS4gQnV0LCBiYXNl ZCBvbiB5b3VyIHJlcGx5IHRvIFEyIGJlbG93LCBJDQo+Pj4gPj5hc3N1bWUgdGhlIGFuc3dlciBp cyBhbHRlcm5hdGl2ZSBhKS4NCj4+PiA+Pg0KPj4+ID4+IEkgdGhpbmsgaXQgd291bGQgYmUgZ29v ZCB0byBtYWtlIHRoYXQgbW9yZSBjbGVhci4NCj4+PiA+Pg0KPj4+ID4+Pj4gUTI6IElmIGEpLCBk b2VzIGl0IGFwcGx5IHRvIHBhc3Nwb3J0IGV4dGVuc2lvbnMgdG9vPw0KPj4+ID4+Pg0KPj4+ID4+ PiBBbGwgZXh0ZW5zaW9ucyBtdXN0IGluY2x1ZGUgdGhlIGJhc2UgcGFzc3BvcnQgY2xhaW1zIGFu ZCBmb2xsb3cNCj4+PiA+Pj5hbGwgcnVsZXMgb2YgdGhlIGNsYWltcywgc28geWVzLg0KPj4+ID4+ DQo+Pj4gPj4gSSB0aGluayBpdCBzaG91bGQgYmUgbW9yZSBjbGVhciB3aGV0aGVyIGEgbm9kZSBj YW4gbW9kaWZ5IGNsYWltcw0KPj4+ID4+b3Igbm90IHdoZW4gYWRkaW5nIGFuIGV4dGVuc2lvbiwg b3Igd2hldGhlciBhbiBleHRlbnNpb24gbmVlZHMgdG8NCj4+PiA+PmV4cGxpY2l0bHkgYWxsb3cg aXQuIEN1cnJlbnRseSB0aGUgdGV4dCBvbmx5IHNheXMgKEFGQUlLKSB0aGF0DQo+Pj4gPj5jbGFp bXMgY2Fubm90IGJlIHJlbW92ZWQuDQo+Pj4gPj4NCj4+PiA+PiBGb3IgZXhhbXBsZSwgaWYgSSBo YXZlIGEgYmFzZSBwYXNzcG9ydCwgYW5kIGFkZCBhbiBSUEggcGFzc3BvcnQsIEkNCj4+PiA+PmFz c3VtZSBJIGNhbm5vdCBjaGFuZ2UgdGhlIHZhbHVlIG9mIHRoZSAiZGVzdCIgY2xhaW0uIEkgd291 bGQgbmVlZA0KPj4+ID4+dG8gdXNlIGEgZGl2ZXJ0IGNsYWltIGZvciB0aGF0Lg0KPj4+ID4+DQo+ Pj4gPj4gQWxzbywgYXMgdGhlIHBhc3Nwb3J0cyBtYXkgYmUgYWRkZWQgYW5kIHNpZ25lZCBieSBk aWZmZXJlbnQNCj4+PiA+PmF1dGhvcml0aWVzLCBhbmQgYXMgZWFjaCBwYXNzcG9ydCB3aWxsIGNv bnRhaW4gdGhlIGJhc2UgY2xhaW1zLCBpdA0KPj4+ID4+bWVhbnMgdGhhdCB0aGUgYmFzZSBjbGFp bXMgd2lsbCBiZSBzaWduZWQgbXVsdGlwbGUgdGltZXMsIGFuZCB0aGV5DQo+Pj4gPj5tYXkgYmUg c2lnbmVkIGJ5IGRpZmZlcmVudCBhdXRob3JpdGllcy4gSSBhc3N1bWUgdGhhdCBpcyBvay4NCj4+ PiA+Pg0KPj4+ID4+IFJlZ2FyZHMsDQo+Pj4gPj4NCj4+PiA+PiBDaHJpc3Rlcg0KPj4+ID4+DQo+ Pj4gPg0KPj4+IA0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+c3RpciBtYWlsaW5nIGxpc3QNCj4+c3RpckBpZXRmLm9yZw0KPj5odHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbQ0KPj5hbl8gDQo+Pmxpc3RpbmZvX3N0aXImZD1Ed0lGQXcmYz1NT3B0TmxWdElFVGVE QUxDX2xVTHJ3JnI9ZFE1MXRMZm9HdXVGamFubWZlS0MwDQo+PndlWCANCj4+SE5NbDl4Wm5uc0lp d1JkNklnWSZtPUNZRUtRZXR4b1lKRldrQ1lsVGpVTEk0Y3VYWXRzd2Mta3NnQU5IV09EejAmcz1u OG4NCj4+NVhuIExvSEgxTjlxVlROZFdDbjVWTlVjUUlRTWFqTjIxcVRpdmJuRDgmZT0NCj4NCg0K From nobody Tue Feb 6 08:22:35 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B94A12D84B for ; Tue, 6 Feb 2018 08:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 MU87JgynAK_S for ; Tue, 6 Feb 2018 08:22:26 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7ED127078 for ; Tue, 6 Feb 2018 08:22:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517934143; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wa2zePXPGQsPzKQqDInmfHiNLk9afEYDwDA3zh9im3g=; b=bciBXLu1jt2lMTaiLl3xHFzYvxELXIui6cl5ndacictGdRJpoHUFH0EgCBHyw34W apkQd5D/dLCQOOnRlkinLCble/96dE/Fb43NJb5Cwq4A0cU5bQsGKSl2f70D4PXW 1PdtjNLWGl4D4wf/QRfnDFbOqRkM5MEIxtcFZC4Ur3A=; X-AuditID: c1b4fb3a-35fff700000067b4-80-5a79d63f372e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 24.36.26548.F36D97A5; Tue, 6 Feb 2018 17:22:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Tue, 6 Feb 2018 17:22:23 +0100 From: Christer Holmberg To: "Peterson, Jon" , Julio Martinez-Minguito , Chris Wendt CC: "stir@ietf.org" Thread-Topic: [EXTERNAL] Re: [stir] PASSPorT: "orig" and "dest" mandatory in all PASSPorTs? Thread-Index: AQHTmhhNxwncwLCIhkCTLcv50WoH5KOUS3IggAJ+rACAAL5LkA== Date: Tue, 6 Feb 2018 16:22:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C15A08D@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C153603@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdUtf+WmWUwdF/VhbTP+1mttj8bA2T xfK125gcmD0m9K1h9Viy5CeTx+sNc9gDmKO4bFJSczLLUov07RK4Mt7t7mcsuBJY0dQ+la2B 8Y5jFyMHh4SAicTBvqguRi4OIYHDjBJ3ejqYIJzFjBLX99xmAiliE7CQ6P6nDRIXEZjDKLG4 bTMrSJxZQFni3277LkZODmGBGImr3ddYQGwRgViJzYvOsEPYThLNPzeAxVkEVCR+vHsNZvMK +Erc+HmQHWLXckaJC9+nsYIkOAXMJbZOX8MEYjMKiEl8PwVhMwuIS9x6Mh/MlhAQkFiy5zwz hC0q8fLxP1YIW0li7eHtLBD1ehI3pk5hg7C1JZYtfM0MsVhQ4uTMJywTGEVnIRk7C0nLLCQt s5C0LGBkWcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGDsHt/y22sF48LnjIUYBDkYlHt4v JyqjhFgTy4orcw8xSnAwK4nwBm0CCvGmJFZWpRblxxeV5qQWH2KU5mBREud1SrOIEhJITyxJ zU5NLUgtgskycXBKNTBOdeo/qH9oieZniULNOK/Tb/8tEfJ5vefpd+f5DRlbFpa9qTzfHLIw c3LzjoVPTMvrJpZqcMjs1Wc+OqN72c0Xl/4+69Q47B6xyHCCrYiIxb0HXhmvjAr+FURfPM/E vq869kNbZoK1CHPl3aVn3384dHPmiez6bS964gMqJSI53rsrb3dW7tmqxFKckWioxVxUnAgA t+HmnJkCAAA= Archived-At: Subject: Re: [stir] [EXTERNAL] Re: PASSPorT: "orig" and "dest" mandatory in all PASSPorTs? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 16:22:33 -0000 Hi, >>Even if you hand the verification service a single Identity header=20 >>fields, which contains embedded claims from N Identity header fields,=20 >>the verification service still have to figure out what goes with what,=20 >>doesn't it? > > The point of nesting is to order the stack, and correlate retargets with = previous targets. So I hope that it is explicit about what goes with what. > >>1 . The "original" (pre-3xx) INVITE traverses proxies P1 and P2. Each=20 >>of those proxies insert a claim. > >.. in separate Identity headers, I assume. Maybe, maybe not. For example, P2 may have done a retarget (with nesting), = in which case I assume there would be a single Identity header field.=20 (It is a little unclear to me whether nesting is supposed to be for retarge= t only, or whether it's to be something more generic that can also be used = for other types of PASSPortT extensions.) >>2. The INVITE then reaches P3, which decides to send a 3xx response.=20 >>It includes a nested PASSporT, with the claims from P1 and P2 (and=20 >>possibly P3) in the responses. > > ... in this case the redirecting service would need to have a way to send= two nested PASSporTs in the backwards=20 > direction (one for the P1 PASSporT and one for the P2 PASSporT); we do ne= ed a way to do that. > >>3. The 3xx reaches the UA, which sends a "new" INVITE, which contains=20 >>the nested PASSporT provided in the 3xx. > >... in general, cases where the 3xx actually reaches the UA don't worry me= as much as ones where a helpful intermediary intervenes. > If the 3xx reaches the UA, the UA can just send a new INVITE which will g= o back through P1 and P2 (or maybe as you have it below=20 > some other AS) and they can merrily add fresh Identity headers to it refl= ecting the new target. > >>The reason why I'm not super concerned about this case is because the STI= R scope is limited to trying to convey the identity of the originator to=20 >>prevent spoofing, not to record service logic like History-Info does. If = the UAC gets the chance to send a new INVITE, it will get a new Identity si= gnature quite routinely. >> >>4. The new INVITE reaches P3 and P4, and eventually a verifier. The=20 >>>Identity header will contain the claims of P1 and P2. Is that the=20 >>intention? Is the verifier supposed to verify those? What if the=20 >>verification fails? Should the verifier reject the request, even if P1=20 >>and P2 are no longer associated with the call? > > Ordinarily there would be no reason for a new INVITE - one resulting from= a 3xx that had reached the UAC - to carry the claims of P1 and P2. Ok. Of course, the 3xx reaching the UA was only an example. The 3xx could have= been terminated e.g., by P1. >>If this will be clarified in the next version, I can wait for the=20 >>answer :) > > The above is basically what I have in mind, anyway, for the revision. To = try to keep this simple, focused on the=20 > impersonation attack, rather than trying to sign service logic decisions.= The new redirection text is basically to=20 > handle the case where the INVITE does not reach the UA, where some interm= ediary explores a new target, that=20 > those nested PASSporTs are relevant here. > > If that scope seems insufficient or misguided, let's talk about it more. > >In addition, P3 and P4 may add their own claims, in separate Identity=20 >header fields, so there would be one Identity header field with the=20 >nested claim (received in the 3xx response), followed by the Identity=20 >header fields added by P3 and P4. Perhaps that is not a problem, but I=20 >just hope we don't make assumptions regarding the number and=20 >combinations of Identity header fields... > > In general, I don't know why changing the target should result in differe= nt authentication services wanting to add PASSporTs to=20 > a call, and I'm kind of afraid to hear the rationale for it. I mean, I ca= n construe a reason for some corner cases, but in ordinary=20 > operations, we hope the administrative domain of the originator of the ca= ll will be able to sign PASSporTs for it, and that it won't be so destinati= on-dependent. For the originator, I agree. But, PASSportTs can be added also by others, e= .g., in the case of retarget. So, there could be a case where a call is ret= argeted, and later redirected. Regards, Christer >On 1/26/18, 9:27 AM, "stir on behalf of Julio Martinez-Minguito" >julio.martinez-minguito@ericsson.com> >wrote: > >>Hi, >> >>I see in the nested divert that the new PASSporT has a claim "opt" >>which includes the PASSporT of the originating network, including the=20 >>signature. >>The PASSporT added by the diverting network includes a claim "orig",=20 >>which is copied from the 'original' PASSporT. >>In this case , for a PASSporT ppt:div, the diverting network mays not=20 >>have authority over the claim "orig", but only over the claim 'div'. A=20 >>verifier will have to check the embedded PASSporT, verify the=20 >>signature and check that the orig in the different PASSporT matches. >> >>Though in another cases, if the originating number and the diverting=20 >>are served by the same operator, the operator has authority over both=20 >>orig and div claims. A nested PASSporT would not be needed in this case. >> >>The end result is quite similar as if we have multiple Identity headers. >>In the end there are multiple PASSporT objects, the difference is how=20 >>they are conveyed in the signaling. >> >>I assume the main reason for the embedding is because of the oob=20 >>solution, or? >> >>Regards, Julio >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: den 24 januari 2018 15:06 >>> To: Chris Wendt >>> Cc: stir@ietf.org >>> Subject: Re: [stir] PASSPorT: "orig" and "dest" mandatory in all=20 >>>PASSPorTs? >>>=20 >>> Hi, >>>=20 >>> >I guess i=B9m not following what=B9s not clear, if you MUST only have= =20 >>> >one orig claim and one identity in that claim, that seems to be=20 >>> >pretty clear to me that you cannot either not have an orig claim or=20 >>> >have more than one. I guess maybe i=B9m missing something subtle in >>>your point. >>>=20 >>> It is clear that you cannot have more than one claim, but I think it=20 >>>could be made more clear that you always must have a claim to begin=20 >>>with :) >>>=20 >>> >For extensions, and in general with any PASSporT, once the PASSporT=20 >>> >is signed, that=B9s it, you cannot modify claims or "re-sign". If=20 >>> >you want new PASSporT claim information that you want to sign, you=20 >>> >must have a new PASSporT or new identity header. >>>=20 >>> Correct, I should have made that clear. >>>=20 >>> So, if you have two (or more) Identity header fields, do they all=20 >>>have to contain the same =B3orig=B2 value? Or, is one allowed to change= =20 >>>it? >>>=20 >>> Does the same apply for =B3dest=B2? And, if you want to change the=20 >>>=B3dest=B2 you need to use the divert extension? You can=B9t just add a= =20 >>>new passport with a new =B3dest=B2 value. Or? >>>=20 >>> >Currently for divert, the approach is to embed a PASSporT inside a=20 >>> >new PASSporT, which is a valid technique also and result in a new=20 >>> >identity header also (but you should remove the old identity header=20 >>> >in this >>>case). >>>=20 >>> My colleague Julio sent some questions and issues regarding the=20 >>> =B3embedding=B2/=B3nesting=B2 approach. I would be happy if you look at= =20 >>> those >>> :) >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>> > >>> >-Chris >>> > >>> >> On Jan 23, 2018, at 2:19 PM, Christer Holmberg=20 >>> >> wrote: >>> >> >>> >> Hi Chris, >>> >> >>> >>>> Question for clarification: >>> >>>> >>> >>>> Section 5.2.1 of draft-passport says: >>> >>>> >>> >>>> "There MUST be exactly one "orig" claim with exactly one=20 >>> >>>>identity claim object in a PASSporT object." >>> >>>> >>> >>>> Q1: Does the text above mean that >>> >>>> >>> >>>> a) a passport must always contain one, one only one, "orig" >>> >>>>claim; or >>> >>>> b) that if a passport contains an "orig" claim, if can=20 >>> >>>>only contains one? >>> >>> >>> >>> It can only contain one key value pair with the key =B3orig=B2 and= =20 >>> >>>the claim value can only be one identity. >>> >>> >>> >>> In other words you cannot claim to originate multiple identities=20 >>> >>>with a single passport object. >>> >> >>> >> Correct. The question is whether "orig" is mandatory (alternative >>> >>a) or not (alternative b). But, based on your reply to Q2 below, I=20 >>> >>assume the answer is alternative a). >>> >> >>> >> I think it would be good to make that more clear. >>> >> >>> >>>> Q2: If a), does it apply to passport extensions too? >>> >>> >>> >>> All extensions must include the base passport claims and follow=20 >>> >>>all rules of the claims, so yes. >>> >> >>> >> I think it should be more clear whether a node can modify claims=20 >>> >>or not when adding an extension, or whether an extension needs to=20 >>> >>explicitly allow it. Currently the text only says (AFAIK) that=20 >>> >>claims cannot be removed. >>> >> >>> >> For example, if I have a base passport, and add an RPH passport,=20 >>> >>I assume I cannot change the value of the "dest" claim. I would=20 >>> >>need to use a divert claim for that. >>> >> >>> >> Also, as the passports may be added and signed by different=20 >>> >>authorities, and as each passport will contain the base claims, it=20 >>> >>means that the base claims will be signed multiple times, and they=20 >>> >>may be signed by different authorities. I assume that is ok. >>> >> >>> >> Regards, >>> >> >>> >> Christer >>> >> >>> > >>>=20 >> >>_______________________________________________ >>stir mailing list >>stir@ietf.org >>https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail >>m >>an_ >>listinfo_stir&d=3DDwIFAw&c=3DMOptNlVtIETeDALC_lULrw&r=3DdQ51tLfoGuuFjanmf= eKC >>0 >>weX >>HNMl9xZnnsIiwRd6IgY&m=3DCYEKQetxoYJFWkCYlTjULI4cuXYtswc-ksgANHWODz0&s=3Dn= 8 >>n 5Xn LoHH1N9qVTNdWCn5VNUcQIQMajN21qTivbnD8&e=3D > From nobody Thu Feb 8 12:08:06 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0401A127444 for ; Thu, 8 Feb 2018 12:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.78 X-Spam-Level: X-Spam-Status: No, score=0.78 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us 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 XFcdaFo1eIfu for ; Thu, 8 Feb 2018 12:08:03 -0800 (PST) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECE0127275 for ; Thu, 8 Feb 2018 12:08:03 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by qproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id DBDB56AE81 for ; Thu, 8 Feb 2018 13:08:02 -0700 (MST) Received: from box462.bluehost.com ([74.220.219.62]) by CMOut01 with id 8L7z1x00Z1MNPNq01L826D; Thu, 08 Feb 2018 13:08:02 -0700 X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=IkcTkHD0fZMA:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=Op4juWPpsa0A:10 a=jqBRFv0mrdUA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=xCrYnY0UqA0zwQtnmsMA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4y4RFkRlsJ10spDJQaxd6PiHUGiVu+zjTVuG6DTfiRQ=; b=QAWNrWPl0VdpQtumpkwR1iYnzq xUbFujc3ETCX3cfn+lPJbJ0DotPGOvJqA6oz9x6iT3QSxYgB7evQdrCSs8zS0y+B46Yuomi3kv3Ka idzRsMm9UCrsxwM79+DwJtcLP; Received: from [12.252.7.226] (port=2496 helo=[100.68.140.201]) by box462.bluehost.com with esmtpa (Exim 4.89_1) (envelope-from ) id 1ejsUA-002a4V-Vp for stir@ietf.org; Thu, 08 Feb 2018 13:07:59 -0700 User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Thu, 08 Feb 2018 14:07:58 -0600 From: Richard Shockey To: IETF STIR Mail List Message-ID: <93F92933-6D17-4410-B17A-984014D2FFFE@shockey.us> Thread-Topic: Ah .. hummmm what is going on folks with the core documents? Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 12.252.7.226 X-Exim-ID: 1ejsUA-002a4V-Vp X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([100.68.140.201]) [12.252.7.226]:2496 X-Source-Auth: richard+shockey.us X-Email-Count: 4 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [stir] Ah .. hummmm what is going on folks with the core documents? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 20:08:05 -0000 I thought these were in 48 AUTH or something?=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook =E2=80=93Twitter rshockey101 PSTN +1 703-593-2683 =20 From nobody Thu Feb 8 12:18:08 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B412D833 for ; Thu, 8 Feb 2018 12:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 HNbp8STQECLV for ; Thu, 8 Feb 2018 12:18:01 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47E2127333 for ; Thu, 8 Feb 2018 12:18:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A5DC0300A0E for ; Thu, 8 Feb 2018 15:17:59 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8xcJnYfvmf_I for ; Thu, 8 Feb 2018 15:17:58 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 737073005B5; Thu, 8 Feb 2018 15:17:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <93F92933-6D17-4410-B17A-984014D2FFFE@shockey.us> Date: Thu, 8 Feb 2018 15:17:58 -0500 Cc: IETF STIR Mail List Content-Transfer-Encoding: 7bit Message-Id: <062A913B-6BD8-4250-8074-0BADAC361169@vigilsec.com> References: <93F92933-6D17-4410-B17A-984014D2FFFE@shockey.us> To: Richard Shockey X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [stir] Ah .. hummmm what is going on folks with the core documents? X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 20:18:07 -0000 > On Feb 8, 2018, at 3:07 PM, Richard Shockey wrote: > > > I thought these were in 48 AUTH or something? https://www.rfc-editor.org/cluster_info.php?cid=C318 https://www.rfc-editor.org/auth48/C318 All approvals have been given. We are waiting on the RFC Editor. Russ From nobody Wed Feb 14 17:34:34 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B0F12D864; Wed, 14 Feb 2018 17:34:19 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 cO6p8aNRujtq; Wed, 14 Feb 2018 17:34:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60DF4126CD6; Wed, 14 Feb 2018 17:34:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 69D14B81257; Wed, 14 Feb 2018 17:33:59 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, stir@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180215013359.69D14B81257@rfc-editor.org> Date: Wed, 14 Feb 2018 17:33:59 -0800 (PST) Archived-At: Subject: [stir] =?utf-8?q?RFC_8224_on_Authenticated_Identity_Management_in?= =?utf-8?q?_the_Session_Initiation_Protocol_=28SIP=29?= X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 01:34:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8224 Title: Authenticated Identity Management in the Session Initiation Protocol (SIP) Author: J. Peterson, C. Jennings, E. Rescorla, C. Wendt Status: Standards Track Stream: IETF Date: February 2018 Mailbox: jon.peterson@neustar.biz, fluffy@cisco.com, ekr@rtfm.com, chris-ietf@chriswendt.net Pages: 46 Characters: 118924 Obsoletes: RFC 4474 I-D Tag: draft-ietf-stir-rfc4474bis-16.txt URL: https://www.rfc-editor.org/info/rfc8224 DOI: 10.17487/RFC8224 The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document is a product of the Secure Telephone Identity Revisited Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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/retrieve/bulk 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 Wed Feb 14 17:35:07 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99CC12D87B; Wed, 14 Feb 2018 17:34:53 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3TD-QIb08ABj; Wed, 14 Feb 2018 17:34:45 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5BA1270AC; Wed, 14 Feb 2018 17:34:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 457B7B81270; Wed, 14 Feb 2018 17:34:22 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, stir@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180215013422.457B7B81270@rfc-editor.org> Date: Wed, 14 Feb 2018 17:34:22 -0800 (PST) Archived-At: Subject: [stir] =?utf-8?q?RFC_8225_on_PASSporT=3A_Personal_Assertion_Token?= X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 01:34:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8225 Title: PASSporT: Personal Assertion Token Author: C. Wendt, J. Peterson Status: Standards Track Stream: IETF Date: February 2018 Mailbox: chris-ietf@chriswendt.net, jon.peterson@neustar.biz Pages: 25 Characters: 48751 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-stir-passport-11.txt URL: https://www.rfc-editor.org/info/rfc8225 DOI: 10.17487/RFC8225 This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. This document is a product of the Secure Telephone Identity Revisited Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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/retrieve/bulk 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 Wed Feb 14 17:35:50 2018 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1728D12D86F; Wed, 14 Feb 2018 17:35:43 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rEuFESAntfH4; Wed, 14 Feb 2018 17:35:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E08312D874; Wed, 14 Feb 2018 17:35:03 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AC43BB81283; Wed, 14 Feb 2018 17:34:45 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, stir@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180215013445.AC43BB81283@rfc-editor.org> Date: Wed, 14 Feb 2018 17:34:45 -0800 (PST) Archived-At: Subject: [stir] =?utf-8?q?RFC_8226_on_Secure_Telephone_Identity_Credential?= =?utf-8?q?s=3A_Certificates?= X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 01:35:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8226 Title: Secure Telephone Identity Credentials: Certificates Author: J. Peterson, S. Turner Status: Standards Track Stream: IETF Date: February 2018 Mailbox: jon.peterson@neustar.biz, sean@sn3rd.com Pages: 24 Characters: 54838 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-stir-certificates-17.txt URL: https://www.rfc-editor.org/info/rfc8226 DOI: 10.17487/RFC8226 In order to prevent the impersonation of telephone numbers on the Internet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. This document is a product of the Secure Telephone Identity Revisited Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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/retrieve/bulk 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 Tue Feb 27 15:20:20 2018 Return-Path: X-Original-To: stir@ietf.org Delivered-To: stir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D791C12EB31; Tue, 27 Feb 2018 15:11:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: stir@ietf.org, adam@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977308287.5200.398857895891982256.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:22 -0800 Archived-At: Subject: [stir] stir - Requested session has been scheduled for IETF 101 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:27 -0000 Dear Russ Housley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. stir Session 1 (1:00:00) Thursday, Morning Session I 0930-1200 Room Name: Viscount size: 175 --------------------------------------------- Special Note: 1100 - 1200 Request Information: --------------------------------------------------------- Working Group Name: Secure Telephone Identity Revisited Area Name: Applications and Real-Time Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 60 Conflicts to Avoid: First Priority: curdle sipbrandy ipwave modern ice dispatch sipcore mmusic rtcweb avtcore ecrit tls acme lamps suit saag Second Priority: perc slim netvc clue tcpinc uta ace oauth People who must be present: Russ Housley Sean Turner Adam Roach Robert Sparks Jon Peterson Chris Wendt Resources Requested: Special Requests: ---------------------------------------------------------