From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <75A2B3D1-6091-436B-85ED-71A6BC8266CD@lodderstedt.net>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_806FA562-9592-4592-94D1-B74B12769C91";
 protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 20 Sep 2019 15:01:13 +0200
In-Reply-To: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, oauth <oauth@ietf.org>,
 draft-ietf-oauth-jwt-introspection-response@ietf.org,
 oauth-chairs@ietf.org, Vladimir Dzhuvinov <vladimir@connect2id.com>
To: Benjamin Kaduk <kaduk@mit.edu>
References: <156746426740.13074.1850379334333790613.idtracker@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/fRdKGIDUpHxFkZ1tDnIL1_bPHdo>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
 draft-ietf-oauth-jwt-introspection-response-07: (with DISCUSS and COMMENT)
Precedence: list


--Apple-Mail=_806FA562-9592-4592-94D1-B74B12769C91
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Ben,=20

thanks a lot for your review comments. =20

We just published a new revision that is intended to resolve all your =
DISCUSS and COMMENT.

=
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08=


> On 3. Sep 2019, at 00:44, Benjamin Kaduk via Datatracker =
<noreply@ietf.org> wrote:
>=20
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-jwt-introspection-response-07: Discuss
>=20
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut =
this
> introductory paragraph, however.)
>=20
>=20
> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> =
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-respon=
se/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>=20
> Per the ongoing discussion on the WG list, it's unclear that we can
> retain the behaviors we describe and still comply with the =
requirements
> of RFC 7519 requirements for being a JWT (e.g., regarding "jti", =
"iat",
> etc.).  That is, in the present formulation, there are two "token"s
> involved -- the input that is being introspected, and the "token" that
> is the introspection response.  We are claiming that certain fields =
are
> describing the input token, when they are defined to be statements =
about
> the current (response) token.
> Relaxing our statements to say that we merely use JWS as opposed to =
JWT
> may be a workaround, though I have thought about it hard enough to =
have
> an opinion on whether it is the best workaround.

I thought about this as well but I think it wouldn=E2=80=99t solve the =
problem entirely. As you said, there are two token involved and we need =
to make the difference clear.=20

We enhanced the wording of the draft to make the difference between the =
introspected token (that could be a JWT) and the introspection response =
in JWT format. I hope that helps.

Re the concrete issue: In my opinion, the use case brought up requires =
the AS to attest the time when the introspection endpoint response was =
created. It=E2=80=99s about non-repudiation for attesting that the =
access token was active at that time.=20

We extended the text in section 5 accordingly.=20
 =20

>=20
> I also think we need more clarity about the use of dynamic client
> registration by a resource server as outlined in Section 4 (where it's
> mentioned as "with a resource server posing as the client", without
> reference to RFC 7591.  As far as I can tell this document/section is
> introducing this use of dynamic client registration by an RS for the
> first time, so we cannot easily just refer to some other document.

I understand. It=E2=80=99s being used in the wild but has never been =
mentioned in an OAuth draft.=20

We added a section on trust management between AS and RS including =
references to dynamic client registration.=20

=
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08=
#section-3


> Specifically, are there any fields that MUST NOT be supplied?  Is a
> human-readable client_name useful?  How does the supplied client_uri
> need to relate to any existing AS representation of a resource in
> audience, scope, etc. (e.g., for the "resource" request parameter from
> draft-ietf-oauth-resource-indicators)?

=
https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-08=
#section-3 lists all fields we consider reasonable.=20

>=20
> Is this usage considered to be a "new use of JWTs"?  If so, it seems
> that we should follow the recommendation of draft-ietf-oauth-jwt-bcp =
and
> use explicit typing.

We added a media type "application/token-introspection+jwt=E2=80=9D and =
language describing it's use.

>=20
> I think there are some missing links in the document between a RS
> registring client policy and the resulting AS enforcement of =
encryption
> of introspection reponses. =20
> I think the intent is roughly that the
> policy will be applied based on the audience of the token being
> presented for introspection (as opposed to the identity of the
> RS-as-client making the introspection request), but we don't seem to
> explicitly say that. =20

We added text about this to Sections 3 & 5.

> Also, we'd need to say something about the
> interaction of multiple RSs' policy when a given token has multiple
> valid audiences.  There is a very brief discussion in Section 6.5, but
> it seems to be more of a description of what is possible than =
mandating
> particular forms of enforcement.

Section 3 now states

The authorization server MUST be able to determine whether an RS is
   the audience for a particular access token and what data it is
   entitled to receive, otherwise the RS is not authorized to obtain
   data for the access token.  The AS has the discretion how to fulfil
   this requirement.  The AS could, for example, maintain a mapping
   between scopes values and resource servers.

Section 5 now states

If the access token is =E2=80=9C..." is not
   intended to be consumed by the calling resource server (audience),
   the authorization server MUST set the value of the response claim
   "active" to "false".  Otherwise, this claim is set to "true=E2=80=9D.

If possible, the AS MUST narrow down the "scope" value to the scopes
   relevant to the particular RS.

Does this work for you?

>=20
> I think we should discuss whether we want some statement from the =
OpenID
> Foundation or related bodies before we register claims that point to
> their documents with the IESG listed as change controller.

After a discussion with the designated expert (Just Richer), we decided =
to remove the registration since the claims we want to include are =
already registered in the JWT Claims Registry. That=E2=80=99s sufficient =
for the use cases of this draft.=20

>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> idnits notes that RFC 5646 is mentioned but not present in the
> references section.

Gone since we removed the OIDC claims registration.=20

>=20
> Section 1
>=20
> We probably need to move the 7519 reference up here to where JWT is
> first used.
>=20
>   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.  This allows deployments to implement
>   identifier-based access tokens in an interoperable way.

Done

>=20
> Does "identifier-based access tokens" mean "tokens that are opaque =
keys
> to a (central) database lookup" or "access tokens that convey user
> identity information" (or something else)?  We may want to tweak the
> wording.

Changed to "opaque tokens"

>=20
> Section 3
>=20
> Can we double-check the base64 form of the response in this example?  =
I
> am seeing output that backslash-escapes the '/' characters in URLs,
> which I did not think was needed in this context.
> I also see an "extension_field" claim in the base64 but not the =
decoded
> form of the example, and "given_name"/"family_name"/"birthdate" in the
> decoded example vs. "username" in the base64 version.

Re-worked the example

>=20
>   Note: If the resource server policy requires a signed and encrypted
>   response and the authorization server receives an unauthenticated
>   request containing an Accept header with content type other than
>   "application/jwt", it MUST refuse to serve the request and return an
>   HTTP status code 400.  This is done to prevent downgrading attacks =
to
>   obtain token data intended for release to legitimate recipients only
>   (see Section 6.2).
>=20
> I'd suggest a forward-reference to section 4 for how the AS will know
> the RS's policy.  Although, given that "unauthenticated request" is
> included in the preconditions, perhaps we do not need the conditional =
on
> "resource server policy" at all?

Since we added section 3, the prerequisites should be clearer now.=20

>=20
> Section 4
>=20
>   The authorization server determines what algorithm to employ to
>   secure the JWT for a particular introspection response.  This
>   decision can be based on registered metadata parameters for the
>   resource server, supplied via dynamic client registration with the
>   resource server posing as the client, as defined by this draft.
>=20
> nit: I suggest s/posing as the/acting as a/, and s/by this =
draft/below/,
> since it's right here in this section.

Done

>=20
>   introspection_encrypted_response_alg  OPTIONAL.  JWE [RFC7516]
>           algorithm ("alg" value) as defined in JWA [RFC7518] for
>           encrypting introspection responses.  If this is specified,
>           the response will be encrypted using JWE and the configured
>           algorithm.  The default, if omitted, is that no encryption =
is
>=20
> This text is slightly confusing with respect to the interaction =
between
> the introspection_encrypted_response_alg "alg" value and the
> introspection_encrypted_response_enc "enc" value.  My understanding is
> that the "enc" is a symmetric bulk encryption scheme that directly
> protects the payload, whereas the "alg" is a key-wrap or key-agreement
> mechanism used to establish the key used as input for the "enc" =
method.
> So, while "algorithm ("alg value") for encrypting introspection
> responses" and "the response will be encrypted using the confugred
> ["algo"] algorithm" are technically true, they're also a bit =
misleading,
> since this is not what encrypts the "bulk" of the response.  Using the
> term from RFC 7158, "key management algorithm", would probably =
alleviate
> this confusion.

Changed the text to consistently use =E2=80=9Ccontent key encryption" =
and "content encryption=E2=80=9D=20

>=20
>   Resource servers may register their public encryption keys using the
>   "jwks_uri" or "jwks" metadata parameters.
>=20
> Should we cite 7591 for these (or, really, the whole section)?  We =
don't
> currently mention it until the IANA considerations.

It=E2=80=99s mentioned in Section 3 now.

>=20
> Section 5
>=20
> Is it worth a note that resource servers will fetch these metadata and
> use them as input to their dynamic registrations in the previous =
section
> (i.e., picking from the list of supported algorithms)?
>=20
>   introspection_encryption_alg_values_supported  OPTIONAL.  JSON array
>           containing a list of the JWE [RFC7516] encryption algorithms
>           ("alg" values) as defined in JWA [RFC7518] supported by the
>           introspection endpoint to encrypt the response.
>=20
> Similarly to the above, some refined text about "key management
> algorithm" used to encrypt the response, would probably be helpful.

Changed the text to consistently use =E2=80=9Ccontent key encryption" =
and "content encryption=E2=80=9D=20

>=20
> Section 6
>=20
> There seem to be notable privacy considerations about quite a few of =
the
> claims registered in Section 8.3.
>=20
> Section 6.1
>=20
> I'm surprised to not see discussion of explicit typing (and, IIUC, how
> it's not a reliable mitigation) here.

Added this discussion to (now) Section 8.1

Any relying party processing the "typ" JWT header element should
   detect the attack since token introspection responses in JWT format
   set this header to the value "token-introspection+jwt".
   Unfortunately, this is not a well established practice yet.


>=20
>   JWT introspection responses and OpenID Connect ID Tokens are
>   syntactically similar.  An attacker could therefore attempt to
>   impersonate an end-user at a OpenID Connect relying party by passing
>   the JWT as an ID token.
>=20
> nit: "response JWT" or "JWT response"
>=20
>   Such an attack can be prevented like any other token substitution
>   attack.  The authorization server MUST include the claims "iss" and
>   "aud" in each JWT introspection response, with the "iss" value set =
to
>   the authorization server's issuer URL and the "aud" value set to the
>   resource server's identifier.  [...]
>=20
> Related to the Discuss point, how does this relate to the dynamic =
client
> registration parameters?

The =E2=80=9Caud" value depends on the way the AS identifies RSs (see =
section 3). Dynamic client registration is just one option for client =
management, I assume the AS would use the client_id in that case.=20

>=20
>   [OpenID.Core].  Relying parties SHOULD also use and check the =
"nonce"
>   parameter and claim to prevent token and code replay.
>=20
> Is this SHOULD just referring to the behavior already described in
> OpenID.Core (and only applicable to OIDC implementations as opposed to
> JWT-instrospection consumers)?  If so, maybe descriptive language is
> more appropriate, like "Relying parties are also expected to use and
> check [...]=E2=80=9D.

Modified the text according to your suggestion. =20

>=20
>   Resource servers utilizing JWTs to represent self-contained access
>   tokens could be susceptible to replay attacks.  Resource servers
>   should therefore apply proper counter measures against replay as
>   described in [I-D.ietf-oauth-security-topics], section 2.2.
>=20
> I'm not sure what part of this is specific to the introspection case.
> Is it supposed to be tied to the risk that JWT-instrospection produces =
a
> new route for the generation of JWT objects that could be confused for
> self-contained access tokens?

yes.

> nit: "countermeasures" is valid as a single word.
> nit: it looks like it's section 3.2, now.
>=20
> Section 6.2
>=20
> Please cite RFC 7525 as BCP 195 as well as RFC 7525 (e.g., "per BCP =
195
> [RFC7525]=E2=80=9D).

done=20

>=20
>   To prevent introspection of leaked tokens and to present an
>   additional security layer against token guessing attacks the
>   authorization server may require all requests to the token
>   introspection endpoint to be authenticated.  As an alternative or as
>   an addition to the authentication, the intended recipients may be =
set
>   up for encrypted responses.
>=20
> Do we want to make either of these "may"s into normative =
recommendations
> (or make a recommendation for prevention of introspection data leakage
> even in the face of token leakage, which can be satisfied by either
> mechanism)?

Changed it to MAY(s)

>=20
> Also, we could say more about how configuring encryption for intended
> recipients protects against unencrypted replies to unintended
> recipients...
>=20
>   In the latter case, confidentiality is ensured by the fact that only
>   the legitimate recipient is able to decrypt the response.  An
>   attacker could try to circumvent this measure by requesting a plain
>   JSON response, using an Accept header with the content type set to,
>   for example, "application/json" instead of "application/jwt".  To
>   prevent this attack the authorization server MUST NOT serve requests
>   with content type other than "application/jwt" if the resource =
server
>   is set up to receive encrypted responses (see also Section 3).
>=20
> ....such as by saying that the introspection response will only be =
made
> available to RSes that are intended recipients of (in the audience =
of?)
> the access token being introspected.

We now state this in Sections 3 & 5.

>=20
> Section 6.3
>=20
>   Authorization servers with a policy that requires token data to be
>   kept confidential from OAuth clients must require all requests to =
the
>   token introspection endpoint to be authenticated.  As an alternative
>   or as an addition to the authentication, the intended recipients may
>   be set up for encrypted responses.
>=20
> [this also seems to be assuming a link not stated between RS policy =
and
> AS enforcement, but it seems unlikely that a fix would need to touch
> this text]

It=E2=80=99s now in Section 3.

>=20
> Section 8.1.1
>=20
> nit: using nested lists might make this more readable.
>=20
>   o  Client Metadata Description: String value specifying the desired
>      introspection response encryption algorithm (alg value).
>=20
> [same bit about "key management algorithm=E2=80=9D]

Same changes as above

>=20
> Section 8.2.1
>=20
>   o  Metadata Description: JSON array containing a list of algorithms
>      supported by the authorization server for introspection response
>      encryption (alg value).
>=20
> [and here]
>=20
> Section 8.3
>=20
> I think we should make some mention earlier in the document
> (Introduction?) that we also register some common claim values that =
are
> in use in the wild (or whatever text you feel is appropriate to =
describe
> the claims in question).

We added a paragraph in Section 5 about use of OpenID Connect claims in =
introspection responses.=20

>=20
> The nested lists would be great here as well.
>=20
> Is there any expectation that some combination of "given_name",
> "middle_name", and "family_name" will produce identical content to the
> full "name" claim?
>=20
>   o  Name: "preferred_username"
>=20
>   o  Description: Shorthand name by which the End-User wishes to be
>      referred to at the RP, such as janedoe or j.doe.  This value MAY
>      be any valid JSON string including special characters such as @,
>      /, or whitespace.
>=20
> It seems like there may be some security considerations about =
sanitziing
> this field before using it in an application's logic.
>=20
>   o  Name: "profile"
>=20
>   o  Description:URL of the End-User's profile page.  The contents of
>      this Web page SHOULD be about the End-User.
>=20
> It's slightly surpising to see this claimed for the end-user's profile
> when it might equally apply to a protocol profile or variant in use.
> But I assume this is already deployed, so there's no real point in
> objecting to its registration...
>=20
>   o  Name: "birthdate"
>=20
>   o  Description:Time the End-User's information was last updated.  =
Its
>      value is a JSON number representing the number of seconds from
>      1970-01-01T0:0:0Z as measured in UTC until the date/time.
>=20
> This seems potentially confusable with the user's day/year of birth.
> (Also, are leap seconds excluded?)
>=20
>   o  Name: "zoneinfo"
>=20
>   o  Description: String from zoneinfo [zoneinfo] time zone database
>      representing the End-User's time zone.  For example, Europe/Paris
>      or America/Los_Angeles.
>=20
> We seem to be missing the actual reference entry for [zoneinfo].

Thanks a lot again for your review and I hope we have resolved all of =
your DISCUSS and COMMENT with the new revision.=20

best regards,
Torsten.=20

>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_806FA562-9592-4592-94D1-B74B12769C91
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCC0ow
ggUyMIIEGqADAgECAhEAh3cjdwfbVS49xtpMKQd5tjANBgkqhkiG9w0BAQsFADCBljELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG
A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAxMzAwMDAwMDBaFw0yMDAxMzAyMzU5
NTlaMCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1iT7e+ZazS5uGQ2/oV6rKb+dLiC1cbVCWN1TEV1XemJP68/I
91+YUtc87N8M46QgGHN25FeM8xaWL6Q83aArs/nnuYx26+x0Em5Z8cqcAe+i1JLbvxt5j47h+5ii
ZErQld2GCf7EsW5YO+UoNws9ZMkcOHp77qSUuva0mDxitDpsMdlVIbYTkOIW2/x7NinUBBSvpO0b
xlejSGukCX73pTUWPBK3kznd3wqg7SaiqZH+1g/1cQxMD8Wk8S1QPO3AB2xA7hES4EjWFZ7a9HhX
5VMRyJlsEDb1KJAot7cypJcfDhCJwG8De5hSEsW5kEWL0h+AOFXcB+JQzLW0sdSVxwIDAQABo4IB
5jCCAeIwHwYDVR0jBBgwFoAUCcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFBnmpsoJu2zU
GrbmQoBZG6uxqdNRMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsG
AQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwQAYDVR0gBDkwNzA1BgwrBgEE
AbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMw
UTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNl
Y3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAiBgNV
HREEGzAZgRd0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDANBgkqhkiG9w0BAQsFAAOCAQEAKEl922ls
OY5xPqRLJUKLCshBzoNcJ6UDXI4CwCClc4E3yIDQg09zpK0UdrFW0cU8qFc7iXRixKdU361AADG+
SB/N9ttU40JB7HgJYLhHYijKjXwobUGohyhZRv00PvAS6qV8Xevj2OGZ1V/w3VPJxEyYPpSCFJ0g
qUut0Nt6qse67hS5+BZsJp5d+v/Ozo9UGjLa658ZovxG7/CsKZXF6AQe5fNPhpWAfyVfnTHwQpqm
5jQYPX3fB3k3JQv/IuB2CIENxgQoYpfXg37sSbcdkeWQu4ouiRlTwTfLDI2pfuxRQLJzoCxIYkxg
jlq6XtpvolvwKfJpeg44hus5k11RPDCCBhAwggP4oAMCAQICEE2ULBDUO+CUCcWBLTorBk8wDQYJ
KoZIhvcNAQEMBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQH
EwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYDVQQDEyVV
U0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MTEwMjAwMDAwMFoXDTMw
MTIzMTIzNTk1OVowgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2Vj
dGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKPO2UCkH/3vlGuejWO+bakr8rEE6qGryCvb4mHCkq
KtLNnFCBP22ULvOXqGfV9eNKjkypdR8i0yW2sxpepwRIm4rx20rno0JKuriIMpoqr03E5cWapdfb
M3wccaNDZvZe/S/Uvk2TUxA8oDX3F5ZBykYQYVRR3SQ36gejH4v1pXWuN82IKPdsmTqQlo49ps+L
bnTeef8hNfl7xZ8+cbDhW5nv0qGPVgGt/biTkR7WwtMewu2mIr06MbiJBEF2rpn9OVXH+EYB7PmH
fpsEkzGp0cul3AhSROpPyx7d53Q97ANyH/yQc+jl9mXm7UHR5ymr+wM3/mwIbnYOz5BTk7kTAgMB
AAGjggFkMIIBYDAfBgNVHSMEGDAWgBRTeb9aqitKz1SA4dibwJ3ysgNmyzAdBgNVHQ4EFgQUCcDy
/AvalNtf/ivfqJlCz8ngrQAwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBQBgNVHR8ESTBH
MEWgQ6BBhj9odHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQ2VydGlmaWNhdGlv
bkF1dGhvcml0eS5jcmwwdgYIKwYBBQUHAQEEajBoMD8GCCsGAQUFBzAChjNodHRwOi8vY3J0LnVz
ZXJ0cnVzdC5jb20vVVNFUlRydXN0UlNBQWRkVHJ1c3RDQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEMBQADggIBAEFEdQCrOcIV9d6OlW0ycWiM
AN0X13ocEDiQyOOxvRcxkfO244K0oX7GzCGHYaqRbklCszzNWVT4DZU/vYrLaeVEDUbCYg+Ci7vh
Nn9dNqscbzN0xKBoOuRVjPPWDechU70geT3pXCxpwi8EXwl+oiz7xpYfY99JSs3E/piztTSxljHi
tcPr5yoWr9lbkFR8KU3+uGTZ11BfKfuSSaRrZFBv133SeY0d2AqvB9Dj2ZDaFZA0OQkkhfAqNgDp
VRH99lQV4JSKx0N7/QAEtMj6OF5dRXV6hhXuU3A0Eql4d0247oBpxvnfcmV95QfG8HP059hZSJe7
T2wwC+IzXVDQO4xnnvrQJ07ZWemxc/grFpgiG+o+pQxapF1bKftysi02Rl6uhdp5wbTeLeYzt2SI
9oKSChwGDQQFixtkNnxuwbdrTwvASwvViDPdIGzIQJrTBqriE5/9nzkXbDZmld8/7DyriJ/A73RI
ZllX4dH8mHqsRpU8NEX8IQZWpHWGK5A5nVgvl7MxNfRlIvCvKZQTSnCL8oNqJgHXm6zCB4gBwDon
M8V/2kuQAUVazVA3I376eIWGwzjuqh3H88v7mNHzubLHm5h0ERCSQNz6UoHVZy3q5xeqbYSaxpDQ
z3lCNObL6sNaOQNh3DcyzqZJYTcGfuLlmC3AIteAAh7lbybJszYnMYIDxzCCA8MCAQEwgawwgZYx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0G
CWCGSAFlAwQCAQUAoIIB6zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xOTA5MjAxMzAxMTRaMC8GCSqGSIb3DQEJBDEiBCBZONBT0K2hXA/nV4CUx2iMSa6VI1vT6MPc
fWnqEXx40jCBvQYJKwYBBAGCNxAEMYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl
YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0
ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl
IEVtYWlsIENBAhEAh3cjdwfbVS49xtpMKQd5tjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1
dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCHdyN3B9tVLj3G2kwpB3m2MA0GCSqG
SIb3DQEBAQUABIIBALUqJEbGRJ2+rHiUM0WLj+SNSszez2t/CM2TQwdFZ87TgErAaAv/AcHo3+XX
6kVTw1unuB7H4u0iOCK84LMNUqQ78OMP4kdC47MsxxWVcJGXr22aUJQttNrosraepQkVImpk1pdU
y62rKHSdishXCP34hqCn5jvTC2DWCEgYxhxGAELhVCMusINJpNYvPZlcJ8AEuBkZp47zTcNC2VON
5BNG9rjtJX8Meqvy9uMumzcy89ZrAFIFQaU0QxtC9M83L0gzpK4Dc34AY077zgjTwUDSS3Q2byEa
LlIcFT/SBG9QnzzZE8lun7ac0o10Wy4Dzugjeqzvght6j4nm6cdZt90AAAAAAAA=
--Apple-Mail=_806FA562-9592-4592-94D1-B74B12769C91--