Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C52212948D for ; Tue, 7 Feb 2017 14:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=ve7jtb-com.20150623.gappssmtp.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 jc9Y4-DpcZ0U for ; Tue, 7 Feb 2017 14:56:12 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 D51C312947E for ; Tue, 7 Feb 2017 14:56:11 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id k15so149860202qtg.3 for ; Tue, 07 Feb 2017 14:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cxZGZ9fwwh8p9OqpkUxr3nNenr70KMPcLrFiKFgho8Q=; b=fQCYhKgs6SJFkA9Tf+G/jF2yyPlqudjIGaK2Sww9OcOCtNFxbQGF8Zjsq8SWFKqhOF VcvCswq8sHx/8Xgq2nuY/IseFLVoRRtqe8Y2CKENgyfyyu8J3ljJWoQDo9Tmq+5rKPOM r53/dfgMRHYmyEJdGn1TKACjFofEyPjTXIy2rjyO/navai8uB9kqyVk8wVO0/OPHUivc BuQNm532FvEPRqGyfJvgQmtuDQX0FKpz8vYqXrHdibKlkBWARAnXT4YntJq7RHPDh/zV ajWpoW7UZ4q7hnwKIDO8qWKuXG1ZgWn8OFVQIA8SgoBZJrFGar6WtSDgIlPBHOY4Z3P9 WQAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cxZGZ9fwwh8p9OqpkUxr3nNenr70KMPcLrFiKFgho8Q=; b=LijmM9o23wBM8VmjcNKOdmOF8Xu+Hq5AzhL3EOGNc4asVU8Q+jljkQ0fUqw1gzt9Gp Q/2wgIGWP2kJhYWbD328ohzSJo61nfaUObWvJA94J9uW3iYxp3WzbBRUC4C+kvCND6GS fp716BehiYb/9r4Z0rawoCB2ImCB+F5iiP69FjXMRyZXtD0gEbQo+Gics9xgFb5e5+76 3D3WpVk9S8Kpt2tCJxwqCVACM7pnLzrGfP771+QVATR4kvoEEOUn1f4PgXwtDZzUEAO1 GiybaNtpa5l7vcHk6HEy/F95UG7xcw6l3+KehkZF+Nd5pDzSLqldN5o3NM9wjP9kUOrW q6Gg== X-Gm-Message-State: AMke39mlGPdxRwBruwJLUyuKTUlvWKTbw0VfM2+LAP1OYvTSRnAyKDUWk585UBmtrBOjGBBr X-Received: by 10.200.44.243 with SMTP id 48mr15964872qtx.262.1486508170831; Tue, 07 Feb 2017 14:56:10 -0800 (PST) Received: from [192.168.86.150] ([191.115.72.210]) by smtp.gmail.com with ESMTPSA id h40sm4604965qtb.6.2017.02.07.14.56.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 14:56:10 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C617AC19-606D-4CAB-9C91-ACBF4B8B9A0B"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 19:56:03 -0300 In-Reply-To: To: Andrei Popov References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF TokBind WG , =JeffH Hodges Subject: Re: [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header field? X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 22:56:14 -0000 --Apple-Mail=_C617AC19-606D-4CAB-9C91-ACBF4B8B9A0B Content-Type: multipart/alternative; boundary="Apple-Mail=_F81A449D-799A-4C3A-B5D8-962AEFF419D8" --Apple-Mail=_F81A449D-799A-4C3A-B5D8-962AEFF419D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Are connection headers normally used in the reverse proxy use case? = Generally the user agent wouldn't know that it was talking to a proxy. I thought that they were more for the forward proxy use case where the = browser is configured to talk to a specific proxy or is transparently = intercepted (man/enterprise in the middle)=20 I could hypothetically see a enterprise proxy creating token binding = Id=E2=80=99s for the connections to servers and mapping those to token = binding ID from the browser.=20 I think the NGNX token binding module = (https://github.com/google/ngx_token_binding = ) is doing that sort of = transparent mapping on the server side for session cookies.=20 We probably don't want the same behaviour for both forward and reverse = proxies. John B. > On Feb 7, 2017, at 7:38 PM, Andrei Popov = wrote: >=20 > When we discussed this early on, there was a strong distaste for = connection headers in the HTTP community, so we've defined TB headers as = per-request. > " clients MUST include the Sec-Token- > Binding header field in their HTTP requests." > We could also explicitly prohibit listing TB headers in the Connection = header, if folks would like to see this clarification.=20 > There are many reasons to keep TB headers per-request; it's not just = about the proxies and terminators. >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = =3DJeffH > Sent: Tuesday, February 7, 2017 2:15 PM > To: IETF TokBind WG > Subject: [Unbearable] on not listing 'Sec-Token-Binding' in the = Connection header field? >=20 > the below is kind of long (read it anyway :) The summary is we need = to make a conscious decision regarding the Connection HTTP request = header field and whether we provide guidance regarding it and the = Sec-Token-Binding header (and what guidance if so), or not. This seems = to have ramifications for the nascent draft-campbell-tokbind-tls-term = draft, unless I'm misunderstanding things. >=20 > =3DJeffH >=20 > In working through the list of "Considerations for New Header Fields" = at the end of rfc7231 section 8.3.1 [1], there are these two items.. >=20 > o Whether it is appropriate to list the field-name in the = Connection > header field (i.e., if the header field is to be hop-by-hop; see > Section 6.1 of [RFC7230]). >=20 > o Under what conditions intermediaries are allowed to insert, > delete, or modify the field's value. >=20 > Given the specifics in [RFC7230] Section 6.1 [2].. >=20 > 6.1. Connection >=20 > The "Connection" header field allows the sender to indicate desired > control options for the current connection. In order to avoid > confusing downstream recipients, a proxy or gateway MUST remove or > replace any received connection options before forwarding the > message. >=20 > When a header field aside from Connection is used to supply control > information for or about the current connection, the sender MUST = list > the corresponding field-name within the Connection header field. A > proxy or gateway MUST parse a received Connection header field = before > a message is forwarded and, for each connection-option in this = field, > remove any header field(s) from the message with the same name as = the > connection-option, and then remove the Connection header field = itself > (or replace it with the intermediary's own connection options for = the > forwarded message). >=20 > Hence, the Connection header field provides a declarative way of > distinguishing header fields that are only intended for the = immediate > recipient ("hop-by-hop") from those fields that are intended for = all > recipients on the chain ("end-to-end"), enabling the message to be > self-descriptive and allowing future connection-specific extensions > to be deployed without fear that they will be blindly forwarded by > older intermediaries. >=20 > ..it offhand seems that one would want to list "Sec-Token-Binding" in = the Connection header field because Sec-Token-Binding is ostensibly = about the connection and is hop-by-hop because TLS is hop-by-hop. >=20 > However, given our current thinking wrt TB and TLS Terminating Reverse = Proxies [3], where we are contemplating one approach where such "TTRPs"=20= > pass-through the Sec-Token-Binding header field and add a = corresponding Token-Binding-Context header, one would not want to list = Sec-Token-Binding in the Connection header (because a TTRP would then = strip it off). However there are implementation and security = considerations with this. >=20 > As one proposal, we could say in HTTPSTB something along the lines = of.. >=20 > [...] > Clients SHOULD NOT list the Sec-Token-Binding header field as > a connection option in the Connection header field (Section 6.1 > of [RFC7230]) in order to generally enable Sec-Token-Binding > header field pass-through by intermediaries, e.g., by TLS > terminating reverse proxies (TTRP). Intermediaries MUST NOT > modify the Sec-Token-Binding header field's value. See also the > security considerations section. > [...] > Security Considerations > [...] > Not listing Sec-Token-Binding in the Connection header: this > enables TTRPs to transparently convey the Sec-Token-Binding header > field, containing a Token Binding Message, to the next tier = ("backend > servers"), e.g., where security tokens containing Token Binding IDs > may be minted and validated. The communication between a TTRP and > backend servers needs to be secured against eavesdropping and > modification by unintended parties. The Token Binding Message itself > may be validated by the TTRP or by a backend server. Though, in the > latter case, the data necessary to perform such validation (i.e., = the > EKM, etc.) needs to be conveyed to the entity performing it. Such > conveyance is out of scope for this specification. >=20 > Listing Sec-Token-Binding in the Connection header: if done, this > may help in ensuring that Token Binding IDs are not inadvertently > revealed to unintended parties, though may cause difficulties with > web sites employing TTRPs. > [...] >=20 > Or, we could just say "clients SHOULD list the Sec-Token-Binding = header field as a connection option in the Connection header field", but = that will create problems for TTRPs [3]. >=20 > Or, we can just not mention the Connection header and see if anyone = raises questions about it during further WG and IETF-wide review. >=20 > thoughts? >=20 > [1] >=20 > [2] >=20 > [3] >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_F81A449D-799A-4C3A-B5D8-962AEFF419D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Are connection headers normally used in the reverse proxy use = case?   Generally the user agent wouldn't know that it was talking = to a proxy.

I = thought that they were more for the forward proxy use case where the = browser is configured to talk to a specific proxy or is transparently = intercepted (man/enterprise in the middle) 

I could hypothetically see a enterprise = proxy creating token binding Id=E2=80=99s for the connections to servers = and mapping those to token binding ID from the browser. 

I think the NGNX token = binding module (https://github.com/google/ngx_token_binding) is = doing that sort of transparent mapping on the server side for session = cookies. 

We probably don't want the same behaviour for both forward = and reverse proxies.

John B.


On Feb 7, 2017, at 7:38 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

When = we discussed this early on, there was a strong distaste for connection = headers in the HTTP community, so we've defined TB headers as = per-request.
" clients MUST include the Sec-Token-
  Binding header field in their HTTP requests."
We could also explicitly prohibit listing TB headers in the = Connection header, if folks would like to see this clarification.
There are many reasons to keep TB headers per-request; it's = not just about the proxies and terminators.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = =3DJeffH
Sent: Tuesday, February 7, 2017 2:15 PM
To: IETF TokBind WG <unbearable@ietf.org>
Subject: = [Unbearable] on not listing 'Sec-Token-Binding' in the Connection header = field?

the below is kind of long (read it = anyway :)  The summary is we need to make a conscious decision = regarding the Connection HTTP request header field and whether we = provide guidance regarding it and the Sec-Token-Binding header (and what = guidance if so), or not. This seems to have ramifications for the = nascent draft-campbell-tokbind-tls-term draft, unless I'm = misunderstanding things.

=3DJeffH

In working through the list of "Considerations = for New Header Fields" at the end of rfc7231 section 8.3.1 [1], there = are these two items..

   o =  Whether it is appropriate to list the field-name in the = Connection
      header = field (i.e., if the header field is to be hop-by-hop; see
=       Section 6.1 of [RFC7230]).

   o  Under what = conditions intermediaries are allowed to insert,
=       delete, or modify the field's = value.

Given the specifics in [RFC7230] = Section 6.1 [2]..

  6.1. =  Connection

   The = "Connection" header field allows the sender to indicate desired
   control options for the current = connection.  In order to avoid
=    confusing downstream recipients, a proxy or gateway = MUST remove or
   replace any received = connection options before forwarding the
=    message.

=    When a header field aside from Connection is used to = supply control
   information for or about = the current connection, the sender MUST list
=    the corresponding field-name within the Connection = header field.  A
   proxy or gateway = MUST parse a received Connection header field before
=    a message is forwarded and, for each connection-option = in this field,
   remove any header = field(s) from the message with the same name as the
=    connection-option, and then remove the Connection = header field itself
   (or replace it with = the intermediary's own connection options for the
=    forwarded message).

=    Hence, the Connection header field provides a = declarative way of
   distinguishing = header fields that are only intended for the immediate
=    recipient ("hop-by-hop") from those fields that are = intended for all
   recipients on the = chain ("end-to-end"), enabling the message to be
=    self-descriptive and allowing future = connection-specific extensions
   to be = deployed without fear that they will be blindly forwarded by
   older intermediaries.

..it offhand seems that one would want to list = "Sec-Token-Binding" in the Connection header field because = Sec-Token-Binding is ostensibly about the connection and is hop-by-hop = because TLS is hop-by-hop.

However, given = our current thinking wrt TB and TLS Terminating Reverse Proxies [3], = where we are contemplating one approach where such "TTRPs"
pass-through the Sec-Token-Binding header field and add a = corresponding Token-Binding-Context header, one would not want to list = Sec-Token-Binding in the Connection header (because a TTRP would then = strip it off). However there are implementation and security = considerations with this.

As one proposal, = we could say in HTTPSTB something along the lines of..

  [...]
  Clients SHOULD = NOT list the Sec-Token-Binding header field as
=   a connection option in the Connection header field (Section = 6.1
  of [RFC7230]) in order to generally = enable Sec-Token-Binding
  header field = pass-through by intermediaries, e.g., by TLS
=   terminating reverse proxies (TTRP). Intermediaries MUST = NOT
  modify the Sec-Token-Binding header = field's value. See also the
  security = considerations section.
  [...]
=   Security Considerations
  [...]
  Not listing Sec-Token-Binding in the Connection = header: this
  enables TTRPs to transparently = convey the Sec-Token-Binding header
  field, = containing a Token Binding Message, to the next tier ("backend
  servers"), e.g., where security tokens = containing Token Binding IDs
  may be minted = and validated. The communication between a TTRP and
=   backend servers needs to be secured against eavesdropping = and
  modification by unintended parties. The = Token Binding Message itself
  may be validated = by the TTRP or by a backend server. Though, in the
=   latter case, the data necessary to perform such validation = (i.e., the
  EKM, etc.) needs to be conveyed to = the entity performing it. Such
  conveyance is = out of scope for this specification.

=   Listing Sec-Token-Binding in the Connection header: if done, = this
  may help in ensuring that Token Binding = IDs are not inadvertently
  revealed to = unintended parties, though may cause difficulties with
=   web sites employing TTRPs.
=   [...]

Or, we could just say = "clients SHOULD list the Sec-Token-Binding header field as a connection = option in the Connection header field", but that will create problems = for TTRPs [3].

Or, we can just not mention = the Connection header and see if anyone raises questions about it during = further WG and IETF-wide review.

thoughts?
[1] <https://tools.ietf.org/html/rfc7231#section-8.3.1>

[2] <https://tools.ietf.org/html/rfc7230#section-6.1>

[3] <https://tools.ietf.org/html/draft-campbell-tokbind-tls-term= >


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

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

= --Apple-Mail=_F81A449D-799A-4C3A-B5D8-962AEFF419D8-- --Apple-Mail=_C617AC19-606D-4CAB-9C91-ACBF4B8B9A0B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjA3MjI1 NjAzWjAjBgkqhkiG9w0BCQQxFgQUtJCOohPQjMZMtcc16VYpx7mcmccwgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBALYiufgW9kquh3QUS8lNunmqFSpGssXr mTA2dKDBkZI4MNJXDCFnNRyPotDPC4Zo/wtNMvrLIgCaHgZfzM17/f/PYMptt3VtyJq3c5BtRUSy /uAJsnMYcm35UTQSEbSGTkdbvPbWnHpax7xfJVkwAC67hb9c3jgtLudknfsExOSSGLxLUMbJfu52 uVxg75iWVva+kyD2D+7v1AjS9wj0zNn8HWRIbIIJ+zsjodtFx2JfKyP4xaVWA+DYCxwEok7Qcz6F GkeB/E90V2DUDrUCC0dpBXoJBSF9DIEI3U4/NnFMZv36QwtWHGHh1k6A/y2MhdQdOIDHKysKngov T2/AW+MAAAAAAAA= --Apple-Mail=_C617AC19-606D-4CAB-9C91-ACBF4B8B9A0B--