Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DCB21F8570 for ; Mon, 18 Jun 2012 13:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBob9V5ZEYVl for ; Mon, 18 Jun 2012 13:19:21 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEBE221F856D for ; Mon, 18 Jun 2012 13:19:20 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4477939ggn.31 for ; Mon, 18 Jun 2012 13:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=s7ILXvTL5qcl5MSQBnKhWuTgnM4Z03yy/ArJeO5G9kI=; b=C49O2syhwgTSGtYvMkgxf9j8xuUVNBD+RzaCR6wbIi+EBytCZkXeuG42MX/zhYZzEn 5MZst/uP+hNG43C5GhOeAtJbiiaqJmsg+xx/Sk8UZri/QHODPfy32bi73Dq66V+GLqVd erhhxVqwcSfo82mvtK5nbU4RHVNr9UH77oIBHQAoOjckuHDw/AJdLzRWLnUPQdwk79H+ 7FpT85jKwu1LTIBJU5gEVFeEHifMPlQ5hnBNH7T3sy588aTsntFJmf2LbNUvKBdFp/sE QQqeFpdX3w5QZkKIGZrD/HYl1wTZydUHnHoCtjp2R5zglqOLiHZCv6W5touYIfEXCvTT Gq1g== Received: by 10.236.190.6 with SMTP id d6mr19560950yhn.16.1340050759847; Mon, 18 Jun 2012 13:19:19 -0700 (PDT) Received: from [192.168.1.213] (190-20-29-46.baf.movistar.cl. [190.20.29.46]) by mx.google.com with ESMTPS id a64sm68705401yhe.11.2012.06.18.13.19.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 13:19:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_39FEC628-0BD5-4285-A37D-112E73554ECC"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> Date: Mon, 18 Jun 2012 16:19:08 -0400 Message-Id: <24783551-C1B8-456B-8E94-9BF59A3CAC75@ve7jtb.com> References: <64C6DF43A866F40437AF4CC3@cyrus.local> <059c01cd39c8$f3d027c0$db707740$@packetizer.com> <1339625839.48148.YahooMailNeo@web31816.mail.mud.yahoo.com> <4FD917ED.2050805@stpeter.im> <1339628098.85328.YahooMailNeo@web31812.mail.mud.yahoo.com> <4FD91AF7.5050107@stpeter.im> <1339630300.21499.YahooMailNeo@web31812.mail.mud.yahoo.com> <012401cd4cf4$6a465da0$3ed318e0$@packetizer.com> <1340040987.3036.YahooMailNeo@web31812.mail.mud.yahoo.com> <022801cd4d7f$644c4dc0$2ce4e940$@packetizer.com> <1340047154.69599.YahooMailNeo@web31803.mail.mud.yahoo.com> To: William Mills X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk06sYPG2bWGdaUEr9LA2X9zxUxdOxRI8jyH6TdsOFm9ZGhVlhxH3B/Gk2zWKtkOQNFod9w Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Aggregated service discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2012 20:19:22 -0000 --Apple-Mail=_39FEC628-0BD5-4285-A37D-112E73554ECC Content-Type: multipart/alternative; boundary="Apple-Mail=_C0A35206-9E3E-4997-89CD-6EABDA051AA3" --Apple-Mail=_C0A35206-9E3E-4997-89CD-6EABDA051AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That is not what I am saying. I am saying that the user's discovery document has a link relation to = the providers decryption of the service. That is different from the = imap endpoint providing the link relation. If you can trust the user's information to provide the Oauth endpoint = why can't you trust the user's information to link to the description of = the service. As I have pointed out before you probably don't want per user = configuration for things like imap, the simplest thing is to describe = the service in host-meta and forget the extra user discovery steps and = maintenance. John B. On 2012-06-18, at 3:19 PM, William Mills wrote: > Unfortunately we came to the conclusion that letting a service = endpoint define it's authenticators is probably wrong, this was in the = context of discovery for SASL mechanisms. The core problem is when the = client supports the password grant if it then trusts the service = endpoint to tell it who to give the username password pair then it's = vulnerable. >=20 > From: John Bradley > To: Paul E. Jones =20 > Cc: 'William Mills' ; 'Peter Saint-Andre' = ; apps-discuss@ietf.org=20 > Sent: Monday, June 18, 2012 11:36 AM > Subject: Re: [apps-discuss] Aggregated service discovery >=20 > A user is likely to have a number of OAuth authorization services for = different things. =20 >=20 > I suspect that the best way to organize it is to describe the services = the user has: > openID Connect > imap > portable contacts > etc >=20 > and let the service describe how it is authenticated and where the = endpoints are. >=20 > For Connect there is a single relation for the Connect issuer and that = is then discovered to get the endpoint and other configuration = information. =20 > Given that user identifiers may point to services in other domains it = is best to leave it up to the service to describe itself rather than = relying on individual user information to be correct. >=20 > John B. >=20 > On 2012-06-18, at 2:22 PM, Paul E. Jones wrote: >=20 >> Bill, >> =20 >> In the referenced draft below, I assume the =93grant-types=94 and = =93token-types=94 should be contained inside a =93properties=94? That = is, I think you want this: >> =20 >> { >> "subject" : "acct:carol@example.com", >> "links" : >> [ >> { >> "rel" : "oauth2-athorize", >> "href" : "http://login.example.com/oauth2/authorize" >> }, >> { >> "rel" : "oauth2-token", >> "href" : "https://login.example.com/oauth2/token", >> "properties" : >> { >> "grant-types" : "code password", >> "token-types" : "bearer" >> } >> } >> ] >> } >> =20 >> For auto-provisioning of email clients (which I understand was your = goal), we can either define one link relation that points to a separate = configuration document of some sort, or we define multiple link = relations. My previous example showed the single link relation and the = email below shows use of multiple. Both have pros and cons, but I tend = to favor using multiple link relations, since this allows one to = introduce new stuff without changing the one mail configuration file. = Also, it reduces the number of queries a mail client has to make to get = config information. >> =20 >> You indicate that IMAP already has a defined URI. Where is that = defined? I could not find it in the IANA link relations registry, so I = assume it=92s really a URI defined in a spec somewhere. In any case, we = could use URIs for these things (rather than defining single token link = relation values and registering them). I have no preference, but I = would like an agreed approach to provisioning. I hate configuring all = the stuff manually on email clients. :-) >> =20 >> Paul >> =20 >> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >> Sent: Monday, June 18, 2012 1:36 PM >> To: Paul E. Jones; 'Peter Saint-Andre' >> Cc: 'Cyrus Daboo'; apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Aggregated service discovery >> =20 >> Paul, >> =20 >> Thanks for the reply on this. I do already have a separate doc for = registering the OAuth specific = relations,http://tools.ietf.org/id/draft-wmills-oauth-lrdd-01.html >> =20 >> I don't think I like the thought of having to register a new link = type for every service, but that might be the right way. IMAP already = has a URI defined for example so if we use a more general link relation = then the URI scheme details the type. The tradeoff is whether you can = look for a specific link-type or if you have to scan list elements for = the URI type you need. >> =20 >> -bill >> =20 >> =20 >> From: Paul E. Jones >> To: 'William Mills' ; 'Peter Saint-Andre' = =20 >> Cc: 'Cyrus Daboo' ; apps-discuss@ietf.org=20 >> Sent: Sunday, June 17, 2012 6:48 PM >> Subject: RE: [apps-discuss] Aggregated service discovery >> =20 >> Bill, >> =20 >> My apologies for the belated reply. I=92ve been busy this week and = got rather behind on email. >> =20 >> I do not personally like using SRV records, either. SRV records = could work for smaller domains, but I=92m not sure that they=92re the = best solution for larger domains. Personally, I would prefer putting = users on specific servers or server clusters and SRV records will not = differentiate users. >> =20 >> To use WebFinger to find one=92s IMAP, SMTP, or POP server, we could = do as I suggested in my email. Now the question is what does one query? = Since these three services are email, I=92d suggest we query = =93mailto:paulej@packetizer.com=94. We could use another URI scheme = (e.g., =93acct:=94), but mailto seems most appropriate given that you=92re= seeking info about mail services. >> =20 >> I provided an example earlier that would simply point to a config = file with server information. We could do this directly via WebFinger = like this: >> =20 >> GET /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com >> =20 >> This query would then return something like this: >> =20 >> { >> "subject" : "mailto:paulej@packetizer.com", >> "links" : >> [ >> { >> "rel" : "smtp-server", >> "properties" : >> { >> "host" : "smtp.packetizer.com", >> "port" : "587", >> "login-required" : "yes", >> "transport" : "starttls" >> } >> }, >> { >> "rel" : "imap-server", >> "properties" : >> { >> "host" : "imap.packetizer.com", >> "port" : "993", >> "transport" : "ssl" >> } >> } >> ] >> } >> =20 >> We would need to standardize the link relation values (smtp-server = and imap-server). We would also need to document what the various = properties would be. If you would like to create such a configuration = document based on WebFinger, I=92d be happy to help out. In any case, = you can see that WebFinger would serve quite nicely for conveying = configuration information given a user=92s email ID. >> =20 >> I=92m not sure exactly what you would need for OAuth endpoints, but I = would suggest you make that a separate document since it is not mail = related. (At least I assume it=92s not. Even if it were, the mail = server information and OAuth information are still different animals.) >> =20 >> Paul >> =20 >> From: William Mills [mailto:wmills@yahoo-inc.com]=20 >> Sent: Wednesday, June 13, 2012 7:32 PM >> To: Peter Saint-Andre >> Cc: Paul E. Jones; 'Cyrus Daboo'; apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Aggregated service discovery >> =20 >> In my use case it's a service/server. >> =20 >> Not a terribly happy answer to say "DNS SRV records won't work for = you, and there is no other solution.". By the same token I could ask = "Why do we need Webfinger and host meta at all if we have DNS SRV = records?". >> =20 >> If XMPP uses SRV records for discovery, that's fine. IMAP and = outbound SMTP services both lack a defined discovery method other than = the ubiquitous "service documentation". Is there a compelling reason to = pick DNS over WF for this? =46rom the app developer point of view I = don't want to have N ways to discover M services. >> =20 >> -bill >> =20 >> =20 >> From: Peter Saint-Andre >> To: William Mills =20 >> Cc: Paul E. Jones ; 'Cyrus Daboo' = ; "apps-discuss@ietf.org" =20 >> Sent: Wednesday, June 13, 2012 3:57 PM >> Subject: Re: [apps-discuss] Aggregated service discovery >>=20 >> On 6/13/12 4:54 PM, William Mills wrote: >> > As I said, I'm interested specifically in IMAP, SMTP and OAuth = endpoints.=20 >>=20 >> What exactly is an "endpoint"? A client? An account? A server? >>=20 >> > As a data point, DNS SRV records are not controllable in many = hosted >> > domain models. >>=20 >> At the last XMPP Summit a few months ago, we learned that DNS SRV >> records are unavailable in whole countries (e.g., Japan). That = doesn't >> mean we should define a replacement for DNS over HTTP. :) >>=20 >> Peter >>=20 >> --=20 >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 >>=20 >>=20 >> =20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 >=20 >=20 --Apple-Mail=_C0A35206-9E3E-4997-89CD-6EABDA051AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 That = is not what I am saying.

I am saying that the user's = discovery document has a link relation to the providers decryption of = the service.   That is different from the imap endpoint providing = the link relation.

If you can trust the user's = information to provide the Oauth endpoint why can't you trust the user's = information to link to the description of the = service.

As I have pointed out before you = probably don't want per user configuration for things like imap, =  the simplest thing is to describe the service in host-meta and = forget the extra user discovery steps and = maintenance.

John B.

On = 2012-06-18, at 3:19 PM, William Mills wrote:

Unfortunately we came to the = conclusion that letting a service endpoint define it's authenticators is = probably wrong, this was in the context of discovery for SASL = mechanisms.  The core problem is when the client supports the = password grant if it then trusts the service endpoint to tell it who to = give the username password pair then it's = vulnerable.

=
=
From: = John Bradley <ve7jtb@ve7jtb.com>
= To: Paul E. Jones = <paulej@packetizer.com>=
Cc: 'William = Mills' <wmills@yahoo-inc.com>; = 'Peter Saint-Andre' <stpeter@stpeter.im>; apps-discuss@ietf.org
= Sent: Monday, June 18, = 2012 11:36 AM
Subject: Re: [apps-discuss] Aggregated service = discovery

A user is likely to have a number = of OAuth authorization services for different things. =  

I suspect that the best way to organize it is = to describe the services the user has:
openID = Connect
imap
portable = contacts
etc

and let the service = describe how it is authenticated and where the endpoints = are.

For Connect there is a single relation for = the Connect issuer and that is then discovered to get the endpoint and = other configuration information.  
Given that user = identifiers may point to services in other domains it is best to leave = it up to the service to describe itself rather than relying on = individual user information to be correct.

John = B.

On 2012-06-18, at 2:22 PM, Paul E. Jones = wrote:

Bill,
 
In the referenced draft below, I assume the =93grant-types=94 = and =93token-types=94 should be contained inside a =93properties=94? = That is, I think you want this:
 
{
  "subject" : "acct:carol@example.com",
  "links" :
  [
    {
      "rel" : = "oauth2-athorize",
    },
    {
      "rel" : = "oauth2-token",
     "properties" :
      {
       "grant-types" : "code = password",
        "token-types" : = "bearer"
      }
    }
  ]
}
 
For auto-provisioning of email clients (which I understand = was your goal), we can either define one link relation that points to a = separate configuration document of some sort, or we define multiple link = relations.  My previous example showed the single link relation and = the email below shows use of multiple.  Both have pros and cons, = but I tend to favor using multiple link relations, since this allows one = to introduce new stuff without changing the one mail configuration = file.  Also, it reduces the number of queries a mail client has to make to get config information.
 
You indicate that IMAP already has a defined URI.  Where = is that defined?  I could not find it in the IANA link relations = registry, so I assume it=92s really a URI defined in a spec = somewhere.  In any case, we could use URIs for these things (rather = than defining single token link relation values and registering = them).  I have no preference, but I would like an agreed approach = to provisioning.  I hate configuring all the stuff manually on = email clients. :-)
 
Paul
 
From: William Mills = [mailto:wmills@yahoo-inc.com] 
Sent:=  Monday, = June 18, 2012 1:36 PM
To: Paul E. Jones; = 'Peter Saint-Andre'
Cc: 'Cyrus Daboo'; = apps-discuss@ietf.org
Subj= ect: Re: = [apps-discuss] Aggregated service discovery
 
Paul,
 
Thanks = for the reply on this.  I do already have a separate doc for = registering the OAuth specific relations,http://tools.ietf.org/id/d= raft-wmills-oauth-lrdd-01.html
=  
I don't = think I like the thought of having to register a new link type for every = service, but that might be the right way.  IMAP already has a URI = defined for example so if we use a more general link relation then the = URI scheme details the type.  The tradeoff is whether you can look = for a specific link-type or if you have to scan list elements for the = URI type you need.
=  
-bill
=  
=  
From: Paul E. Jones = <paulej@packetizer.com&= gt;
To: 'William = Mills' <wmills@yahoo-inc.com&g= t;; 'Peter Saint-Andre' <stpeter@stpeter.im>=  
Cc: 'Cyrus = Daboo' <cyrus@daboo.name>;<= span class=3D"yiv1198500501Apple-converted-space"> apps-discuss@ietf.org<= span = class=3D"yiv1198500501Apple-converted-space"> 
Sent:=  Sunday, = June 17, 2012 6:48 PM
Subject: RE: = [apps-discuss] Aggregated service discovery
 
Bill,
 
My apologies for the belated reply.  I=92ve been busy this = week and got rather behind on email.
 
I do not personally like using SRV records, either.  SRV = records could work for smaller domains, but I=92m not sure that they=92re = the best solution for larger domains.  Personally, I would prefer = putting users on specific servers or server clusters and SRV records = will not differentiate users.
 
To use WebFinger to find one=92s IMAP, SMTP, or POP server, we = could do as I suggested in my email.  Now the question is what does = one query?  Since these three services are email, I=92d suggest we = query =93mailto:paulej@packetizer.c= om=94.  We could use another URI scheme (e.g., =93acct:=94), = but mailto seems most appropriate given that you=92re seeking info about = mail services.
 
I provided an example earlier that would simply point to a config = file with server information.  We could do this directly via = WebFinger like this:
 
GET = /.well-known/host-meta?resource=3Dmailto:paulej@packetizer.com
 
This query would then return something like this:
 
{
  "links" :
  [
    {
   =    "rel" : "smtp-server",
      "properties" :
      {
        "host" : "smtp.packetizer.com",<= /span>
        "port" : = "587",
        "login-required" : = "yes",
        "transport" : = "starttls"
      }
    },
    {
   =    "rel" : "imap-server",
      "properties" :
      {
        "host" : "imap.packetizer.com",<= /span>
        "port" : = "993",
        "transport" : = "ssl"
      }
    }
  ]
}
 
We would need to standardize the link relation values = (smtp-server and imap-server).  We would also need to document what = the various properties would be.  If you would like to create such a configuration document based on WebFinger, I=92d = be happy to help out.  In any case, you can see that WebFinger = would serve quite nicely for conveying configuration information given a = user=92s email ID.
 
I=92m not sure exactly what you would need for OAuth endpoints, = but I would suggest you make that a separate document since it is not = mail related.  (At least I assume it=92s not.  Even if it were, the mail server information = and OAuth information are still different animals.)
 
Paul
 
From: William Mills [mailto:wmills@yahoo-inc.c= om] 
Sent:=  Wednesday,= June 13, 2012 7:32 PM
To: Peter = Saint-Andre
Cc: Paul E. Jones; = 'Cyrus Daboo'; apps-discuss@ietf.org<= br>Subject: Re: [apps-discuss] Aggregated service discovery
 
In my = use case it's a service/server.
 
Not a = terribly happy answer to say "DNS SRV records won't work for you, and = there is no other solution.".  By the same token I could ask "Why = do we need Webfinger and host meta at all if we have DNS SRV = records?".
 
If XMPP uses SRV records for discovery, that's = fine.  IMAP and outbound SMTP services both lack a defined = discovery method other than the ubiquitous "service = documentation".  Is there a compelling reason to pick DNS over WF = for this?  =46rom the app developer point of view I don't want to = have N ways to discover M services.
 
-bill
 
 
From: Peter = Saint-Andre <stpeter@stpeter.im>=
To: William Mills = <wmills@yahoo-inc.com&g= t; 
Cc: Paul E. = Jones <paulej@packetizer.com&= gt;; 'Cyrus Daboo' <cyrus@daboo.name>; = "apps-discuss@ietf.org"= <apps-discuss@ietf.org&= gt; 
Sent:=  Wednesday,= June 13, 2012 3:57 PM
Subject: Re: = [apps-discuss] Aggregated service discovery

On 6/13/12 4:54 PM, William Mills = wrote:
> As I said, I'm interested specifically in IMAP, SMTP and = OAuth endpoints. 

What = exactly is an "endpoint"? A client? An account? A server?

> As = a data point, DNS SRV records are not controllable in many = hosted
> domain models.

At the last XMPP Summit a few = months ago, we learned that DNS SRV
records are unavailable in whole = countries (e.g., Japan). That doesn't
mean we should define a = replacement for DNS over HTTP. :)

Peter

-- 
Peter = Saint-Andre
https://stpeter.im/



<= /div>
=  
= _______________________________________________
apps-discuss mailing = list
apps-discuss@ietf.org
https://www.ie= tf.org/mailman/listinfo/apps-discuss


=

= --Apple-Mail=_C0A35206-9E3E-4997-89CD-6EABDA051AA3-- --Apple-Mail=_39FEC628-0BD5-4285-A37D-112E73554ECC Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPnzCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDCCB+IwggXKoAMCAQICAQ4wDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NFoXDTEyMTAyMjIxMDI1NFowgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RAD teP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCA o7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXX fIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR6 5cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCA1swggNXMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGmMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBqAYDVR0jBIGgMIGd gBROC+8apEBbpRdphzDKNGhD0EGu8qGBgaR/MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkw JwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBATAJBgNVHRIEAjAAMD0G CCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAoYhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2Eu Y3J0MGAGA1UdHwRZMFcwLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zZnNjYS1jcmwu Y3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwggFdBgNVHSAEggFU MIIBUDCCAUwGCysGAQQBgbU3AQEEMIIBOzAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9p bnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBTdGFydCBDb21tZXJjaWFsIChTdGFy dENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxl Z2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkg UG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAR BglghkgBhvhCAQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMA0GCSqGSIb3DQEBBQUA A4ICAQAe9xAX/vbphHkvkDdNrslXWdO7fD3JaqnTT3jmmDu55r7UpW1H/v/J40UBXsw9DKU8TylE 4RwZT5HDAMW42f1x498AzM4FOnL/pUTTvr6BiRlrify5ZovkDYVWjy1GYTJ+hPiBEv0HmHnDxjhn JIIkEvJ+niMHLLEdpNMhZnxMiTFRAtIF4WeYcpgXBjAxsEDRKBvw40K+r3N4lykySQNp2ElIJ8H1 z2BmhxtppUdWpOVJ4Q1Gvn9jfV1qnMhFCDY+X1X8DrkKrTcpDExcGlefweQs7+DYUK3spiQkJpN7 qpPYlfy2GYHedv7lGa1ZAghMI/4882QVAK2zq6M60nHpOUMtYD61XtAs3ZD5L3yn9LCdeK2j4ZbQ 3uRdwvxAMFWwXyUK/ALP4lCu9QhxbnETOkBWT3FJul4/FUgzM0RRCEGhuQWiOFSoa35XJTcYf/4E /ZuvOXhK04nUpe7DYTMWzRqL04yyoJQVHKHKSboytueydKuqFZKdJA9gi77OnPBYL/yxkXGgkLC9 tsi77oT4AgZry0/6lgX56ak+f/umQihNPgtKSQQjEYq9S8MlOHzpUM0vxsghATYsdUPBw6r6ZxDH jXoUAD03DUMEbKsWvqFB7nJNVesngbu8miw1EYLA+fHfTaCidoV3CL75jKqM/KE87qrh9Fqti9bK qnkvpTGCA2wwggNoAgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsO AwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYx ODIwMTkwOVowIwYJKoZIhvcNAQkEMRYEFJp+0RrlA4Z7xFsas/s7UV+FHfeQMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAIL MYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIB ACBl1QXeOpmoGaKEbwGs/Q/2K1H0SW4yYbL2BfQJynjEtsSwEbcB424poCGwb97A7FLqs5lSb5Gv R8D6KhieYTXcoOKgD+rEZa2EdkIsS0C5zKJWlauFiNxV9XGNZKxflBKaMzUcK7AiacVrfR4/Yeas FzefJkQ6ylb2ih68Lu4cISeymTALgbeO8PBOnvsfu2r4XI9Vr2humb2Kbt9g4mzkF5tgXSFZZ8u3 jFEbbo9qm+Qk+ROTtHdupUtfKqFkLDFbKQ3Q75jj0+1AGQY+63eoVSjtbT4NKlKBmc2SuyG6vZ64 V3JnQwwNaTvEt1DffxGdrlvuXBlC797c8ZSF8XoAAAAAAAA= --Apple-Mail=_39FEC628-0BD5-4285-A37D-112E73554ECC--