MIME-Version: 1.0
In-Reply-To: <20170104171617.GE24134@blitiri.com.ar>
References: <20170104171617.GE24134@blitiri.com.ar>
From: Daniel Margolis <dmargolis@google.com>
Date: Thu, 5 Jan 2017 05:29:44 -0700
Message-ID: <CANtKdUcXVHmVjooyV3k85C3UucGW_qYvERWn1m464dhY381oqw@mail.gmail.com>
To: Alberto Bertogli <albertito@blitiri.com.ar>
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha-256; boundary="f403045e8a1a7aa0810545580ec9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/Omqo1Bw6rJbrTMl2Zo69IJr35Qo>
Cc: uta@ietf.org
Subject: Re: [Uta] MTA-STS - Questions on implementing the latest (02) draft
Precedence: list

--f403045e8a1a7aa0810545580ec9
Content-Type: multipart/alternative; boundary=f403045e8a1a71b1dc0545580e18

--f403045e8a1a71b1dc0545580e18
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Inline:

On Wed, Jan 4, 2017 at 10:16 AM, Alberto Bertogli <albertito@blitiri.com.ar=
>
wrote:

>
> Hi! Happy new year!
>
> I had some time during the holidays and started to do a basic
> implementation of the latest MTA-STS draft.
>
> While doing so, there were a couple of things I wasn't sure about so I'd
> thought I'd ask:
>
> - What happens if the "mx" field is missing from the policy?
>   Should the MTA skip checking the field but honour the rest of the polic=
y,
>   treat the policy as invalid, or assume no MX is valid?
>

The "mx" field is required, so if it is missing, the policy is invalid and
should not be honored. (It doesn't make sense to honor the policy anyway, I
would say, since a policy without allowed MXs is essentially a way of
saying, "There should be TLS and the server identity should match the MX,
whatever the MX is." I guess this prevents SSL stripping, but doesn't
prevent DNS injection, so it's of relatively little value.)


> - For the case of an internationalized domain name, the "mx" field should
>   include domain patterns in their U form (e.g. "*.=C3=B1aca.com
> <http://xn--aca-6ma.com>"), A form
>   ("*.*.xn--aca-6ma.com"), or both can be present?
>

I suppose this is underspecified in the draft!

I would say based on https://tools.ietf.org/html/rfc6125#section-6.4.2 that
it makes the most sense for this to be in the A-form, since otherwise the
MTA would have to convert to the A form for checking. What do you think?

I proably can make a quick change to clarify this if it seems reasonable to
those on this list.


> - The TXT record is on "_mta-sts" but the policy is on "mta-sts". Is that
>   intentional? Why not putting both on the same domain, to simplify thing=
s?
>

Yes, this is intentional. The underscore in "_mta-sts" was kept to be
similar to that in (e.g.) _dmarc TXT records, but for the HTTP host this
seemed inadvisable:
https://www.ietf.org/mail-archive/web/uta/current/msg01524.html.


>
> - The draft says that clients MUST check the TXT record, but it seems to =
me
>   it's totaly possible to make a reasonable implementation without doing
> so.
>   Is it worth using "MUST" for this?
>   I imagine this is related to the previous discussion we had, but
>   forcing MTAs to check seemed quite strong so I was wondering if
>   there was something else.
>

I think there's some utility in specifying this as at least a SHOULD so as
to ensure common behavior--otherwise, a recipient domain that updates its
HTTP but not TXT will work some of the time for some senders, I guess? That
seems risky.

But need it be a MUST? Probably not. The truth of the matter is, as you
say, that nobody would really know (except from slightly higher request
rates) if your implementation did HTTP-only. ;)

I'm open to making this a SHOULD, but it's not something I have a strong
feeling about one way or another. What do you (and others) think--worth
changing to SHOULD? Better to keep a "MUST"?


>
>
> Thanks!
>                 Alberto
>
>
> In case you're curious, the implementation I have so far is at
> https://blitiri.com.ar/git/r/chasquid/b/sts/, in particular
> https://blitiri.com.ar/git/r/chasquid/c/febad008f38c9ac980a4c0a6179a76
> 81fed7f125/
> (patch and branch are subject to rebasing).
>
> It's mostly fetching, parsing and checking. It has no caching or
> reporting yet; I will add them later, but thought these questions are
> independent anyway.
>

I feel slightly bad for not having shared this earlier, but I wrote a toy
implementation here: https://github.com/danmarg/smtp-sts. As with yours, it
does not do caching or reporting; I wrote it merely to power this:
http://sts.x.af0.net.

Feel free to copy any code you like, of course, though it's a little late
for that. ;)


>
> The integration into the MTA itself will come later too, but I expect it
> to be roughly similar to the integration into the smtp-check tool, which
> is included.
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>

--f403045e8a1a71b1dc0545580e18
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Inli=
ne:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">On=
 Wed, Jan 4, 2017 at 10:16 AM, Alberto Bertogli <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:albertito@blitiri.com.ar" target=3D"_blank">albertito@blitiri.=
com.ar</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><br>
Hi! Happy new year!<br>
<br>
I had some time during the holidays and started to do a basic<br>
implementation of the latest MTA-STS draft.<br>
<br>
While doing so, there were a couple of things I wasn&#39;t sure about so I&=
#39;d<br>
thought I&#39;d ask:<br>
<br>
- What happens if the &quot;mx&quot; field is missing from the policy?<br>
=C2=A0 Should the MTA skip checking the field but honour the rest of the po=
licy,<br>
=C2=A0 treat the policy as invalid, or assume no MX is valid?<br></blockquo=
te><div><br></div><div>The &quot;mx&quot; field is required, so if it is mi=
ssing, the policy is invalid and should not be honored. (It doesn&#39;t mak=
e sense to honor the policy anyway, I would say, since a policy without all=
owed MXs is essentially a way of saying, &quot;There should be TLS and the =
server identity should match the MX, whatever the MX is.&quot; I guess this=
 prevents SSL stripping, but doesn&#39;t prevent DNS injection, so it&#39;s=
 of relatively little value.)=C2=A0</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
- For the case of an internationalized domain name, the &quot;mx&quot; fiel=
d should<br>
=C2=A0 include domain patterns in their U form (e.g. &quot;*.<a href=3D"htt=
p://xn--aca-6ma.com" rel=3D"noreferrer" target=3D"_blank">=C3=B1aca.com</a>=
&quot;), A form<br>
=C2=A0 (&quot;*.*.<a href=3D"http://xn--aca-6ma.com" rel=3D"noreferrer" tar=
get=3D"_blank">xn--aca-6ma.com</a>&quot;), or both can be present?<br></blo=
ckquote><div><br></div><div>I suppose this is underspecified in the draft!<=
/div><div><br></div><div>I would say based on <a href=3D"https://tools.ietf=
.org/html/rfc6125#section-6.4.2">https://tools.ietf.org/html/rfc6125#sectio=
n-6.4.2</a> that it makes the most sense for this to be in the A-form, sinc=
e otherwise the MTA would have to convert to the A form for checking. What =
do you think?=C2=A0</div><div><br></div><div>I proably can make a quick cha=
nge to clarify this if it seems reasonable to those on this list.=C2=A0</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- The TXT record is on &quot;_mta-sts&quot; but the policy is on &quot;mta-=
sts&quot;. Is that<br>
=C2=A0 intentional? Why not putting both on the same domain, to simplify th=
ings?<br></blockquote><div><br></div><div>Yes, this is intentional. The und=
erscore in &quot;_mta-sts&quot; was kept to be similar to that in (e.g.) _d=
marc TXT records, but for the HTTP host this seemed inadvisable:=C2=A0<a hr=
ef=3D"https://www.ietf.org/mail-archive/web/uta/current/msg01524.html">http=
s://www.ietf.org/mail-archive/web/uta/current/msg01524.html</a>.=C2=A0</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- The draft says that clients MUST check the TXT record, but it seems to me=
<br>
=C2=A0 it&#39;s totaly possible to make a reasonable implementation without=
 doing so.<br>
=C2=A0 Is it worth using &quot;MUST&quot; for this?<br>
=C2=A0 I imagine this is related to the previous discussion we had, but<br>
=C2=A0 forcing MTAs to check seemed quite strong so I was wondering if<br>
=C2=A0 there was something else.<br></blockquote><div><br></div><div>I thin=
k there&#39;s some utility in specifying this as at least a SHOULD so as to=
 ensure common behavior--otherwise, a recipient domain that updates its HTT=
P but not TXT will work some of the time for some senders, I guess? That se=
ems risky.=C2=A0</div><div><br></div><div>But need it be a MUST? Probably n=
ot. The truth of the matter is, as you say, that nobody would really know (=
except from slightly higher request rates) if your implementation did HTTP-=
only. ;)=C2=A0</div><div><br></div><div>I&#39;m open to making this a SHOUL=
D, but it&#39;s not something I have a strong feeling about one way or anot=
her. What do you (and others) think--worth changing to SHOULD? Better to ke=
ep a &quot;MUST&quot;?</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
<br>
<br>
Thanks!<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alberto<br>
<br>
<br>
In case you&#39;re curious, the implementation I have so far is at<br>
<a href=3D"https://blitiri.com.ar/git/r/chasquid/b/sts/" rel=3D"noreferrer"=
 target=3D"_blank">https://blitiri.com.ar/git/r/<wbr>chasquid/b/sts/</a>, i=
n particular<br>
<a href=3D"https://blitiri.com.ar/git/r/chasquid/c/febad008f38c9ac980a4c0a6=
179a7681fed7f125/" rel=3D"noreferrer" target=3D"_blank">https://blitiri.com=
.ar/git/r/<wbr>chasquid/c/<wbr>febad008f38c9ac980a4c0a6179a76<wbr>81fed7f12=
5/</a><br>
(patch and branch are subject to rebasing).<br>
<br>
It&#39;s mostly fetching, parsing and checking. It has no caching or<br>
reporting yet; I will add them later, but thought these questions are<br>
independent anyway.<br></blockquote><div><br></div><div>I feel slightly bad=
 for not having shared this earlier, but I wrote a toy implementation here:=
=C2=A0<a href=3D"https://github.com/danmarg/smtp-sts">https://github.com/da=
nmarg/smtp-sts</a>. As with yours, it does not do caching or reporting; I w=
rote it merely to power this: <a href=3D"http://sts.x.af0.net">http://sts.x=
.af0.net</a>.=C2=A0</div><div><br></div><div>Feel free to copy any code you=
 like, of course, though it&#39;s a little late for that. ;)=C2=A0</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The integration into the MTA itself will come later too, but I expect it<br=
>
to be roughly similar to the integration into the smtp-check tool, which<br=
>
is included.<br>
<br>
______________________________<wbr>_________________<br>
Uta mailing list<br>
<a href=3D"mailto:Uta@ietf.org">Uta@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/uta" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/uta</a><br>
</blockquote></div><br></div></div>

--f403045e8a1a71b1dc0545580e18--

--f403045e8a1a7aa0810545580ec9
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS7QYJKoZIhvcNAQcCoIIS3jCCEtoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBTMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEajCCA1KgAwIBAgIMefUloYHzSGHxvhoTMA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjE4NDIxM1oXDTE3MDUy
MTE4NDIxM1owJTEjMCEGCSqGSIb3DQEJAQwUZG1hcmdvbGlzQGdvb2dsZS5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVZeMgUxvBZAIC2QAMYEvZok17Coe5EZf6rdTm4bN/hx8+
q9CiMoFwC7tXxS091f9wnwQv9TZBRfYZq3/Z1u7WF1MSj1X8Ddfo+/y2ae5sf/Stn8mCKvRF2kVd
yrG5pfiD3re49+a5SIOA/EXF8nIc5tT52XGLyQ7X4OH85pFc0KJW5DoXjUhlYMdMuLcVZxgmMyF0
TM3y3zJ82oXwXbjGxzyoBGiCMZ7SazcvUiH6l/dXE8ITtMNSl2JfV4zuPLRrq8M+8VSw4TZ0WdHR
iEH66x2WPkP2GHB2VzMAe5MT03fS4xY7PzOHnrX+LXUGPBz8SLopJATblErlv4am5cGPAgMBAAGj
ggFxMIIBbTAfBgNVHREEGDAWgRRkbWFyZ29saXNAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIw
QAYIKwYBBQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWlt
ZWNhMS5jcnQwHQYDVR0OBBYEFN9KM4M2uNz3WAAm1cJXg4N5P0o/MB8GA1UdIwQYMBaAFMs4ErDH
mcB4koyzIZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0
dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0
dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAw
HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQB6v2N2ySCp
H9nWObqr0Vt4DnGPi1eIgcyagCKHkxcLYw/chdimjGaNvv91Y7wZVUQuulgC8cXN4uQ80A4TXGWW
o03viEEa1lSd4KcdrBDOnYipjH3h2/aTs9KArFH12Rk0o2Bjl7zeXLWVyafWfTY06DqBNtWw5D1N
XynQNh6eoH33VxfpUo7aMdY+tpPXdrQ0PWjSY1M1jjYGf6++hhfh91QBGsiaVUw6QSL0qS/Ib6tg
5wPUGBUTjS1QkSousJTh61Gy9miSCGK+bMPflop+32V08iIy+vKPAYrdhlbZb+s75CLDMDY52g27
8Khm2RrbmO+9D86TfsmHlIPvWfo/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UE
ChMQR2xvYmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIM
efUloYHzSGHxvhoTMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCA0gAQW0dGEXCcO
kaptUL8vd2RE2w6tnQYPGnHXCFWb7zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0xNzAxMDUxMjI5NDVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCG
SAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEB
BzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAbaJHjFbIj54VvpthVKtx+Gu27zsqGjWJ
TsB2bQc8vmzEifznUwG1kC7LCCXpVSfXNdMQWYimPAoH++35eg66ccyj3pVG9NoYuChsF6Y3ZfzF
dlQX81XFTNmT8RpwJTe5pN5gtwYzrS6uP+9SX0gK9+fNamvKOBFQUdr42NDmFivfXgsku6Mdm4k6
8TGzr+wAAkDkJKNKtbigUoWJ6n0J46ZFPUQf/3JZk7ngwui9tk9BqsZeNPQNyvuqJwrAeFJcqg6g
Bwm/UIHs8AKQTOSOYCZBxTr6Tvfvq7cJM2jHUYc93lU7Noj8lHcuLac/gyrO3rK1Z2fLjKDbY/4L
BLm51g==
--f403045e8a1a7aa0810545580ec9--