From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <C590F29A-3B23-4202-937D-14566C116BFF@lodderstedt.net>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_16A752A0-D990-41C1-9979-AC1C58D53CFC";
 protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Wed, 11 Mar 2020 10:20:25 +0100
In-Reply-To:
 <CALkShctZhK-UT9r187uvjxX47-24gnqTbWevwswsNWyL-=3cxw@mail.gmail.com>
Cc: Justin Richer <jricher@mit.edu>,
 Bill Jung <bjung=40pingidentity.com@dmarc.ietf.org>, oauth@ietf.org
To: Andrii Deinega <andrii.deinega@gmail.com>
References:
 <CAErhd0OLTMKxXnT-_X6DyWYUxe==gTXdcHKLjOEDTmXCUZNxrg@mail.gmail.com>
 <CALkShcuLTd02iu309dCZ8PtnzbKd5b9PsVS_DWUMGWXgFovwMg@mail.gmail.com>
 <C0C40A3E-2455-4C86-B504-AB18F31975D9@alkaline-solutions.com>
 <CALkShct=sYSq-HoG=yMiV2BqT8+F=gnej+p2GgFD87FV1OQu3w@mail.gmail.com>
 <D3D1BFB8-CE54-4E48-A8B9-45E01ED2B637@alkaline-solutions.com>
 <CAErhd0PkNzFTVgjSS24RzjKZ+sq2Hubhr3j_hmnbtgLuQgOGhQ@mail.gmail.com>
 <7C1D0E68-5D7B-4C0A-AE13-D513AB8723DE@mit.edu>
 <CAErhd0Ov7v8TMnmwpOaqnrS-FXKZP2fa_FZ37XQ5SPOWzbH3Mg@mail.gmail.com>
 <CALkShctZhK-UT9r187uvjxX47-24gnqTbWevwswsNWyL-=3cxw@mail.gmail.com>
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/oauth/7sijYxKy_3R_fiRUSlSJewWvdnA>
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh
 token?
Precedence: list


--Apple-Mail=_16A752A0-D990-41C1-9979-AC1C58D53CFC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Andrii,

> On 10. Mar 2020, at 22:11, Andrii Deinega <andrii.deinega@gmail.com> =
wrote:
>=20
> Justin,
>=20
> Aren=E2=80=99t these things considered as valid concerns?
>=20
> The introspection endpoint allows to introspect a refresh token for
> its consumers whether they are clients or RSs assuming they were
> successfully authenticated using one or another way.
>=20
> There are lots of projects which act like OAuth & OIDC proxies (or
> just as HTTP request filters) for RSs and what they basically do is
> check whether an access token is valid. The problem here, as I
> described before, that an attacker or even a misbehaving client may
> start to use a refresh instead of an access token which in the worst
> case allows to have access to RSs for a lifetime of the refresh token.
>=20
> =
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-r=
esponse-08
> doesn't shed light on this thing too, at least for me, and even states
> that "OAuth 2.0 Token Introspection [RFC7662] specifies a method for a
> protected resource to query an OAuth 2.0 authorization server to
> determine the state of an access token and obtain data associated with
> the access token." in the introduction section. Although, RFC7662
> allows us to introspect two types of tokens with no issues.

As editor of this draft, I take the liberty to jump in here.=20

draft-ietf-oauth-jwt-introspection-response-08 is not intended to be =
used in conjunction with refresh tokens, simply because there is no use =
case for refresh tokens. The objective is to provide RSs access token =
data with additional security properties by signing and encrypting it. =
This is typically required if the RS needs to proof that the AS provided =
this data to the RS.=20

>=20
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14 as
> well as other documents I saw (for example "An Extensive Formal
> Security Analysis of the OpenID Financial-grade API" at
> https://arxiv.org/abs/1901.11520) neither cover this thing.

I assume because no-one could image RSs accepting refresh tokens. I also =
don=E2=80=99t see a use case for it and would strongly advise against it =
because it violates the security assumptions around refresh tokens.=20

A client could theorectially use the token introspection endpoint and =
introspect a refresh token, but AS cannot do more than either not =
supporting refresh token introspection at all or provide a very small =
set of data for refresh tokens, basically active and scope.=20

I don=E2=80=99t see how an attacker could utilize this to gain access to =
RSs but I agree this assumptions/advise needs to be clearly stated.=20

best regards,
Torsten.=20

>=20
> Could you please, clarify these things?
>=20
> Regards,
> Andrii
>=20
>=20
> On Wed, Mar 4, 2020 at 2:06 PM Bill Jung
> <bjung=3D40pingidentity.com@dmarc.ietf.org> wrote:
>>=20
>> Yep, I agree. But that's just me agreeing with it. Unless the spec =
clearly says it everybody will throw different ideas and use cases. =
That's why I want the spec to clarify this.
>>=20
>> On Wed, Mar 4, 2020, 1:42 PM Justin Richer, <jricher@mit.edu> wrote:
>>>=20
>>> Why would the client need to know the refresh token=E2=80=99s =
expiry? Can=E2=80=99t they just use the refresh token and see? Either =
way it=E2=80=99s a single round trip to the AS and the client gets the =
same answer with the same recovery code path.
>>>=20
>>> =E2=80=94 Justin
>>>=20
>>> On Mar 4, 2020, at 2:01 PM, Bill Jung =
<bjung=3D40pingidentity.com@dmarc.ietf.org> wrote:
>>>=20
>>> The question started when some RPs (client apps) asked that AS allow =
introspection endpoint to RPs so that RPs can check their refresh =
token's expiry. If AS allows this, which the spec is not clear about, =
then AS needs to know if the request is coming from RP or RS so that AS =
can allow the Access Token introspection to RS only. But then is that =
the right thing to do even?
>>>=20
>>> Surely some clarification will eliminate the time spent on =
unnecessary discussion among developers.
>>>=20
>>> Bill Jung
>>> Manager, Response Engineering
>>> bjung@pingidentity.com
>>> w: +1 604.697.7037
>>> Connect with us:
>>>=20
>>>=20
>>> On Sun, Mar 1, 2020 at 9:33 PM David Waite =
<david=3D40alkaline-solutions.com@dmarc.ietf.org> wrote:
>>>>=20
>>>> On Mar 1, 2020, at 10:11 PM, Andrii Deinega =
<andrii.deinega@gmail.com> wrote:
>>>>>=20
>>>>> How would the authorization server know who actually uses the
>>>>> introspection endpoint assuming that a protected resource and a =
client
>>>>> application use the same credentials (client_id and =
client_secret)?
>>>>=20
>>>> In the external context, you have a client accessing a protected =
resource with an access token. The client should treat the token as =
opaque, and RFC7662 makes no allowances for that client to introspect =
its tokens.
>>>>=20
>>>> If you control both the client and protected resource, you may =
decide to short-cut and have them share credentials. However, the client =
logic still should never be introspecting the tokens.
>>>>=20
>>>> The security considerations also say that you must prove the =
authentication of the protected resource, which I have interpreted to =
mean that access tokens used to authorize the call to the introspection =
endpoint must be issued to a confidential client - public clients cannot =
protect credentials to perform an authentication. You want to limit =
introspection to prevent denial of service and probing attacks, and to =
limit the amount of information on viable attacks conveyed if someone =
steals a token.
>>>>=20
>>>> -DW
>>>>=20
>>>>>=20
>>>>> Regards,
>>>>> Andrii
>>>>>=20
>>>>> On Sun, Mar 1, 2020 at 7:38 PM David Waite =
<david@alkaline-solutions.com> wrote:
>>>>>>=20
>>>>>> I would expect the AS to invalidate the refresh token in this =
case, which would not require a refresh token mode nor necessarily any =
signaling back to the resource.
>>>>>>=20
>>>>>> -DW
>>>>>>=20
>>>>>>> On Mar 1, 2020, at 12:12 AM, Andrii Deinega =
<andrii.deinega@gmail.com> wrote:
>>>>>>>=20
>>>>>>> Hello Bill,
>>>>>>>=20
>>>>>>> I'm just thinking out loud about possible scenarios for a =
protected
>>>>>>> resource here... It may decide to revoke a refresh token if a =
client
>>>>>>> application tried to use it instead of an access token when the
>>>>>>> protected resource is paranoid about security. In order to do =
that an
>>>>>>> introspection response should include a non-standard parameter =
which
>>>>>>> indicates that the requested token is refresh_token.
>>>>>>>=20
>>>>>>> A user of the introspection endpoint should rely only on a value =
of
>>>>>>> the active parameter (which is a boolean indicator) of the =
endpoint
>>>>>>> response. This applies to both types of tokens. Note, the =
expiration
>>>>>>> date, as well as other parameters, are defined as optional in =
the
>>>>>>> specification.. Both token types can be revoked before the =
expiration
>>>>>>> date comes even if this parameter is presented as part of the
>>>>>>> response. In my opinion, there are a number of reasons why this =
check
>>>>>>> (for a refresh token) can be useful on the client application =
side.
>>>>>>>=20
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Andrii
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Fri, Feb 28, 2020 at 1:59 AM Bill Jung
>>>>>>> <bjung=3D40pingidentity.com@dmarc.ietf.org> wrote:
>>>>>>>>=20
>>>>>>>> Hello, hopefully I am using the right email address.
>>>>>>>>=20
>>>>>>>> Simply put, can this spec be enhanced to clarify "Who can use =
the introspection endpoint for a refresh token? A resource provider or a =
client app or both?"
>>>>>>>>=20
>>>>>>>> RFC7662 clearly mentions that the user of introspection =
endpoint is a 'protected resource' and that makes sense for an access =
token. If we allow this to client apps, it'll give unnecessary token =
information to them.
>>>>>>>> However, the spec also mentions that refresh tokens can also be =
used against the endpoint.
>>>>>>>> In case of refresh tokens, user of the endpoint should be a =
client app because refresh tokens are used by clients to get another =
access token. (Cannot imagine how/why a resource server would introspect =
a refresh token)
>>>>>>>>=20
>>>>>>>> Is it correct to assume that the endpoint should be allowed to =
client apps if they want to examine refresh token's expiry time? Then =
the RFC should clearly mention it.
>>>>>>>>=20
>>>>>>>> Thanks in advance.
>>>>>>>>=20
>>>>>>>> <Details from the spec>
>>>>>>>> In https://tools.ietf.org/html/rfc7662
>>>>>>>> In '1.  Introduction' section says,
>>>>>>>> "This specification defines a protocol that allows authorized
>>>>>>>> protected resources to query the authorization server to =
determine
>>>>>>>> the set of metadata for a given token that was presented to =
them by
>>>>>>>> an OAuth 2.0 client."
>>>>>>>> Above makes clear that user of the endpoint is a "protected =
resource".
>>>>>>>>=20
>>>>>>>> And under 'token' in '2.1.  Introspection Request' section =
says,
>>>>>>>> "For refresh tokens,
>>>>>>>> this is the "refresh_token" value returned from the token =
endpoint
>>>>>>>> as defined in OAuth 2.0 [RFC6749], Section 5.1."
>>>>>>>> So looks like a refresh token is allowed for this endpoint..
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Bill Jung
>>>>>>>> Manager, Response Engineering
>>>>>>>> bjung@pingidentity.com
>>>>>>>> w: +1 604.697.7037
>>>>>>>> Connect with us:
>>>>>>>>=20
>>>>>>>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited...  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf..org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>=20
>>>=20
>>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>=20
>> CONFIDENTIALITY NOTICE: This email may contain confidential and =
privileged material for the sole use of the intended recipient(s). Any =
review, use, distribution or disclosure by others is strictly =
prohibited..  If you have received this communication in error, please =
notify the sender immediately by e-mail and delete the message and any =
file attachments from your computer. Thank =
you._______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_16A752A0-D990-41C1-9979-AC1C58D53CFC
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC38w
ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG
EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE
CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G
A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN
Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F
jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb
IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy
zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E
AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr
BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw
MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R
BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr
BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG
CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp
cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7
2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe
GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/
L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE
tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q
CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3
/crnd7HTmUfqi0yCylHY62wwggaDMIIEa6ADAgECAhBP3hBL7ZVb3outZYfMQV7jMA0GCSqGSIb3
DQEBCwUAMGsxCzAJBgNVBAYTAklUMQ4wDAYDVQQHDAVNaWxhbjEjMCEGA1UECgwaQWN0YWxpcyBT
LnAuQS4vMDMzNTg1MjA5NjcxJzAlBgNVBAMMHkFjdGFsaXMgQXV0aGVudGljYXRpb24gUm9vdCBD
QTAeFw0xOTA5MjAwNzEyMDVaFw0zMDA5MjIxMTIyMDJaMIGNMQswCQYDVQQGEwJJVDEQMA4GA1UE
CAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UECgwaQWN0YWxpcyBT
LnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u
IENBIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt2hzetk81C/73GfKPc6UfP+J
Gc7aGmPzGUeQJ1go3CdFpsBPonREDXUDdmRCIRkTDroH30RLsTO/0hEFiYjCyvvbSVSm05sXkvfJ
XOXefNqK21fBayr4JCgMRyLVwqRYXlKI7bb42nYSm7YcXGTDmdcydmJuuqcLqFQawWiBMNRRVEi4
uW5uXBZgWGmq8NoKH/+5xGBFbf6tNTWcGhPVceResuwK155+OiH6jTW01Na8aLj7c7IAGJ0Y9e6h
iHtRthfW7SwbU7ys73a3nNXv8Kv9XNr0RvJKHoOsKqxjffew3GKQrMXIHB5tm/je3XEnIxUT8JG3
sEsk7IfF3VirSwIDAQABo4IB/jCCAfowDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRS2Ig6
yJ94Zu2J83s4cJTJAgI20DBBBggrBgEFBQcBAQQ1MDMwMQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3Nw
MDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUH
AgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAnBgNVHSUEIDAeBggrBgEF
BQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMJMIHjBgNVHR8EgdswgdgwgZaggZOggZCGgY1sZGFwOi8v
bGRhcDA1LmFjdGFsaXMuaXQvY24lM2RBY3RhbGlzJTIwQXV0aGVudGljYXRpb24lMjBSb290JTIw
Q0EsbyUzZEFjdGFsaXMlMjBTLnAuQS4lMmYwMzM1ODUyMDk2NyxjJTNkSVQ/Y2VydGlmaWNhdGVS
ZXZvY2F0aW9uTGlzdDtiaW5hcnkwPaA7oDmGN2h0dHA6Ly9jcmwwNS5hY3RhbGlzLml0L1JlcG9z
aXRvcnkvQVVUSC1ST09UL2dldExhc3RDUkwwHQYDVR0OBBYEFGvyjZ5owSUEH1E0V/YWXJTqTWka
MA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEAYES6GaKrcvsOQZpEwboVOb2dri/f
Jrcpb7GSEW9JmA+Kep4GLmp9X50Iv8EK478kwf2aAjnPnsOdiItALcIgecS1qVxN+EY+V5GCNEy4
VAsB5gzlQBmKI9P4PxLt9pnQJneCVEvDnVBMZAllIL5s3uaCiIEb8eYZqG8taOWSM1nqjoCZULcc
hXWYajBqaJg0RUOZ6f5IB0lb26HA/7EUVmh1nSVglDoUeD7elINXHph0z3if1722UydcoH4Jj3Za
Y9dtQ4wJSNhSZOzES72UkS6we/556FOGs7oeJWuQe8Rq2EeeSGmGliZKUbYo4jB/C2omMn0L4QwI
5wMNrWd2FRNUUwxMBmbJYtEaDRTQ72HPA8DnbRkvRDSJkjsToqU6ZpBlBf4s5EwrhXqFVb2rM9mG
CPDZJi7Hw3y8BYD/d3iTL6PW5UjOTSpFcnSIP4HW5PI6MTHXl+ab6ajCnvJw6E1TGLh3zJypv5CQ
8Ftm0z7MKLt5Zr2E4jojZXeZn1sUpSqidZyp9mG/LYMRmHMkthDRnDnO2tHv5+YOO4cUEbTt5Bww
E5RPjqovsnedyd5SijIK+k1MCXFLMTfERz3qUN3i/fwueXcGy4jEf2n/FvYsEY3GBHXZCMVWPffB
fbl/ITjs9Q9NG37bAEm/mg2yNq02NLjDbQIKgt9W0aBU9SsxggOpMIIDpQIBATCBojCBjTELMAkG
A1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAh
BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCC
AdcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwMzExMDkyMDI1
WjAvBgkqhkiG9w0BCQQxIgQgZXRBIvKO7quEvLODhee4gzUlXCPuNJhf1LGiLIlDug0wgbMGCSsG
AQQBgjcQBDGBpTCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcM
EFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSww
KgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7
IHRfgzCBtQYLKoZIhvcNAQkQAgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJn
YW1vMRkwFwYDVQQHDBBQb250ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8w
MzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzIC
EGl8QiQdCJabMXrMOyB0X4MwDQYJKoZIhvcNAQEBBQAEggEAlPMLeNCstuYxAuo/XIQ0AeeVuea1
cKIclkzWW7di/aupBbWUdtp/dPrStBD/6sURmYFmF//Z3nAhvFEjI0Hg3eYu26Rb/ZUcD56AGJ11
hDY2ZJwzTNhGnFKlo8qVTos2RdUyfSvkHC5GdKLIYrfhrD9r4dUDfk9tivtK+YszMHWzj6akSeDF
VER/FcbsO4khSyayoAHGJKrAztDU+X++i4ajTmHiGgfDZ9GnZps3ZV/ro+MTxrIy1npqF+hBTUx3
gYtrzCGM/Wy5MW9jzlTBj64awiYOO42n4C2jYaYsglgPd1jxTOhZV2yWTD6mGaA/o9QWnHeOr7ZD
C4pfIxj3CAAAAAAAAA==
--Apple-Mail=_16A752A0-D990-41C1-9979-AC1C58D53CFC--