From jpanzer@google.com Tue Dec 1 08:53:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204813A68FD for ; Tue, 1 Dec 2009 08:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.926 X-Spam-Level: X-Spam-Status: No, score=-105.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jW5tFlynKQn for ; Tue, 1 Dec 2009 08:53:11 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 8D1993A67B6 for ; Tue, 1 Dec 2009 08:53:11 -0800 (PST) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id nB1Gr3NG005648 for ; Tue, 1 Dec 2009 08:53:03 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259686384; bh=YHlZac/ZITWT3Sj7pRZwIPG3W+U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=qC9/AvUKk6dhWnkKtcCpecOPCoRjay6P/XMqOWmJs92+ekG4beNllbS4b+JVLrES7 q+rRxB5Fk024DM9KxybZQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=rTHwtl2kftS47ppA2QXVVMCrHuvuOhiEH1S4UcoSRBR3q1mrNhuZUPtWwi2igeZ8H ENGpIURdS326bDXaJMK4A== Received: from pzk11 (pzk11.prod.google.com [10.243.19.139]) by zps37.corp.google.com with ESMTP id nB1GqL21031528 for ; Tue, 1 Dec 2009 08:53:00 -0800 Received: by pzk11 with SMTP id 11so3365496pzk.14 for ; Tue, 01 Dec 2009 08:53:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.188.38 with SMTP id l38mr11422475waf.179.1259686380346; Tue, 01 Dec 2009 08:53:00 -0800 (PST) In-Reply-To: References: <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Tue, 1 Dec 2009 08:52:40 -0800 Message-ID: To: Mike Malone Content-Type: multipart/alternative; boundary=0016e64cd7923a9d120479ad9785 X-System-Of-Record: true Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 16:53:13 -0000 --0016e64cd7923a9d120479ad9785 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone wrote: > On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt > wrote: > > > > On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: > >> > >> I for one, see great value in offering some form of crypto-based > security for cases where TLS is not suitable. > > > > Are these use cases enumerated somewhere? > > I'm not completely opposed to the TLS route, but since you asked... > off the top of my head, here are a couple drawbacks to using TLS > instead of signing: > - Bigger burden on developers who need to debug this stuff (i.e., > you can't sniff your own traffic to debug requests & responses). > - Properly setting up TLS can be complicated and expensive. For > developers who don't have a lot of ops skills the barrier may be too > high. > - You can no longer pass around signed URLs as another level of > delegation (a use case that I use regularly for making XHR & POST > requests from the browser). This could be a non-issue if some other > mechanism for fourth-party delegation existed. > > Can you elaborate on the above? For OAuth, signatures (bound to a particular Consumer Secret that can't be leaked to subcontractors) is a barrier to multi-level delegation. > If we were coming up with a more secure replacement for browser-based > HTTP basic auth (and looking at Aza Raskin's work with identity in > Firefox, OAuth in the browser doesn't appear to be that far off) would > you want to mandate that all auth'd HTTP traffic use TLS? Not sure if > the answer is yes or no, but I'm guessing many of the > advantages/drawbacks will be the same. > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64cd7923a9d120479ad9785 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone <mjmalone@gmail.com= > wrote:
On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt <Dick.Hardt@microsoft.com> wrote= :
>
> On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote:
>>
>> I for one, see great value in offering some form of crypto-based s= ecurity for cases where TLS is not suitable.
>
> Are these use cases enumerated somewhere?

I'm not completely opposed to the TLS route, but since you asked.= ..
off the top of my head, here are a couple drawbacks to using TLS
instead of signing:
=A0- Bigger burden on developers who need to debug this stuff (i.e.,
you can't sniff your own traffic to debug requests & responses). =A0- Properly setting up TLS can be complicated and expensive. For
developers who don't have a lot of ops skills the barrier may be too high.
=A0- You can no longer pass around signed URLs as another level of
delegation (a use case that I use regularly for making XHR & POST
requests from the browser). This could be a non-issue if some other
mechanism for fourth-party delegation existed.

Can you elaborate on the above? =A0For OAuth, signatu= res (bound to a particular Consumer Secret that can't be leaked to subc= ontractors) is a barrier to multi-level delegation. =A0

=A0
If we were coming up with a more secure replacement for browser-based
HTTP basic auth (and looking at Aza Raskin's work with identity in
Firefox, OAuth in the browser doesn't appear to be that far off) would<= br> you want to mandate that all auth'd HTTP traffic use TLS? Not sure if the answer is yes or no, but I'm guessing many of the
advantages/drawbacks will be the same.

Mike
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e64cd7923a9d120479ad9785-- From beaton@google.com Tue Dec 1 09:52:17 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCDD13A68C1 for ; Tue, 1 Dec 2009 09:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+22Y4iImQJr for ; Tue, 1 Dec 2009 09:52:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id BD3B03A67F2 for ; Tue, 1 Dec 2009 09:52:16 -0800 (PST) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id nB1Hq4f0013511 for ; Tue, 1 Dec 2009 17:52:05 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259689927; bh=/EGLue88zxbX71YZ8AtTzIi6stA=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=RjMBQpQd8tzYDJs6TcF7zCAXnCQIPISJrRytQ9RKKEi91cCDV/gYuKOIiC+eYAno3 3L3Bc6w6S9o4CLQz/j5qg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:date:message-id:subject:from:to:content-type:x-system-of-record; b=JpHi1QHzMZAXfpOdLm4lVP+SiHMGyPmAONbr7S8Y5KO0uKSd+Zyz8sB/5NP1LjLl5 zyAvL9cAdPE/7BMjKWbmg== Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by spaceape7.eur.corp.google.com with ESMTP id nB1HmblK013930 for ; Tue, 1 Dec 2009 09:52:02 -0800 Received: by pxi1 with SMTP id 1so1047573pxi.25 for ; Tue, 01 Dec 2009 09:52:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.171.4 with SMTP id t4mr404621rve.260.1259689922211; Tue, 01 Dec 2009 09:52:02 -0800 (PST) Date: Tue, 1 Dec 2009 09:52:02 -0800 Message-ID: From: Brian Eaton To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] delegation, authentication, public key, hmac, and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:52:17 -0000 I'm going to try to summarize some conversations that happened in other threads on these topics. Our story so far: A significant number of people don't think any crypto is necessary for most use cases. Some folks want HMAC to protect token secrets over HTTP. [1]. Several people believe public key cryptography is necessary for bootstrapping authentication. [2]. A few people have expressed a preference for public key signing of individual data access requests. [1] and [2]. Everybody is in favor of a model that allows new signature algorithms to be added in the future. [3]. No one appears to be arguing strongly that data access requests (as opposed to the initial authentication/authorization) need to be signed *both* with public key and HMAC. To meet these requirements, I think we should 1) Agree on a signature base string, something sort of like the signature base string in OAuth 1.0a. [4] 2) Agree on a system for naming signature algorithms. 3) Agree on profiles for combining bearer tokens/redirects/signed tokens into reusable profiles to address different use cases. I'd fully expect people to mix-and-match and come up with new profiles that trade-off security, complexity, and latency in ways that address their individual use cases. My hope would be that they could reuse as much of the signature base string and the signature algorithms as possible. Sound reasonable? Cheers, Brian [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00506.html [2] http://www.ietf.org/mail-archive/web/oauth/current/msg00630.html [3] http://www.ietf.org/mail-archive/web/oauth/current/msg00585.html [4] http://oauth.net/core/1.0a#anchor13 From mjmalone@gmail.com Tue Dec 1 10:22:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68B03A697C for ; Tue, 1 Dec 2009 10:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4Ebtl0XzmKh for ; Tue, 1 Dec 2009 10:22:49 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id B87203A6967 for ; Tue, 1 Dec 2009 10:22:48 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so1003852qwb.31 for ; Tue, 01 Dec 2009 10:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3+kPquppk99TQJYYczfBoYa0x3JWlpyQtriOygeSRpI=; b=v6kLpGpAQ902QDdtoRmjcsRUfxep6LZpIGNAL4mCNied7j0YujX1hyZUDJRcDV3G0+ tud8h+FDTd73N9KFR5qSFrthYK3t3p7PT0HCjpcBfmUX+J73kc1fVNbKidBIEQWAMaF+ tEZBOH8dJW4I8tMK0eWN3ftnsHan9S4J+id40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l3FvgxifAbTYDJuzfcH/L0LM8bT1Qx8Gjv+mzCr9lZgm3yAoHWndiXmHWyjVPk5kSe b9tivkjjcoP6Ecofyj8J805840ijG1DQX7LGDIULTfPdlLCKQ9txWlbCsqcVOdPNF3f9 XdFRACEELRxX9b8fFWGUloPvo/f/ig5cpbrTg= MIME-Version: 1.0 Received: by 10.229.29.204 with SMTP id r12mr724207qcc.72.1259691758579; Tue, 01 Dec 2009 10:22:38 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 1 Dec 2009 10:22:38 -0800 Message-ID: From: Mike Malone To: John Panzer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:22:50 -0000 On Tue, Dec 1, 2009 at 8:52 AM, John Panzer wrote: > On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone wrote: >> >> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt >> wrote: >> > >> > On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: >> >> >> >> I for one, see great value in offering some form of crypto-based >> >> security for cases where TLS is not suitable. >> > >> > Are these use cases enumerated somewhere? >> >> I'm not completely opposed to the TLS route, but since you asked... >> off the top of my head, here are a couple drawbacks to using TLS >> instead of signing: >> =A0- Bigger burden on developers who need to debug this stuff (i.e., >> you can't sniff your own traffic to debug requests & responses). >> =A0- Properly setting up TLS can be complicated and expensive. For >> developers who don't have a lot of ops skills the barrier may be too >> high. >> =A0- You can no longer pass around signed URLs as another level of >> delegation (a use case that I use regularly for making XHR & POST >> requests from the browser). This could be a non-issue if some other >> mechanism for fourth-party delegation existed. >> > Can you elaborate on the above? =A0For OAuth, signatures (bound to a > particular Consumer Secret that can't be leaked to subcontractors) is a > barrier to multi-level delegation. Right, but you can do poor-man's delegation by signing a URL and passing it off to a third (er, fourth) party to use. I've seen this most often with web apps, where the app (the OAuth Consumer) wants to make a request to the Provider directly from the browser (e.g., POSTing a large file). They can't sign the URL in javascript without compromising the Consumer Secret, so the the URL is signed server side and passed to the browser for use. Mike From jpanzer@google.com Tue Dec 1 10:34:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4AA3A6A3F for ; Tue, 1 Dec 2009 10:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.931 X-Spam-Level: X-Spam-Status: No, score=-105.931 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4Z992WL5eNB for ; Tue, 1 Dec 2009 10:34:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 035DD3A68D9 for ; Tue, 1 Dec 2009 10:34:40 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id nB1IYVGr001605 for ; Tue, 1 Dec 2009 18:34:32 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259692472; bh=xrkEY7edybSGym3qSTbobconK6Q=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=kFYPi7p+++je6kV1v0fI7hP/6S8aZw/ZgA/T9hMz1/pv8PDeveEEdb4FVTrjkpTZJ jd6Qp18QOGwzJ9AcDF9mw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=iqlOLGj6P4zttrj7F8OklhG9ZKxMfFPwzQJYmgPVPhWQiiX/bGK11AQvhkeZUbMAG XFitT8833kpOOctNxHK0w== Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by wpaz29.hot.corp.google.com with ESMTP id nB1IXr0d030381 for ; Tue, 1 Dec 2009 10:34:28 -0800 Received: by pxi1 with SMTP id 1so1097791pxi.25 for ; Tue, 01 Dec 2009 10:34:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.151.5 with SMTP id d5mr11646426wao.204.1259692466357; Tue, 01 Dec 2009 10:34:26 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Tue, 1 Dec 2009 10:34:05 -0800 Message-ID: To: Mike Malone Content-Type: multipart/alternative; boundary=0016e64eeb64fbc6210479af01bf X-System-Of-Record: true Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:34:42 -0000 --0016e64eeb64fbc6210479af01bf Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 1, 2009 at 10:22 AM, Mike Malone wrote: > On Tue, Dec 1, 2009 at 8:52 AM, John Panzer wrote: > > On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone wrote: > >> > >> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt > >> wrote: > >> > > >> > On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: > >> >> > >> >> I for one, see great value in offering some form of crypto-based > >> >> security for cases where TLS is not suitable. > >> > > >> > Are these use cases enumerated somewhere? > >> > >> I'm not completely opposed to the TLS route, but since you asked... > >> off the top of my head, here are a couple drawbacks to using TLS > >> instead of signing: > >> - Bigger burden on developers who need to debug this stuff (i.e., > >> you can't sniff your own traffic to debug requests & responses). > >> - Properly setting up TLS can be complicated and expensive. For > >> developers who don't have a lot of ops skills the barrier may be too > >> high. > >> - You can no longer pass around signed URLs as another level of > >> delegation (a use case that I use regularly for making XHR & POST > >> requests from the browser). This could be a non-issue if some other > >> mechanism for fourth-party delegation existed. > >> > > Can you elaborate on the above? For OAuth, signatures (bound to a > > particular Consumer Secret that can't be leaked to subcontractors) is a > > barrier to multi-level delegation. > > Right, but you can do poor-man's delegation by signing a URL and > passing it off to a third (er, fourth) party to use. I've seen this > most often with web apps, where the app (the OAuth Consumer) wants to > make a request to the Provider directly from the browser (e.g., > POSTing a large file). They can't sign the URL in javascript without > compromising the Consumer Secret, so the the URL is signed server side > and passed to the browser for use. > That's the reverse (proxy authorization) -- the client is relying on the proxy to do the signing, and the proxy has to figure out based on other stuff (browser cookies, magic incantations) whether _its_ client is authorized. This is the OAuth Proxy model. I thought you were talking about being able to get user consent for service X to do something, but then service X sub-contracts out some of the work to service Y, perhaps run by a separate organization. Y can call-back to X to do its work, neatly defeating some of the purpose of sub-contracting work out as everything flows through X anyway. Or X could hand a signed URL to Y, but then Y can only deal with what was actually signed, and can't vary the parameters, again defeating much of the purpose of subcontracting. Also, isn't there a nonce in there? So Y can only make one call with that URL before returning to the well. It'd be much better to (in an extension!) be able to say "Give me a token just like the one I have, but read-only, and only valid for 3 minutes, and I'm going to let another service use it" and get a restricted token to hand off to a sub-contractor[1]. In any case, I don't see how signing the URL helps with doing something along these lines, and I think if it does anything at all it hurts (because of inclusion of things like nonces and timestamps). Yeah, there are some basic use cases for it, like getting access to a read-only feed (capability URLs) but those can be accomplished quite as well and more simply with bearer tokens IMHO. John [1] I am going on strike and refusing to go beyond "third party" as there are actually an infinite number of parties and use cases here and I can't keep them straight any more. > > Mike > --0016e64eeb64fbc6210479af01bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 1, 2009 at 10:22 AM, Mike Malone <mjmalone@gmail.com= > wrote:
On Tue, Dec 1, 2009 at 8:52 AM, John Panzer <jpanzer@google.com> wrote:
> On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone <mjmalone@gmail.com> wrote:
>>
>> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt <Dick.Hardt@microsoft.com>
>> wrote:
>> >
>> > On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote:
>> >>
>> >> I for one, see great value in offering some form of crypt= o-based
>> >> security for cases where TLS is not suitable.
>> >
>> > Are these use cases enumerated somewhere?
>>
>> I'm not completely opposed to the TLS route, but since you ask= ed...
>> off the top of my head, here are a couple drawbacks to using TLS >> instead of signing:
>> =A0- Bigger burden on developers who need to debug this stuff (i.e= .,
>> you can't sniff your own traffic to debug requests & respo= nses).
>> =A0- Properly setting up TLS can be complicated and expensive. For=
>> developers who don't have a lot of ops skills the barrier may = be too
>> high.
>> =A0- You can no longer pass around signed URLs as another level of=
>> delegation (a use case that I use regularly for making XHR & P= OST
>> requests from the browser). This could be a non-issue if some othe= r
>> mechanism for fourth-party delegation existed.
>>
> Can you elaborate on the above? =A0For OAuth, signatures (bound to a > particular Consumer Secret that can't be leaked to subcontractors)= is a
> barrier to multi-level delegation.

Right, but you can do poor-man's delegation by signing a URL and<= br> passing it off to a third (er, fourth) party to use. I've seen this
most often with web apps, where the app (the OAuth Consumer) wants to
make a request to the Provider directly from the browser (e.g.,
POSTing a large file). They can't sign the URL in javascript without compromising the Consumer Secret, so the the URL is signed server side
and passed to the browser for use.

That= 's the reverse (proxy authorization) -- the client is relying on the pr= oxy to do the signing, and the proxy has to figure out based on other stuff= (browser cookies, magic incantations) whether _its_ client is authorized. = =A0This is the OAuth Proxy model.

I thought you were talking about being able to get user= consent for service X to do something, but then service X sub-contracts ou= t some of the work to service Y, perhaps run by a separate organization. = =A0Y can call-back to X to do its work, neatly defeating some of the purpos= e of sub-contracting work out as everything flows through X anyway. =A0Or X= could hand a signed URL to Y, but then Y can only deal with what was actua= lly signed, and can't vary the parameters, again defeating much of the = purpose of subcontracting. =A0Also, isn't there a nonce in there? =A0So= Y can only make one call with that URL before returning to the well.

It'd be much better to (in an extension!) be able t= o say "Give me a token just like the one I have, but read-only, and on= ly valid for 3 minutes, and I'm going to let another service use it&quo= t; and get a restricted token to hand off to a sub-contractor[1].

In any case, I don't see how signing the URL helps = with doing something along these lines, and I think if it does anything at = all it hurts (because of inclusion of things like nonces and timestamps). = =A0Yeah, there are some basic use cases for it, like getting access to a re= ad-only feed (capability URLs) but those can be accomplished quite as well = and more simply with bearer tokens IMHO.

John

[1] I am going on strike = and refusing to go beyond "third party" as there are actually an = infinite number of parties and use cases here and I can't keep them str= aight any more.
=A0

Mike

--0016e64eeb64fbc6210479af01bf-- From Dick.Hardt@microsoft.com Tue Dec 1 10:56:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBAD3A6946 for ; Tue, 1 Dec 2009 10:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxz7YXlVByW6 for ; Tue, 1 Dec 2009 10:56:02 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id AF2783A6921 for ; Tue, 1 Dec 2009 10:56:02 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Dec 2009 10:56:21 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi; Tue, 1 Dec 2009 10:52:54 -0800 From: Dick Hardt To: Mike Malone Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5EuVfSAgAED2ACAAt81AIAAASmAgABrE4CAAH1JAIABBIUAgACcJwCAAAx/gIAa2A2AgAA2ZwCAAVTsAA== Date: Tue, 1 Dec 2009 18:52:40 +0000 Message-ID: <2944C863-B474-4E4D-BFCB-734BF8F29406@microsoft.com> References: <4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de> <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <6bf10c85-e4cd-4cd6-a466-ff7f9be72872> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:56:03 -0000 Thanks for the response Mike, comments inline ...=20 On 2009-11-30, at 12:32 PM, Mike Malone wrote: > On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt w= rote: >>=20 >> On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: >>>=20 >>> I for one, see great value in offering some form of crypto-based securi= ty for cases where TLS is not suitable. >>=20 >> Are these use cases enumerated somewhere? >=20 > I'm not completely opposed to the TLS route, but since you asked... > off the top of my head, here are a couple drawbacks to using TLS > instead of signing: > - Bigger burden on developers who need to debug this stuff (i.e., > you can't sniff your own traffic to debug requests & responses). > - Properly setting up TLS can be complicated and expensive. For > developers who don't have a lot of ops skills the barrier may be too > high. These sound barriers to a developer using TLS as opposed to use cases where= TLS is not suitable. OAuth 1.0A has similar burdens compared to getting the user's username and = password. - find a library for OAuth for your platform and install it (which may not = be possible in a shared hosting environment) - acquire a Consumer Key and Secret and store it somewhere secure > - You can no longer pass around signed URLs as another level of > delegation (a use case that I use regularly for making XHR & POST > requests from the browser). This could be a non-issue if some other > mechanism for fourth-party delegation existed. I don't understand this use case. Would you be able to provide a pointer to= a description somewhere?= From mjmalone@gmail.com Tue Dec 1 11:01:51 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5DD28C0E9 for ; Tue, 1 Dec 2009 11:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciDa+53YNJxn for ; Tue, 1 Dec 2009 11:01:50 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id DD41D3A6965 for ; Tue, 1 Dec 2009 11:01:49 -0800 (PST) Received: by qyk41 with SMTP id 41so2546699qyk.29 for ; Tue, 01 Dec 2009 11:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hfq7YjoOu3KMCYtae7/jZffjB9Uivj2YoWuSJXbYe6Q=; b=sFCuKK49tN/wz6RYSdft1Ejl4vhkRdIKTC3L4LdCSGj6X77zW8iqhY4zoXL6D32Om9 dFeYzuEMGYSu5OARQDGZ3uqZDn7cybprexbNT7rvBPlKcIoT5ioabPIY+TdpcUw7kaD9 BG5DRN7cUoFlScGxk6oCe/hF5UYTckJA/hmQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EPsA33CxHLxQgWSS1OcXRwkJDtmVHOQq/bp0GZlBVlgWMlgTdConKvhgSoa2Qi1jwC q3j0oYMchK3ZJJ+YkOSzYZ3wKDO0RU2YkOUKEN7bJEdOoyCj5GUCnWyy0rm75GnXnYWt SDqIWieK1atO9kpA2+Gj2R8SHZ3V1R+gx4LLw= MIME-Version: 1.0 Received: by 10.229.29.148 with SMTP id q20mr876078qcc.51.1259694097421; Tue, 01 Dec 2009 11:01:37 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 1 Dec 2009 11:01:37 -0800 Message-ID: From: Mike Malone To: John Panzer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:01:51 -0000 On Tue, Dec 1, 2009 at 10:34 AM, John Panzer wrote: > On Tue, Dec 1, 2009 at 10:22 AM, Mike Malone wrote: >> >> On Tue, Dec 1, 2009 at 8:52 AM, John Panzer wrote: >> > On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone wrot= e: >> >> >> >> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt >> >> wrote: >> >> > >> >> > On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: >> >> >> >> >> >> I for one, see great value in offering some form of crypto-based >> >> >> security for cases where TLS is not suitable. >> >> > >> >> > Are these use cases enumerated somewhere? >> >> >> >> I'm not completely opposed to the TLS route, but since you asked... >> >> off the top of my head, here are a couple drawbacks to using TLS >> >> instead of signing: >> >> =A0- Bigger burden on developers who need to debug this stuff (i.e., >> >> you can't sniff your own traffic to debug requests & responses). >> >> =A0- Properly setting up TLS can be complicated and expensive. For >> >> developers who don't have a lot of ops skills the barrier may be too >> >> high. >> >> =A0- You can no longer pass around signed URLs as another level of >> >> delegation (a use case that I use regularly for making XHR & POST >> >> requests from the browser). This could be a non-issue if some other >> >> mechanism for fourth-party delegation existed. >> >> >> > Can you elaborate on the above? =A0For OAuth, signatures (bound to a >> > particular Consumer Secret that can't be leaked to subcontractors) is = a >> > barrier to multi-level delegation. >> >> Right, but you can do poor-man's delegation by signing a URL and >> passing it off to a third (er, fourth) party to use. I've seen this >> most often with web apps, where the app (the OAuth Consumer) wants to >> make a request to the Provider directly from the browser (e.g., >> POSTing a large file). They can't sign the URL in javascript without >> compromising the Consumer Secret, so the the URL is signed server side >> and passed to the browser for use. > > That's the reverse (proxy authorization) -- the client is relying on the > proxy to do the signing, and the proxy has to figure out based on other > stuff (browser cookies, magic incantations) whether _its_ client is > authorized. =A0This is the OAuth Proxy model. Yea sort of. It's proxying the signing, but it's not proxying the actual request. > I thought you were talking about being able to get user consent for servi= ce > X to do something, but then service X sub-contracts out some of the work = to > service Y, perhaps run by a separate organization. =A0Y can call-back to = X to > do its work, neatly defeating some of the purpose of sub-contracting work > out as everything flows through X anyway. =A0Or X could hand a signed URL= to > Y, but then Y can only deal with what was actually signed, and can't vary > the parameters, again defeating much of the purpose of subcontracting. > =A0Also, isn't there a nonce in there? =A0So Y can only make one call wit= h that > URL before returning to the well. All true. The use case where this becomes incredibly useful (despite the limitations you mentioned) is for allowing file uploads from the browser without the Consumer proxying everything. Since OAuth doesn't sign a multipart/form-data body you can vary that without a problem. And since the file upload typically takes some time, asking the Consumer for a signed URL for each request isn't much of a burden. > It'd be much better to (in an extension!) be able to say "Give me a token > just like the one I have, but read-only, and only valid for 3 minutes, an= d > I'm going to let another service use it" and get a restricted token to ha= nd > off to a sub-contractor[1]. Yes. I want that. > In any case, I don't see how signing the URL helps with doing something > along these lines, and I think if it does anything at all it hurts (becau= se > of inclusion of things like nonces and timestamps). =A0Yeah, there are so= me > basic use cases for it, like getting access to a read-only feed (capabili= ty > URLs) but those can be accomplished quite as well and more simply with > bearer tokens IMHO. Yea, an extension would be nice. I guess what I'm saying is that whatever we do moving forward should at least keep the basic level of delegation we have, however naive and broken it is, because it's useful. > John > [1] I am going on strike and refusing to go beyond "third party" as there > are actually an infinite number of parties and use cases here and I can't > keep them straight any more. Thank god. Mike From GFFletch@aol.com Tue Dec 1 11:22:04 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A3183A696E for ; Tue, 1 Dec 2009 11:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA7KmunP9xYU for ; Tue, 1 Dec 2009 11:22:01 -0800 (PST) Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by core3.amsl.com (Postfix) with ESMTP id D9DD53A6959 for ; Tue, 1 Dec 2009 11:21:58 -0800 (PST) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB1JLPW2016981; Tue, 1 Dec 2009 14:21:25 -0500 Received: from GFFletch@aol.com by imo-da04.mx.aol.com (mail_out_v42.5.) id o.c45.4059df91 (37258); Tue, 1 Dec 2009 14:21:20 -0500 (EST) Received: from palantir.local ([10.181.87.216]) by cia-ma07.mx.aol.com (v126.13) with ESMTP id MAILCIAMA078-918a4b156cb0248; Tue, 01 Dec 2009 14:21:20 -0500 Message-ID: <4B156CB0.5040001@aol.com> Date: Tue, 01 Dec 2009 14:21:20 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Mike Malone References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.87.216 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 19:22:04 -0000 In addition to the use case Mike gave, I have seen at least two other use cases of having the "proxy" sign the URL and then present over HTTP. 1. an iGoogle gadget that wants to launch an iframe with a URL that carries specific identity & authorized rights 2. a rich/desktop application want to launch a browser in an authenticated/authorized state (i.e. client-to-browser SSO) I also haven't seen anyone bring up the "restricted device" use case yet:) I do work with a product team that refuses to use SSL because of the memory, load time, and CPU requirements. Curious if any in the mobile device environment see the requirement of SSL an issue? Potentially not given most devices these days have a browser. Thanks, George Mike Malone wrote: > On Tue, Dec 1, 2009 at 8:52 AM, John Panzer wrote: > >> On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone wrote: >> >>> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt >>> wrote: >>> >>>> On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: >>>> >>>>> I for one, see great value in offering some form of crypto-based >>>>> security for cases where TLS is not suitable. >>>>> >>>> Are these use cases enumerated somewhere? >>>> >>> I'm not completely opposed to the TLS route, but since you asked... >>> off the top of my head, here are a couple drawbacks to using TLS >>> instead of signing: >>> - Bigger burden on developers who need to debug this stuff (i.e., >>> you can't sniff your own traffic to debug requests & responses). >>> - Properly setting up TLS can be complicated and expensive. For >>> developers who don't have a lot of ops skills the barrier may be too >>> high. >>> - You can no longer pass around signed URLs as another level of >>> delegation (a use case that I use regularly for making XHR & POST >>> requests from the browser). This could be a non-issue if some other >>> mechanism for fourth-party delegation existed. >>> >>> >> Can you elaborate on the above? For OAuth, signatures (bound to a >> particular Consumer Secret that can't be leaked to subcontractors) is a >> barrier to multi-level delegation. >> > > Right, but you can do poor-man's delegation by signing a URL and > passing it off to a third (er, fourth) party to use. I've seen this > most often with web apps, where the app (the OAuth Consumer) wants to > make a request to the Provider directly from the browser (e.g., > POSTing a large file). They can't sign the URL in javascript without > compromising the Consumer Secret, so the the URL is signed server side > and passed to the browser for use. > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From beaton@google.com Tue Dec 1 15:31:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EEAE3A6934 for ; Tue, 1 Dec 2009 15:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWlVWQODHn2E for ; Tue, 1 Dec 2009 15:31:51 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 7FAB73A6872 for ; Tue, 1 Dec 2009 15:31:51 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id nB1NVfZV004086 for ; Tue, 1 Dec 2009 23:31:41 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259710301; bh=pKDeXaj+OQzQhIVCM9D8//19hY0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Ln8VgslkazqE/l/UjgydOruizdf2j5tGsAOWqjSpzBi87l+fby93bp1kE2BN1bctg 13ZHoZfzfmn00oIyxpK/w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=hQiG25ge5n6EbfL3IF86DquAJOgBCIYox6DWUDjuTn8CfpCECZw8cesm1XESAJ9XR j8m/nrc1g+3tiT/qtvqmQ== Received: from pzk38 (pzk38.prod.google.com [10.243.19.166]) by wpaz24.hot.corp.google.com with ESMTP id nB1NUrmF020720 for ; Tue, 1 Dec 2009 15:31:38 -0800 Received: by pzk38 with SMTP id 38so4254016pzk.9 for ; Tue, 01 Dec 2009 15:31:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.165.13 with SMTP id n13mr383590rve.3.1259710298291; Tue, 01 Dec 2009 15:31:38 -0800 (PST) In-Reply-To: <4B156CB0.5040001@aol.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B156CB0.5040001@aol.com> Date: Tue, 1 Dec 2009 15:31:38 -0800 Message-ID: From: Brian Eaton To: George Fletcher Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 23:31:52 -0000 On Tue, Dec 1, 2009 at 11:21 AM, George Fletcher wrote: > In addition to the use case Mike gave, I have seen at least two other use > cases of having the "proxy" sign the URL and then present over HTTP. > 1. an iGoogle gadget that wants to launch an iframe with a URL that carries > specific identity & authorized rights > 2. a rich/desktop application want to launch a browser in an > authenticated/authorized state (i.e. client-to-browser SSO) OK, so now we're up to 7 (8?) different use cases where "OAuth" signatures are being used. Some others are listed here: http://www.ietf.org/mail-archive/web/oauth/current/msg00544.html ... most of them still inventing their own signature base strings, which I find either amusing or tragic depending on my mood. =) > I also haven't seen anyone bring up the "restricted device" use case yet:) I > do work with a product team that refuses to use SSL because of the memory, > load time, and CPU requirements. So what do these folks deem to be acceptable, security-wise? (I'll put my money on "short-lived bearer token that is automatically refreshed at intervals"... =) > Curious if any in the mobile device > environment see the requirement of SSL an issue? Potentially not given most > devices these days have a browser. I hear this now and again, but every time I've looked at it seriously it's turned out to be a non-issue. Cheers, Brian From breno.demedeiros@gmail.com Tue Dec 1 15:52:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7D528C0D7 for ; Tue, 1 Dec 2009 15:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLG+hU5sSJRv for ; Tue, 1 Dec 2009 15:52:33 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id A9C2B3A6923 for ; Tue, 1 Dec 2009 15:52:27 -0800 (PST) Received: by yxe30 with SMTP id 30so10672729yxe.29 for ; Tue, 01 Dec 2009 15:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YaTh+0qpzEPvSZGXkbYr2MzUrW+knYhSPYn5wwSwvqA=; b=xeSheEBhSLEmb3hUlX56M1hNkI8uZVRtv5sauzWUW73F1t8JZgH2kV3ozcn4/IobQ6 yimYEo5CLsBPgs42IYRiKfWo65855LcdtSIRX9SsoTPlNfLLalyuJMwd6X6OwuWhIQyL +TLAd3Cr4VclI51lRBwd/KCCUmdxguf5FY31M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=w763i7vpG9BQ91+D9dFpMp0Oe+0JNY6Fzbk+kyPIyLCKtNcMRYkCXcnuPR1j8KJadY 3xyviowd9HtJgXqvLPLydmZXpplBqKRSrn5zAHtODxF2WgLBnyd0ClR8ABp3AQ0w+b+P rKqLuF7YvaC5NenXoQt8g01I6Nk+xJ/NpdPk0= MIME-Version: 1.0 Received: by 10.101.7.33 with SMTP id k33mr796259ani.131.1259711537197; Tue, 01 Dec 2009 15:52:17 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209B8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 1 Dec 2009 15:52:17 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636c5bfcdb1bc460479b3723d Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 23:52:35 -0000 --001636c5bfcdb1bc460479b3723d Content-Type: text/plain; charset=ISO-8859-1 Eran, The HMAC approach also requires key management. The fact that the community has punted on it to an out-of-band channel doesn't mean that the problem has been addressed. Typical security recommendations for shared keys is that they should be rotated more often than public keys. It would be quite reasonable, from a security perspective, for a provider to want to be specify that HMAC signing keys should be rotated weekly. For instance, the US Government profile for OpenID requires daily rotation of HMAC signing values. What then? The spec should support key management, with or without PK signing mechanisms. On Mon, Nov 30, 2009 at 11:32 AM, Eran Hammer-Lahav wrote: > The issue with RSA-SHA1-like method isn't the signature or crypto. Those > are trivial to spec out. The issue is everything else we didn't cover in 1.0 > including key management and rotation, and how to establish it. > > We had rough consensus about dropping the client credentials (consumer key) > from protected resources requests. This means you may use client credentials > to request a token, but once you have the token, you don't need to use the > client credentials anymore. The implications of this are that any PK-based > method will need to work at the token level, not the client level. > > With this approach, it will be easy to include a PK method alongside an > HMAC method, but it is not clear how the secret portion of the token pair > will be obtained and managed. My limited understanding suggests that issuing > a token-secret pair isn't the same as a token-Private Key pair. Maybe I'm > wrong and it can be made as trivial. > > And no, there will be nothing to prevent such an extension. > > EHL > > > -----Original Message----- > > From: Hans Granqvist [mailto:hans@granqvist.com] > > Sent: Monday, November 30, 2009 9:31 AM > > To: OAuth WG (oauth@ietf.org) > > Cc: Eran Hammer-Lahav; Pelle Braendgaard > > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > > > It's tricky. If you allow only MACs, you have to forgo no only RSA (and > ECC...) > > but also potentially traditional symmetric key schemes -- their usability > > notwithstanding. > > > > On the other hand, if you try to cover all possible key schemes, it > quickly > > becomes unmanageable. > > > > Eran, is there a way to define what you want and leave it open for, say > an > > RSA extension, as long as it can be represented as a string, such as > > {ALGORITHM}:{STRING}, and where any extra protocol flows are out of this > > specification's scope? > > > > -Hans > > > > > > On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard > > wrote: > > > +1 for all minus dropping RSA. > > > > > > I think the main reason we haven't seen a lot of RSA implementations > > > yet has been because the kind of businesses who I think would be > > > interested in using this such as banks/payments etc are not > > > traditionally early adopters. If we want to see OAUTH used in these > > > areas in the future I think it would be a very good idea to leave it > > > in. > > > > > > I am personally working on creating new OAuth based financial > > > transaction standard called OpenTransact, where we are planning on > > > standardizing on RSA in the next revision. > > > > > > Regards > > > Pelle > > > > > > > > > On Mon, Nov 30, 2009 at 2:34 AM, Eran Hammer-Lahav > > wrote: > > >> > > >> > > >>> -----Original Message----- > > >>> From: Paul C. Bryan [mailto:email@pbryan.net] > > >>> Sent: Sunday, November 29, 2009 3:08 PM > > >>> To: Eran Hammer-Lahav > > >>> Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > > >>> (lisa.dusseault@gmail.com); OAuth WG (oauth@ietf.org) > > >>> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > >>> > > >>> To the overall approach, +1. > > >>> > > >>> Some follow-up questions: > > >>> > > >>> 1. Why drop RSA? It seems some form of public key cryptography will > > >>> be necessary/useful to make web-based-attribute-containing tokens > > >>> Internet- scalable. > > >> > > >> Mostly due to lack of implementation experience or interest within the > > OAuth community. But also because the Plain and MAC versions are based > > on a simple symmetric shared secret, while PK requires more. This means > we > > will need to support different types of tokens. While I am open to this > if > > needed, it seems to add a significant complexity. Also, part 2 will then > need > > to be able to provision both symmetric and asymmetric secrets which adds > to > > the complexity there. > > >> > > >> In other words, why put the effort in if no one is asking for this > (based on > > 2 years of deployment experience). > > >> > > >>> 2. Is it an objective to have the Token auth-scheme contain > > >>> extension points so that new token formats can be introduced without > > >>> need to redefine the scheme or draft a new one? > > >> > > >> Yes, but see above. > > >> > > >> EHL > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > > > > > > > > > > -- > > > http://agree2.com - Reach Agreement! > > > http://extraeagle.com - Solutions for the electronic Extra Legal world > > > http://stakeventures.com - Bootstrapping blog > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Breno de Medeiros --001636c5bfcdb1bc460479b3723d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eran,

The HMAC approach also requires key management. Th= e fact that the community has punted on it to an out-of-band channel doesn&= #39;t mean that the problem has been addressed.=A0

Typical security recommendations for shared keys is that they should be rot= ated more often than public keys. It would be quite reasonable, from a secu= rity perspective, for a provider to want to be specify that HMAC signing ke= ys should be rotated weekly. For instance, the US Government profile for Op= enID requires daily rotation of HMAC signing values.

What then?

The spec should sup= port key management, with or without PK signing mechanisms.

<= /div>

On Mon, Nov 30, 2009 at 11:32 AM, = Eran Hammer-Lahav <eran@hueniverse.com> wrote:
The issue with RSA-SHA1-like method isn'= ;t the signature or crypto. Those are trivial to spec out. The issue is eve= rything else we didn't cover in 1.0 including key management and rotati= on, and how to establish it.

We had rough consensus about dropping the client credentials (consumer key)= from protected resources requests. This means you may use client credentia= ls to request a token, but once you have the token, you don't need to u= se the client credentials anymore. The implications of this are that any PK= -based method will need to work at the token level, not the client level.
With this approach, it will be easy to include a PK method alongside an HMA= C method, but it is not clear how the secret portion of the token pair will= be obtained and managed. My limited understanding suggests that issuing a = token-secret pair isn't the same as a token-Private Key pair. Maybe I&#= 39;m wrong and it can be made as trivial.

And no, there will be nothing to prevent such an extension.

EHL

> -----Original Message-----
> From: Hans Granqvist [mailto:han= s@granqvist.com]
> Sent: Monday, November 30, 2009 9:31 AM
> To: OAuth WG (oauth@ietf.org) > Cc: Eran Hammer-Lahav; Pelle Braendgaard
> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
>
> It's tricky. If you allow only MACs, you have to forgo no only RSA= (and ECC...)
> but also potentially traditional symmetric key schemes -- their usabil= ity
> notwithstanding.
>
> On the other hand, if you try to cover all possible key schemes, it qu= ickly
> becomes unmanageable.
>
> Eran, is there a way to define what you want and leave it open for, sa= y an
> RSA extension, as long as it can be represented as a string, such as > {ALGORITHM}:{STRING}, and where any extra protocol flows are out of th= is
> specification's scope?
>
> -Hans
>
>
> On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard
> <pelle@stakeventures.com= > wrote:
> > +1 for all minus dropping RSA.
> >
> > I think the main reason we haven't seen a lot of RSA implemen= tations
> > yet has been because the kind of businesses who I think would be<= br> > > interested in using this such as banks/payments etc are not
> > traditionally early adopters. If we want to see OAUTH used in the= se
> > areas in the future I think it would be a very good idea to leave= it
> > in.
> >
> > I am personally working on creating new OAuth based financial
> > transaction standard called OpenTransact, where we are planning o= n
> > standardizing on RSA in the next revision.
> >
> > Regards
> > Pelle
> >
> >
> > On Mon, Nov 30, 2009 at 2:34 AM, Eran Hammer-Lahav
> <eran@hueniverse.com>= wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Paul C. Bryan [mailto:email@pbryan.net]
> >>> Sent: Sunday, November 29, 2009 3:08 PM
> >>> To: Eran Hammer-Lahav
> >>> Cc: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault
> >>> (lisa.dusseau= lt@gmail.com); OAuth WG (oauth@ietf.o= rg)
> >>> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
> >>>
> >>> To the overall approach, +1.
> >>>
> >>> Some follow-up questions:
> >>>
> >>> 1. Why drop RSA? It seems some form of public key cryptog= raphy will
> >>> be necessary/useful to make web-based-attribute-containin= g tokens
> >>> Internet- scalable.
> >>
> >> Mostly due to lack of implementation experience or interest w= ithin the
> OAuth community. But also because the Plain and MAC versions are based=
> on a simple symmetric shared secret, while PK requires more. This mean= s we
> will need to support different types of tokens. While I am open to thi= s if
> needed, it seems to add a significant complexity. Also, part 2 will th= en need
> to be able to provision both symmetric and asymmetric secrets which ad= ds to
> the complexity there.
> >>
> >> In other words, why put the effort in if no one is asking for= this (based on
> 2 years of deployment experience).
> >>
> >>> 2. Is it an objective to have the Token auth-scheme conta= in
> >>> extension points so that new token formats can be introdu= ced without
> >>> need to redefine the scheme or draft a new one?
> >>
> >> Yes, but see above.
> >>
> >> EHL
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> >
> >
> > --
> > http://agree2.com= - Reach Agreement!
> > http://extrae= agle.com - Solutions for the electronic Extra Legal world
> > http://sta= keventures.com - Bootstrapping blog
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Breno de Me= deiros

--001636c5bfcdb1bc460479b3723d-- From eran@hueniverse.com Tue Dec 1 16:55:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E603A6935 for ; Tue, 1 Dec 2009 16:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWYj4srdJl52 for ; Tue, 1 Dec 2009 16:55:11 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DD3913A6898 for ; Tue, 1 Dec 2009 16:55:10 -0800 (PST) Received: (qmail 25521 invoked from network); 2 Dec 2009 00:55:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 00:55:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 1 Dec 2009 17:55:00 -0700 From: Eran Hammer-Lahav To: Breno Date: Tue, 1 Dec 2009 17:55:08 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 / Charter Thread-Index: Acpy4VH097Nuq9D0QT62ypMAIv8K2QAB597Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209F41@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785209F41P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 00:55:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785209F41P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is an important difference in how 1.0 deals with the two. HMAC secrets are token specific and expire when the token does. With the se= ssion extension you get free HMAC "key" management, but either way, you can= scope the secret to a limited time via the token. Since the secret comes w= ith the token, it is obtained the same way which is well defined. RSA keys are negotiated out of band and are the same for all tokens used by= a single client. There is nothing in the spec on how they should be obtain= ed or cycled. If we add an RSA option to the authentication part, it will mean we will ha= ve to start issuing private keys with each token. If people are happy with = this idea (I have no clue), this can be done in the same way as the HMAC se= cret. I am just not sure if it is a proper way of distributing keys. Anothe= r option would be for the client to provide the server with its public key = when asking for a token (and then a new public key when renewing a token). QUESTION: Are people interested in seeing such an RSA method in the authent= ication spec? Since the new authentication spec exclude the use of client c= redentials (only token with optional secret), any key used for RSA signatur= es will need to be part of the token. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Tuesday, December 01, 2009 3:52 PM To: Eran Hammer-Lahav Cc: Hans Granqvist; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter Eran, The HMAC approach also requires key management. The fact that the community= has punted on it to an out-of-band channel doesn't mean that the problem h= as been addressed. Typical security recommendations for shared keys is that they should be rot= ated more often than public keys. It would be quite reasonable, from a secu= rity perspective, for a provider to want to be specify that HMAC signing ke= ys should be rotated weekly. For instance, the US Government profile for Op= enID requires daily rotation of HMAC signing values. What then? The spec should support key management, with or without PK signing mechanis= ms. On Mon, Nov 30, 2009 at 11:32 AM, Eran Hammer-Lahav > wrote: The issue with RSA-SHA1-like method isn't the signature or crypto. Those ar= e trivial to spec out. The issue is everything else we didn't cover in 1.0 = including key management and rotation, and how to establish it. We had rough consensus about dropping the client credentials (consumer key)= from protected resources requests. This means you may use client credentia= ls to request a token, but once you have the token, you don't need to use t= he client credentials anymore. The implications of this are that any PK-bas= ed method will need to work at the token level, not the client level. With this approach, it will be easy to include a PK method alongside an HMA= C method, but it is not clear how the secret portion of the token pair will= be obtained and managed. My limited understanding suggests that issuing a = token-secret pair isn't the same as a token-Private Key pair. Maybe I'm wro= ng and it can be made as trivial. And no, there will be nothing to prevent such an extension. EHL > -----Original Message----- > From: Hans Granqvist [mailto:hans@granqvist.com] > Sent: Monday, November 30, 2009 9:31 AM > To: OAuth WG (oauth@ietf.org) > Cc: Eran Hammer-Lahav; Pelle Braendgaard > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > > It's tricky. If you allow only MACs, you have to forgo no only RSA (and E= CC...) > but also potentially traditional symmetric key schemes -- their usability > notwithstanding. > > On the other hand, if you try to cover all possible key schemes, it quick= ly > becomes unmanageable. > > Eran, is there a way to define what you want and leave it open for, say a= n > RSA extension, as long as it can be represented as a string, such as > {ALGORITHM}:{STRING}, and where any extra protocol flows are out of this > specification's scope? > > -Hans > > > On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard > > wrote: > > +1 for all minus dropping RSA. > > > > I think the main reason we haven't seen a lot of RSA implementations > > yet has been because the kind of businesses who I think would be > > interested in using this such as banks/payments etc are not > > traditionally early adopters. If we want to see OAUTH used in these > > areas in the future I think it would be a very good idea to leave it > > in. > > > > I am personally working on creating new OAuth based financial > > transaction standard called OpenTransact, where we are planning on > > standardizing on RSA in the next revision. > > > > Regards > > Pelle > > > > > > On Mon, Nov 30, 2009 at 2:34 AM, Eran Hammer-Lahav > > wrote: > >> > >> > >>> -----Original Message----- > >>> From: Paul C. Bryan [mailto:email@pbryan.net= ] > >>> Sent: Sunday, November 29, 2009 3:08 PM > >>> To: Eran Hammer-Lahav > >>> Cc: Peter Saint-Andre (stpeter@stpeter.im)= ; Lisa Dusseault > >>> (lisa.dusseault@gmail.com); OAuth WG= (oauth@ietf.org) > >>> Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter > >>> > >>> To the overall approach, +1. > >>> > >>> Some follow-up questions: > >>> > >>> 1. Why drop RSA? It seems some form of public key cryptography will > >>> be necessary/useful to make web-based-attribute-containing tokens > >>> Internet- scalable. > >> > >> Mostly due to lack of implementation experience or interest within the > OAuth community. But also because the Plain and MAC versions are based > on a simple symmetric shared secret, while PK requires more. This means w= e > will need to support different types of tokens. While I am open to this i= f > needed, it seems to add a significant complexity. Also, part 2 will then = need > to be able to provision both symmetric and asymmetric secrets which adds = to > the complexity there. > >> > >> In other words, why put the effort in if no one is asking for this (ba= sed on > 2 years of deployment experience). > >> > >>> 2. Is it an objective to have the Token auth-scheme contain > >>> extension points so that new token formats can be introduced without > >>> need to redefine the scheme or draft a new one? > >> > >> Yes, but see above. > >> > >> EHL > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > -- > > http://agree2.com - Reach Agreement! > > http://extraeagle.com - Solutions for the electronic Extra Legal world > > http://stakeventures.com - Bootstrapping blog > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E72343785209F41P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is = an important difference in how 1.0 deals with the two.

 

HMAC secrets are token specific and expire when the token does. W= ith the session extension you get free HMAC “key” management, b= ut either way, you can scope the secret to a limited time via the token. Si= nce the secret comes with the token, it is obtained the same way which is w= ell defined.

 

RSA keys are negotiated out of b= and and are the same for all tokens used by a single client. There is nothi= ng in the spec on how they should be obtained or cycled.<= /p>

 

If we add an RSA option to the authentication part, it will mea= n we will have to start issuing private keys with each token. If people are= happy with this idea (I have no clue), this can be done in the same way as= the HMAC secret. I am just not sure if it is a proper way of distributing = keys. Another option would be for the client to provide the server with its= public key when asking for a token (and then a new public key when renewin= g a token).

 

QUESTION: Are people interested i= n seeing such an RSA method in the authentication spec? Since the new authe= ntication spec exclude the use of client credentials (only token with optio= nal secret), any key used for RSA signatures will need to be part of the to= ken.

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Tues= day, December 01, 2009 3:52 PM
To: Eran Hammer-Lahav
Cc: Hans Granqvist; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-W= G] OAuth 2.0 / Charter

 

Eran,

 

The HMA= C approach also requires key management. The fact that the community has pu= nted on it to an out-of-band channel doesn't mean that the problem has been= addressed. 

 =

Typical security recommendations = for shared keys is that they should be rotated more often than public keys.= It would be quite reasonable, from a security perspective, for a provider = to want to be specify that HMAC signing keys should be rotated weekly. For = instance, the US Government profile for OpenID requires daily rotation of H= MAC signing values.

&nbs= p;

What then?

=

 

The spec should support key management, with or without PK signing mech= anisms.

 

=

 

On Mon, Nov 30, 2009 at 11:32 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The issue with RSA-SHA1-like method isn't the signature = or crypto. Those are trivial to spec out. The issue is everything else we d= idn't cover in 1.0 including key management and rotation, and how to establ= ish it.

We had rough consensus about dropping the client credentials= (consumer key) from protected resources requests. This means you may use c= lient credentials to request a token, but once you have the token, you don'= t need to use the client credentials anymore. The implications of this are = that any PK-based method will need to work at the token level, not the clie= nt level.

With this approach, it will be easy to include a PK method= alongside an HMAC method, but it is not clear how the secret portion of th= e token pair will be obtained and managed. My limited understanding suggest= s that issuing a token-secret pair isn't the same as a token-Private Key pa= ir. Maybe I'm wrong and it can be made as trivial.

And no, there wil= l be nothing to prevent such an extension.

EHL


> -----= Original Message-----
> From: Hans Granqvist [mailto:hans@granqvist.com]
> Sent: Monday, Novembe= r 30, 2009 9:31 AM
> To: OAuth WG (= oauth@ietf.org)
> Cc: Eran Hammer-Lahav; Pelle Braendgaard
>= ; Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
>
> It's tricky. = If you allow only MACs, you have to forgo no only RSA (and ECC...)
> = but also potentially traditional symmetric key schemes -- their usability> notwithstanding.
>
> On the other hand, if you try to co= ver all possible key schemes, it quickly
> becomes unmanageable.
&= gt;
> Eran, is there a way to define what you want and leave it open = for, say an
> RSA extension, as long as it can be represented as a st= ring, such as
> {ALGORITHM}:{STRING}, and where any extra protocol fl= ows are out of this
> specification's scope?
>
> -Hans>
>
> On Mon, Nov 30, 2009 at 7:53 AM, Pelle Braendgaard> <pelle@stakeventures.co= m> wrote:
> > +1 for all minus dropping RSA.
> >> > I think the main reason we haven't seen a lot of RSA implementa= tions
> > yet has been because the kind of businesses who I think = would be
> > interested in using this such as banks/payments etc a= re not
> > traditionally early adopters. If we want to see OAUTH u= sed in these
> > areas in the future I think it would be a very go= od idea to leave it
> > in.
> >
> > I am persona= lly working on creating new OAuth based financial
> > transaction = standard called OpenTransact, where we are planning on
> > standar= dizing on RSA in the next revision.
> >
> > Regards
&g= t; > Pelle
> >
> >
> > On Mon, Nov 30, 2009 a= t 2:34 AM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
> >>
> >>> >>> -----Original Message-----
> >>> From: P= aul C. Bryan [mailto:email@pbryan.net]
> >>> Sent: Sunday, November 29, 2009 3:08 PM
> &g= t;>> To: Eran Hammer-Lahav
> >>> Cc: Peter Saint-Andre= (stpeter@stpeter.im); Lisa Dusse= ault
> >>> (lisa= .dusseault@gmail.com); OAuth WG (oaut= h@ietf.org)
> >>> Subject: Re: [OAUTH-WG] OAuth 2.0 / Ch= arter
> >>>
> >>> To the overall approach, +1= .
> >>>
> >>> Some follow-up questions:
&g= t; >>>
> >>> 1. Why drop RSA? It seems some form of= public key cryptography will
> >>> be necessary/useful to m= ake web-based-attribute-containing tokens
> >>> Internet- sc= alable.
> >>
> >> Mostly due to lack of implementat= ion experience or interest within the
> OAuth community. But also bec= ause the Plain and MAC versions are based
> on a simple symmetric sha= red secret, while PK requires more. This means we
> will need to supp= ort different types of tokens. While I am open to this if
> needed, i= t seems to add a significant complexity. Also, part 2 will then need
>= ; to be able to provision both symmetric and asymmetric secrets which adds = to
> the complexity there.
> >>
> >> In other= words, why put the effort in if no one is asking for this (based on
>= ; 2 years of deployment experience).
> >>
> >>> = 2. Is it an objective to have the Token auth-scheme contain
> >>= ;> extension points so that new token formats can be introduced without<= br>> >>> need to redefine the scheme or draft a new one?
>= ; >>
> >> Yes, but see above.
> >>
> &g= t;> EHL
> >> _______________________________________________=
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailma= n/listinfo/oauth
> >>
> >
> >
> >= ;
> > --
> > http://agree2.com - Reach Agreement!
> > http://extraeagle.com - Solutions fo= r the electronic Extra Legal world
> > http://stakeventures.com - Bootstrapping bl= og
> > _______________________________________________
> >= ; OAuth mailing list
> > OAuth@i= etf.org
> > https://www.ietf.org/mailman/listinfo/oauth
= > >
_______________________________________________
OAuth maili= ng list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth




--=
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785209F41P3PW5EX1MB01E_-- From faynberg@alcatel-lucent.com Tue Dec 1 17:18:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4DC3A680B for ; Tue, 1 Dec 2009 17:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUQx-BpADK-Q for ; Tue, 1 Dec 2009 17:18:33 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 8F4F53A685E for ; Tue, 1 Dec 2009 17:18:33 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nB21IHHl010784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 19:18:17 -0600 (CST) Received: from [135.244.19.125] (faynberg.lra.lucent.com [135.244.19.125]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nB21IH4O016169; Tue, 1 Dec 2009 19:18:17 -0600 (CST) Message-ID: <4B15C057.3040301@alcatel-lucent.com> Date: Tue, 01 Dec 2009 20:18:15 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Eaton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] delegation, authentication, public key, hmac, and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 01:18:34 -0000 Reasonable?.. As far as I am concerned, it is *perfect! *Igor Brian Eaton wrote: > I'm going to try to summarize some conversations that happened in > other threads on these topics. Our story so far: > > A significant number of people don't think any crypto is necessary for > most use cases. Some folks want HMAC to protect token secrets over > HTTP. [1]. > > Several people believe public key cryptography is necessary for > bootstrapping authentication. [2]. > > A few people have expressed a preference for public key signing of > individual data access requests. [1] and [2]. > > Everybody is in favor of a model that allows new signature algorithms > to be added in the future. [3]. > > No one appears to be arguing strongly that data access requests (as > opposed to the initial authentication/authorization) need to be signed > *both* with public key and HMAC. > > To meet these requirements, I think we should > > 1) Agree on a signature base string, something sort of like the > signature base string in OAuth 1.0a. [4] > 2) Agree on a system for naming signature algorithms. > 3) Agree on profiles for combining bearer tokens/redirects/signed > tokens into reusable profiles to address different use cases. > > I'd fully expect people to mix-and-match and come up with new profiles > that trade-off security, complexity, and latency in ways that address > their individual use cases. My hope would be that they could reuse as > much of the signature base string and the signature algorithms as > possible. > > Sound reasonable? > ... From faynberg@alcatel-lucent.com Tue Dec 1 17:36:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEC33A6926 for ; Tue, 1 Dec 2009 17:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn6V4Q+TchIs for ; Tue, 1 Dec 2009 17:36:11 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C6EFE3A68F2 for ; Tue, 1 Dec 2009 17:36:11 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nB21a0wd023501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Dec 2009 19:36:00 -0600 (CST) Received: from [135.244.19.125] (faynberg.lra.lucent.com [135.244.19.125]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nB21Zxlx025631; Tue, 1 Dec 2009 19:35:59 -0600 (CST) Message-ID: <4B15C47C.30202@alcatel-lucent.com> Date: Tue, 01 Dec 2009 20:35:56 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F41@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F41@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 01:36:12 -0000 Eran Hammer-Lahav wrote: ... > > > > RSA keys are negotiated out of band and are the same for all tokens > used by a single client. There is nothing in the spec on how they > should be obtained or cycled. > This is right, but this is because a public key is NOT subject to negotiation. It is confirmed by a certificate. > > > > If we add an RSA option to the authentication part, it will mean we > will have to start issuing private keys with each token. If people are > happy with this idea (I have no clue), this can be done in the same > way as the HMAC secret. I am just not sure if it is a proper way of > distributing keys. Another option would be for the client to provide > the server with its public key when asking for a token (and then a new > public key when renewing a token). > I would never be happy with THIS idea. For one thing, if a private key is escrowed it may NOT be used in signatures. This is why, to begin with, I assumed that some sort of PKI ought to be in place. > > > > ..., any key used for RSA signatures will need to be part of the token. > It is likely that I misunderstood this statement. But if I take it literally, the answer is no. The key should not be (and cannot be) part of the token. The private key is useless for HMAC because it is not available to anyone and thus no one can verify the signature. Perhaps you meant that the certificate (or a certificate chain) needs to be present? This, actually, may very well be a possibility. Igor > > > From jpanzer@google.com Tue Dec 1 17:54:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3ABE3A68F2 for ; Tue, 1 Dec 2009 17:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.936 X-Spam-Level: X-Spam-Status: No, score=-105.936 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGnkm2Y2N-on for ; Tue, 1 Dec 2009 17:54:26 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 423E83A679F for ; Tue, 1 Dec 2009 17:54:26 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id nB21sGxm023823 for ; Wed, 2 Dec 2009 01:54:17 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259718857; bh=GXJbDIRqi9GzTVopAEahVnABeeQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=g9WdY7Tl3fw5vhUAFuoDiO8z17Lri571poHzJL+c1IYGrBYQMZtpxoTeK+wjovNaO D34Oi5EAcNTaJjH7ceivQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=DSgfx9AfU5Prt6VKzdON5dPYy857VCl/1NeMzCUyBXzfPVtk2XSAFjR471O1mBmHv 4L8GokijZTUi46Pa/y7CQ== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by wpaz13.hot.corp.google.com with ESMTP id nB21sDk0027634 for ; Tue, 1 Dec 2009 17:54:14 -0800 Received: by pwj9 with SMTP id 9so3096545pwj.11 for ; Tue, 01 Dec 2009 17:54:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.187.3 with SMTP id k3mr12694973waf.82.1259718853455; Tue, 01 Dec 2009 17:54:13 -0800 (PST) In-Reply-To: References: From: John Panzer Date: Tue, 1 Dec 2009 17:53:53 -0800 Message-ID: To: Brian Eaton Content-Type: multipart/alternative; boundary=0016e64cca0cc6ee280479b52610 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] delegation, authentication, public key, hmac, and bearer tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 01:54:27 -0000 --0016e64cca0cc6ee280479b52610 Content-Type: text/plain; charset=ISO-8859-1 +1 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Tue, Dec 1, 2009 at 9:52 AM, Brian Eaton wrote: > I'm going to try to summarize some conversations that happened in > other threads on these topics. Our story so far: > > A significant number of people don't think any crypto is necessary for > most use cases. Some folks want HMAC to protect token secrets over > HTTP. [1]. > > Several people believe public key cryptography is necessary for > bootstrapping authentication. [2]. > > A few people have expressed a preference for public key signing of > individual data access requests. [1] and [2]. > > Everybody is in favor of a model that allows new signature algorithms > to be added in the future. [3]. > > No one appears to be arguing strongly that data access requests (as > opposed to the initial authentication/authorization) need to be signed > *both* with public key and HMAC. > > To meet these requirements, I think we should > > 1) Agree on a signature base string, something sort of like the > signature base string in OAuth 1.0a. [4] > 2) Agree on a system for naming signature algorithms. > 3) Agree on profiles for combining bearer tokens/redirects/signed > tokens into reusable profiles to address different use cases. > > I'd fully expect people to mix-and-match and come up with new profiles > that trade-off security, complexity, and latency in ways that address > their individual use cases. My hope would be that they could reuse as > much of the signature base string and the signature algorithms as > possible. > > Sound reasonable? > > Cheers, > Brian > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00506.html > [2] http://www.ietf.org/mail-archive/web/oauth/current/msg00630.html > [3] http://www.ietf.org/mail-archive/web/oauth/current/msg00585.html > [4] http://oauth.net/core/1.0a#anchor13 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64cca0cc6ee280479b52610 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Tue, Dec 1, 2009 at 9:52 AM, Brian Ea= ton <beaton@googl= e.com> wrote:
I'm going to try to summarize some conversations that happened in
other threads on these topics. =A0Our story so far:

A significant number of people don't think any crypto is necessary for<= br> most use cases. =A0 Some folks want HMAC to protect token secrets over
HTTP. =A0[1].

Several people believe public key cryptography is necessary for
bootstrapping authentication. [2].

A few people have expressed a preference for public key signing of
individual data access requests. [1] and [2].

Everybody is in favor of a model that allows new signature algorithms
to be added in the future. [3].

No one appears to be arguing strongly that data access requests (as
opposed to the initial authentication/authorization) need to be signed
*both* with public key and HMAC.

To meet these requirements, I think we should

1) Agree on a signature base string, something sort of like the
signature base string in OAuth 1.0a. [4]
2) Agree on a system for naming signature algorithms.
3) Agree on profiles for combining bearer tokens/redirects/signed
tokens into reusable profiles to address different use cases.

I'd fully expect people to mix-and-match and come up with new profiles<= br> that trade-off security, complexity, and latency in ways that address
their individual use cases. =A0My hope would be that they could reuse as much of the signature base string and the signature algorithms as
possible.

Sound reasonable?

Cheers,
Brian

[1] http://www.ietf.org/mail-archive/web/oauth/current/= msg00506.html
[2] http://www.ietf.org/mail-archive/web/oauth/current/= msg00630.html
[3] http://www.ietf.org/mail-archive/web/oauth/current/= msg00585.html
[4] http:= //oauth.net/core/1.0a#anchor13
_________________________________________= ______
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e64cca0cc6ee280479b52610-- From idan@pixane.com Tue Dec 1 16:21:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F118E28C13D for ; Tue, 1 Dec 2009 16:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJtB9KQVDBx3 for ; Tue, 1 Dec 2009 16:21:36 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 92C6828C138 for ; Tue, 1 Dec 2009 16:21:36 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so1273228eyf.51 for ; Tue, 01 Dec 2009 16:21:23 -0800 (PST) Received: by 10.216.87.194 with SMTP id y44mr2250881wee.204.1259713282675; Tue, 01 Dec 2009 16:21:22 -0800 (PST) Received: from ?10.0.0.5? (93-173-158-244.bb.netvision.net.il [93.173.158.244]) by mx.google.com with ESMTPS id i35sm1287612gve.11.2009.12.01.16.21.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Dec 2009 16:21:21 -0800 (PST) Message-Id: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> From: Idan Gazit To: oauth@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Dec 2009 02:21:19 +0200 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 01 Dec 2009 18:35:42 -0800 Subject: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 00:23:55 -0000 Hey folks, I redrew/updated an old diagram (http://documentation.fring.com/images/1/11/Oauth_diagram.png ) outlining the OAuth authentication flow. The old one didn't reflect the changes in 1.0a. The updated diagrams are here: http://s3.pixane.com/Oauth_diagram.png http://s3.pixane.com/Oauth_diagram.pdf Please feel free to use them, I hereby place them in the public domain. I was pointed in their direction by Mike Malone, after having looked for exactly such a thing (for quite a while). He mentioned that the reason it was chucked from the documentation is that it doesn't reflect the changes made in the wake of the session fixation attack. I took the old diagram, took the spec, and updated as required, with some minor changes for legibility and aesthetics. Speaking as somebody who has tried (and failed) to digest OAuth by means of the long and detailed spec, this sort of diagram is extremely helpful in getting the "big picture" across. I'm not knocking the need for a good spec, but a one-page overview that pulls it all together without going into too much detail is sorely missing from the docs. This diagram goes a long way towards meeting that need. Just my $0.02! Thanks for authoring this standard, hope this is useful! -Idan From eran@hueniverse.com Tue Dec 1 18:42:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4283A6880 for ; Tue, 1 Dec 2009 18:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sdi+-lptYkap for ; Tue, 1 Dec 2009 18:42:50 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 11C643A6813 for ; Tue, 1 Dec 2009 18:42:50 -0800 (PST) Received: (qmail 29393 invoked from network); 2 Dec 2009 02:42:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 02:42:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 1 Dec 2009 19:42:41 -0700 From: Eran Hammer-Lahav To: "faynberg@alcatel-lucent.com" Date: Tue, 1 Dec 2009 19:42:50 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 / Charter Thread-Index: Acpy78/BI5nSbXMwRQOdks8z6Or4XgAB0xuQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B8C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F41@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15C47C.30202@alcatel-lucent.com> In-Reply-To: <4B15C47C.30202@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 02:42:50 -0000 > -----Original Message----- > From: Igor Faynberg [mailto:faynberg@alcatel-lucent.com] > Sent: Tuesday, December 01, 2009 5:36 PM > > If we add an RSA option to the authentication part, it will mean we > > will have to start issuing private keys with each token. If people are > > happy with this idea (I have no clue), this can be done in the same > > way as the HMAC secret. I am just not sure if it is a proper way of > > distributing keys. Another option would be for the client to provide > > the server with its public key when asking for a token (and then a new > > public key when renewing a token). > > I would never be happy with THIS idea. For one thing, if a private key = is > escrowed it may NOT be used in signatures. This is why, to begin with, I > assumed that some sort of PKI ought to be in place. Which is why I added the flip side as an idea. When the client requests a token, it provides the public key to the server = for verifying it is the rightful owner of the token (once issued). The serv= er then issues a token without any secrets and uses the public key provided= by the client to authenticate token requests. What kind of PKI? The current RSA-SHA1 method uses a simple private/public = key pair without any dependency on other infrastructure. > > > > > > ..., any key used for RSA signatures will need to be part of the token. > > >=20 > It is likely that I misunderstood this statement. But if I take it litera= lly, the > answer is no. The key should not be (and cannot be) part of the token. Th= e > private key is useless for HMAC because it is not available to anyone and= thus > no one can verify the signature. Perhaps you meant that the certificate (= or a > certificate chain) needs to be present? This, actually, may very well be = a > possibility. It means part of the 'set of token credentials', not part of the token itse= lf. That would never work. =20 EHL From eran@hueniverse.com Tue Dec 1 18:43:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E213A6813 for ; Tue, 1 Dec 2009 18:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTMkUZw2zaGv for ; Tue, 1 Dec 2009 18:43:48 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B576A3A679F for ; Tue, 1 Dec 2009 18:43:48 -0800 (PST) Received: (qmail 968 invoked from network); 2 Dec 2009 02:43:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 02:43:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 1 Dec 2009 19:43:37 -0700 From: Eran Hammer-Lahav To: Idan Gazit , "oauth@ietf.org" Date: Tue, 1 Dec 2009 19:43:45 -0700 Thread-Topic: [OAUTH-WG] OAuth 1.0a flow diagram Thread-Index: Acpy+CMaLo/POltwRUORf2vQXJZOkgAARgiw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209F70@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> In-Reply-To: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 02:43:49 -0000 Which version of the 'long and detailed' spec? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Idan Gazit > Sent: Tuesday, December 01, 2009 4:21 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] OAuth 1.0a flow diagram >=20 > Hey folks, >=20 > I redrew/updated an old diagram > (http://documentation.fring.com/images/1/11/Oauth_diagram.png > ) outlining the OAuth authentication flow. The old one didn't reflect the > changes in 1.0a. >=20 > The updated diagrams are here: >=20 > http://s3.pixane.com/Oauth_diagram.png > http://s3.pixane.com/Oauth_diagram.pdf >=20 > Please feel free to use them, I hereby place them in the public domain. >=20 > I was pointed in their direction by Mike Malone, after having looked for > exactly such a thing (for quite a while). He mentioned that the reason it= was > chucked from the documentation is that it doesn't reflect the changes mad= e > in the wake of the session fixation attack. I took the old diagram, took = the > spec, and updated as required, with some minor changes for legibility and > aesthetics. >=20 > Speaking as somebody who has tried (and failed) to digest OAuth by means > of the long and detailed spec, this sort of diagram is extremely helpful = in > getting the "big picture" across. I'm not knocking the need for a good sp= ec, > but a one-page overview that pulls it all together without going into too > much detail is sorely missing from the docs. > This diagram goes a long way towards meeting that need. >=20 > Just my $0.02! Thanks for authoring this standard, hope this is useful! >=20 > -Idan > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Tue Dec 1 18:58:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B19B3A67C0 for ; Tue, 1 Dec 2009 18:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEz6R3Nuralp for ; Tue, 1 Dec 2009 18:58:20 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2C3A53A6405 for ; Tue, 1 Dec 2009 18:58:20 -0800 (PST) Received: from squire.local (dsl-205-34.dynamic-dsl.frii.net [216.17.205.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BA21840D16; Tue, 1 Dec 2009 19:58:11 -0700 (MST) Message-ID: <4B15D7C2.2070901@stpeter.im> Date: Tue, 01 Dec 2009 19:58:10 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net><4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de><90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000904020101050902040104" Cc: ext Dick Hardt , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 02:58:21 -0000 This is a cryptographically signed message in MIME format. --------------ms000904020101050902040104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/30/09 1:27 PM, Eran Hammer-Lahav wrote: > OAuth is being proposed as a generally useful method for securing API > calls. I expect many open source libraries to implement it on the > server side and use it for blog plugins, widgets, and other highly > distributed software. If OAuth required the use of TLS, it would > simply be ignored by all those applications which will likely > continue using Basic. > > With all due respect to big companies, their resources, and ability > to effortlessly deploy SSL/TLS, it is still an expensive and complex > process for more developers deploying small scale server components. With all due respect, I think it can be harder for big companies to deploy TLS -- they have a lot more users, need more hardware (special SSL accelerators and the like), have more layers of employees (so it can be more difficult to find the person who controls the hostmaster or whois-listed email address), etc. Getting a Class 1 cert from the likes of StartSSL is easy as pie these days. IMHO there is no excuse for not deploying SSL if you care one whit about security. The problem is that too many small-scale developers (and big companies!) simply don't care. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms000904020101050902040104 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMjAyNTgxMFowIwYJKoZIhvcNAQkEMRYEFF2RvWVNGm1smifb+Va1 BdAEf6xsMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAA9UhCNnxUeTJtGaAPeAQMM3GxWWNRP8BMeBhtrAz tO/mul+JV3f66mUC58odllhZYOUNa/ZLwOAOS/shS93tngpezxsDSpFhRyRDZPqiUq8EkOcY +Udbqr67vv1fV0IhTkYSoRdCjgjFsvesulBe8rIKNhzdctbeP8h/9no08raC5tO1BATInyrA JSnsI97t9SvdM7E4Xe6b4ebO8lEJ0dn7Z92vB061kUjQ/jiKukrjUUaprnWcDya9laJ7zDq6 rP+Fy8lAzjU1WIbjjbi/xHYCcDYgmUDFrrfPqZQlqkQ0gtSLoFSDa4QANciopxCWbbudZ0by 1ziNAx0a8i5xGQAAAAAAAA== --------------ms000904020101050902040104-- From eran@hueniverse.com Tue Dec 1 19:08:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006FE3A67AE for ; Tue, 1 Dec 2009 19:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XR26OW5k352 for ; Tue, 1 Dec 2009 19:08:49 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EF3F03A6781 for ; Tue, 1 Dec 2009 19:08:48 -0800 (PST) Received: (qmail 5777 invoked from network); 2 Dec 2009 03:08:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 03:08:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 1 Dec 2009 20:08:37 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre Date: Tue, 1 Dec 2009 20:08:45 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: Acpy+0tDO98Ic0wOQMyVtts1JRKRjwAANzGQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net><4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de><90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> In-Reply-To: <4B15D7C2.2070901@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Dick Hardt , ext, "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 03:08:50 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGV0ZXIgU2FpbnQtQW5k cmUgW21haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVy IDAxLCAyMDA5IDY6NTggUE0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2DQo+IENjOiBUc2Nob2Zl bmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKTsgZXh0IERpY2sgSGFyZHQ7IG9hdXRoQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHdoeSBhcmUgd2Ugc2lnbmluZz8NCj4gDQo+ IDxoYXQgdHlwZT0naW5kaXZpZHVhbCcvPg0KPiANCj4gT24gMTEvMzAvMDkgMToyNyBQTSwgRXJh biBIYW1tZXItTGFoYXYgd3JvdGU6DQo+ID4gT0F1dGggaXMgYmVpbmcgcHJvcG9zZWQgYXMgYSBn ZW5lcmFsbHkgdXNlZnVsIG1ldGhvZCBmb3Igc2VjdXJpbmcgQVBJDQo+ID4gY2FsbHMuIEkgZXhw ZWN0IG1hbnkgb3BlbiBzb3VyY2UgbGlicmFyaWVzIHRvIGltcGxlbWVudCBpdCBvbiB0aGUNCj4g PiBzZXJ2ZXIgc2lkZSBhbmQgdXNlIGl0IGZvciBibG9nIHBsdWdpbnMsIHdpZGdldHMsIGFuZCBv dGhlciBoaWdobHkNCj4gPiBkaXN0cmlidXRlZCBzb2Z0d2FyZS4gSWYgT0F1dGggcmVxdWlyZWQg dGhlIHVzZSBvZiBUTFMsIGl0IHdvdWxkDQo+ID4gc2ltcGx5IGJlIGlnbm9yZWQgYnkgYWxsIHRo b3NlIGFwcGxpY2F0aW9ucyB3aGljaCB3aWxsIGxpa2VseQ0KPiA+IGNvbnRpbnVlIHVzaW5nIEJh c2ljLg0KPiA+DQo+ID4gV2l0aCBhbGwgZHVlIHJlc3BlY3QgdG8gYmlnIGNvbXBhbmllcywgdGhl aXIgcmVzb3VyY2VzLCBhbmQgYWJpbGl0eQ0KPiA+IHRvIGVmZm9ydGxlc3NseSBkZXBsb3kgU1NM L1RMUywgaXQgaXMgc3RpbGwgYW4gZXhwZW5zaXZlIGFuZCBjb21wbGV4DQo+ID4gcHJvY2VzcyBm b3IgbW9yZSBkZXZlbG9wZXJzIGRlcGxveWluZyBzbWFsbCBzY2FsZSBzZXJ2ZXIgY29tcG9uZW50 cy4NCj4gDQo+IFdpdGggYWxsIGR1ZSByZXNwZWN0LCBJIHRoaW5rIGl0IGNhbiBiZSBoYXJkZXIg Zm9yIGJpZyBjb21wYW5pZXMgdG8NCj4gZGVwbG95IFRMUyAtLSB0aGV5IGhhdmUgYSBsb3QgbW9y ZSB1c2VycywgbmVlZCBtb3JlIGhhcmR3YXJlIChzcGVjaWFsDQo+IFNTTCBhY2NlbGVyYXRvcnMg YW5kIHRoZSBsaWtlKSwgaGF2ZSBtb3JlIGxheWVycyBvZiBlbXBsb3llZXMgKHNvIGl0IGNhbg0K PiBiZSBtb3JlIGRpZmZpY3VsdCB0byBmaW5kIHRoZSBwZXJzb24gd2hvIGNvbnRyb2xzIHRoZSBo b3N0bWFzdGVyIG9yDQo+IHdob2lzLWxpc3RlZCBlbWFpbCBhZGRyZXNzKSwgZXRjLg0KDQpFaXRo ZXIgd2F5IHlvdSBhcmUgbWFraW5nIG15IHBvaW50LCBzb3J0YS4NCg0KPiBHZXR0aW5nIGEgQ2xh c3MgMSBjZXJ0IGZyb20gdGhlIGxpa2VzIG9mIFN0YXJ0U1NMIGlzIGVhc3kgYXMgcGllIHRoZXNl DQo+IGRheXMuIElNSE8gdGhlcmUgaXMgbm8gZXhjdXNlIGZvciBub3QgZGVwbG95aW5nIFNTTCBp ZiB5b3UgY2FyZSBvbmUgd2hpdA0KPiBhYm91dCBzZWN1cml0eS4gVGhlIHByb2JsZW0gaXMgdGhh dCB0b28gbWFueSBzbWFsbC1zY2FsZSBkZXZlbG9wZXJzIChhbmQNCj4gYmlnIGNvbXBhbmllcyEp IHNpbXBseSBkb24ndCBjYXJlLg0KDQpEb24ndCBjYXJlLCBkb24ndCBuZWVkIHRoYXQgbXVjaCBz ZWN1cml0eSwgZG9uJ3QgdW5kZXJzdGFuZCBpdCwgZXRjLiBCb3R0b20gbGluZSBpcyB0aGF0IHJl cXVpcmluZyBTU0wgaXMgY2VydGFpbiB0byBmb3JrIHRoaXMgd29yayBpZiBub3QgZG9uZSByaWdo dC4NCg0KQW5kIEJUVywgSSB3YXMgdGhlIG9uZSBhcmd1aW5nIGZvciBtYW5kYXRpbmcgU1NMIGlu IDEuMCB3aGVuIG9idGFpbmluZyB0b2tlbnMuIEkgbG9zdC4NCg0KRUhMDQoNCj4gUGV0ZXINCj4g DQo+IC0tDQo+IFBldGVyIFNhaW50LUFuZHJlDQo+IGh0dHBzOi8vc3RwZXRlci5pbS8NCj4gDQoN Cg== From stpeter@stpeter.im Tue Dec 1 19:12:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C870C3A67AE for ; Tue, 1 Dec 2009 19:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BtNIJRJrZlZ for ; Tue, 1 Dec 2009 19:12:06 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 335D83A682F for ; Tue, 1 Dec 2009 19:12:04 -0800 (PST) Received: from squire.local (dsl-205-34.dynamic-dsl.frii.net [216.17.205.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EACD740D16; Tue, 1 Dec 2009 20:11:55 -0700 (MST) Message-ID: <4B15DAFA.1020404@stpeter.im> Date: Tue, 01 Dec 2009 20:11:54 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <35D50F5C-3982-4298-A9E0-86A528F5C5D3@jkemp.net><4A956CE47D1066408D5C7EB34368A5110551FFC1@S4DE8PSAAQC.mitte.t-com.de><90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000501040406050304030608" Cc: ext Dick Hardt , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 03:12:14 -0000 This is a cryptographically signed message in MIME format. --------------ms000501040406050304030608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/1/09 8:08 PM, Eran Hammer-Lahav wrote: > >> -----Original Message----- From: Peter Saint-Andre >> [mailto:stpeter@stpeter.im] Sent: Tuesday, December 01, 2009 6:58 >> PM To: Eran Hammer-Lahav Cc: Tschofenig, Hannes (NSN - FI/Espoo); >> ext Dick Hardt; oauth@ietf.org Subject: Re: [OAUTH-WG] why are we >> signing? >> >> >> >> On 11/30/09 1:27 PM, Eran Hammer-Lahav wrote: >>> OAuth is being proposed as a generally useful method for securing >>> API calls. I expect many open source libraries to implement it on >>> the server side and use it for blog plugins, widgets, and other >>> highly distributed software. If OAuth required the use of TLS, it >>> would simply be ignored by all those applications which will >>> likely continue using Basic. >>> >>> With all due respect to big companies, their resources, and >>> ability to effortlessly deploy SSL/TLS, it is still an expensive >>> and complex process for more developers deploying small scale >>> server components. >> With all due respect, I think it can be harder for big companies to >> deploy TLS -- they have a lot more users, need more hardware >> (special SSL accelerators and the like), have more layers of >> employees (so it can be more difficult to find the person who >> controls the hostmaster or whois-listed email address), etc. > > Either way you are making my point, sorta. > >> Getting a Class 1 cert from the likes of StartSSL is easy as pie >> these days. IMHO there is no excuse for not deploying SSL if you >> care one whit about security. The problem is that too many >> small-scale developers (and big companies!) simply don't care. > > Don't care, don't need that much security, don't understand it, etc. > Bottom line is that requiring SSL is certain to fork this work if not > done right. o/~ don't know much about security... o/~ > And BTW, I was the one arguing for mandating SSL in 1.0 when > obtaining tokens. I lost. Right, because people are lazy. In any case, if the big companies take the lead and require encrypted connections, then everyone else will follow. This is more of a cultural issue than a technical issue. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms000501040406050304030608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMjAzMTE1NFowIwYJKoZIhvcNAQkEMRYEFH1tuLw1A0NhK+U9pe61 OJ+JKLf2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEATM0v18OHreZr1Q9/kKzMV+owAyc4xsAAvNGR0krZ ikUvZltAA/8mJyEscVvzc2wq/vrz82cr2LJjxDWNwrHGYksdgFBFDfTy2sUxlvpdWbzMBCo8 leUPNcufiHPfkh2jJfu7iqbfRw+h1EKFjyEE1QLjhAIwUz0znf36qlR4vTpy5BI6mwDESFCb YqLwsLJ1QdwIway6JhIZh1m5jcGxtea0dpo04rl/QSnWVWe6xs64P6ogM+VssnU1wVtKXvtf rFZ98TJP1vHkYRDc4qZQTl1cI/hWm1AJHpifK/v3EikmiEz+Ywj5QS3exNty5pTN/TFysX3s MoOVOaZtcTJwrAAAAAAAAA== --------------ms000501040406050304030608-- From beaton@google.com Tue Dec 1 19:46:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B9983A67AE for ; Tue, 1 Dec 2009 19:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdEhCtlmYHCZ for ; Tue, 1 Dec 2009 19:46:52 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 30DBD3A6774 for ; Tue, 1 Dec 2009 19:46:52 -0800 (PST) Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id nB23keG0024496 for ; Wed, 2 Dec 2009 03:46:41 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259725602; bh=2hQNrcrSW9Cig0ycPIl2KvkntNk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=UfxaQcfaifKrhJFfV7Ei5Q4T1EM/PLZQAqR7Gq+STV7XCJFrfhE9a7r4FEMKAnfcf 6YlsnfXEVmFBRZMd3DIEQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Kbz0lKU3WiuawUmiqxMV0AQTsqGcbijZGxLGANTitT2dCRJ+R7W04pXTdnnqrFa1R geQTdK4MMJnKYAkJGrmVg== Received: from pzk10 (pzk10.prod.google.com [10.243.19.138]) by spaceape9.eur.corp.google.com with ESMTP id nB23kQKE030731 for ; Tue, 1 Dec 2009 19:46:38 -0800 Received: by pzk10 with SMTP id 10so4125126pzk.19 for ; Tue, 01 Dec 2009 19:46:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.42.3 with SMTP id u3mr455787rvj.107.1259725597783; Tue, 01 Dec 2009 19:46:37 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 1 Dec 2009 19:46:37 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Dick Hardt , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" , ext@core3.amsl.com Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 03:46:53 -0000 On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav wrote: >> Getting a Class 1 cert from the likes of StartSSL is easy as pie these >> days. IMHO there is no excuse for not deploying SSL if you care one whit >> about security. The problem is that too many small-scale developers (and >> big companies!) simply don't care. > > Don't care, don't need that much security, don't understand it, etc. Bottom line is that requiring SSL is certain to fork this work if not done right. Note, however, that someone who can't get SSL working and still deploys OAuth has basically no security against eavesdroppers or MITM attacks, and certainly can't expect OAuth to provide it. The issues are in the token issuance phase: these organizations are sending user passwords and session cookies in clear text! OAuth is the least of their security concerns, (Wearing my security geek hat, I think it's pretty reasonable for some people to refuse to deploy SSL. It's a business choice. Security is about managing risk, and in some cases the cost of getting SSL working just isn't worth it. And I'm completely fine with those folks deploying OAuth without SSL as well. There's no sense in putting a bullet proof door on a house made of straw.) Cheers, Brian From Dick.Hardt@microsoft.com Tue Dec 1 21:51:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08DF28C13D for ; Tue, 1 Dec 2009 21:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.51 X-Spam-Level: X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx2Kn7xbN0qZ for ; Tue, 1 Dec 2009 21:51:24 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 2000628C133 for ; Tue, 1 Dec 2009 21:51:24 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 1 Dec 2009 21:51:42 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi; Tue, 1 Dec 2009 21:51:15 -0800 From: Dick Hardt To: Brian Eaton Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5EuVfSAgAED2ACAAt81AIAAASmAgABrE4CAAH1JAIABBIUAgACcJwCAAAx/gIAa2A2A//97K4CAAA8m8IACiKgAgAAC9YCAAAqUgIAAItEA Date: Wed, 2 Dec 2009 05:51:14 +0000 Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <7b35e839-f7c6-4d5d-a4fd-c9ff81679008> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 05:51:24 -0000 On 2009-12-01, at 5:46 PM, Brian Eaton wrote: > On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav w= rote: >>> Getting a Class 1 cert from the likes of StartSSL is easy as pie these >>> days. IMHO there is no excuse for not deploying SSL if you care one whi= t >>> about security. The problem is that too many small-scale developers (an= d >>> big companies!) simply don't care. >>=20 >> Don't care, don't need that much security, don't understand it, etc. Bot= tom line is that requiring SSL is certain to fork this work if not done rig= ht. >=20 > Note, however, that someone who can't get SSL working and still > deploys OAuth has basically no security against eavesdroppers or MITM > attacks, and certainly can't expect OAuth to provide it. The issues > are in the token issuance phase: these organizations are sending user > passwords and session cookies in clear text! OAuth is the least of > their security concerns, If the cost of SSL outweighs the risk of a security breach, then why would = a developer deploying OAuth choose to sign their messages rather then use t= he simpler bearer token? Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think th= at is a good question. Perhaps it should be RECOMMENDED, and deployments ca= n make their own benefit analysis. -- Dick= From eran@hueniverse.com Tue Dec 1 22:04:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9189A3A6825 for ; Tue, 1 Dec 2009 22:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo-GTH9VrCxP for ; Tue, 1 Dec 2009 22:04:23 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8CBB33A67F5 for ; Tue, 1 Dec 2009 22:04:23 -0800 (PST) Received: (qmail 2008 invoked from network); 2 Dec 2009 06:04:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 06:04:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 1 Dec 2009 23:04:15 -0700 From: Eran Hammer-Lahav To: Dick Hardt , Brian Eaton Date: Tue, 1 Dec 2009 23:04:23 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5EuVfSAgAED2ACAAt81AIAAASmAgABrE4CAAH1JAIABBIUAgACcJwCAAAx/gIAa2A2A//97K4CAAA8m8IACiKgAgAAC9YCAAAqUgIAAItEA//9802A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 06:04:24 -0000 I would like to make an official request to the chair for a consensus call = on recommending SSL but keeping it optional in the various OAuth components= . We can figure out how strong to make the language (or how scary), and we = may make it mandatory in some flows/profiles, but I would like to be done w= ith this discussion (for the n time). If someone will want to raise new arguments, well, this is the IETF so who = can stop them? :-) EHL > -----Original Message----- > From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] > Sent: Tuesday, December 01, 2009 9:51 PM > To: Brian Eaton > Cc: Eran Hammer-Lahav; Peter Saint-Andre; ; > Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org > Subject: Re: [OAUTH-WG] why are we signing? >=20 >=20 > On 2009-12-01, at 5:46 PM, Brian Eaton wrote: >=20 > > On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav > wrote: > >>> Getting a Class 1 cert from the likes of StartSSL is easy as pie > >>> these days. IMHO there is no excuse for not deploying SSL if you > >>> care one whit about security. The problem is that too many > >>> small-scale developers (and big companies!) simply don't care. > >> > >> Don't care, don't need that much security, don't understand it, etc. > Bottom line is that requiring SSL is certain to fork this work if not don= e right. > > > > Note, however, that someone who can't get SSL working and still > > deploys OAuth has basically no security against eavesdroppers or MITM > > attacks, and certainly can't expect OAuth to provide it. The issues > > are in the token issuance phase: these organizations are sending user > > passwords and session cookies in clear text! OAuth is the least of > > their security concerns, >=20 >=20 > If the cost of SSL outweighs the risk of a security breach, then why woul= d a > developer deploying OAuth choose to sign their messages rather then use > the simpler bearer token? >=20 > Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think > that is a good question. Perhaps it should be RECOMMENDED, and > deployments can make their own benefit analysis. >=20 > -- Dick From jpanzer@google.com Tue Dec 1 23:13:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794433A67F7 for ; Tue, 1 Dec 2009 23:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.939 X-Spam-Level: X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3axij9ki-j2f for ; Tue, 1 Dec 2009 23:13:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id BCD0E3A6A11 for ; Tue, 1 Dec 2009 23:13:16 -0800 (PST) Received: from spaceape11.eur.corp.google.com (spaceape11.eur.corp.google.com [172.28.16.145]) by smtp-out.google.com with ESMTP id nB26eJqx006078 for ; Tue, 1 Dec 2009 22:40:20 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259736021; bh=ameSsCMw3COYOwrCebFNww7EAYg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AP3SQ3TLkY9F72WAd3pDSPkKNGAAWs0G/qCOnmcfkV3mPEu+YX0oQO9SoJDKkgGne jz3MwlS+7AoYGiCzjRnOA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=pIzgOWoB9NZEx9ZzBTuqRkP2oUOsgMJTgjsLUdK+vZRxsPrHpvrzPnWw/i+KJLyT3 z/VnsTHX/dh2ShG6S+yhQ== Received: from pwi2 (pwi2.prod.google.com [10.241.219.2]) by spaceape11.eur.corp.google.com with ESMTP id nB26eFul004967 for ; Tue, 1 Dec 2009 22:40:16 -0800 Received: by pwi2 with SMTP id 2so3221043pwi.16 for ; Tue, 01 Dec 2009 22:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.253.18 with SMTP id a18mr6719756wai.224.1259736015434; Tue, 01 Dec 2009 22:40:15 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Tue, 1 Dec 2009 22:39:55 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e68786b8b5f29f0479b925e1 X-System-Of-Record: true Cc: Dick Hardt , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" , "" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 07:13:19 -0000 --0016e68786b8b5f29f0479b925e1 Content-Type: text/plain; charset=ISO-8859-1 I am not sure what the practical impact will be, but for what it's worth I support the concept of recommending TLS (SHOULD, not MUST) in general, and also the concept of moving forward. Side note: In prior IETF standards efforts I've been involved with, having very specific spec language proposals to get consensus around was helpful. In this case that'd be premature but I think that getting to the point where we can start doing that would help bring these discussions to closure earlier, and make it stick. (To change a prior consensus, new specific language would need to be drafted that replaces the old language, and that would need a new consensus; this is a much higher bar than just passively opposing something). Side note 2: RFC 5023 (AtomPub) has a pair of paragraphs that are pertinent, though you may need a standards wonk to interpret them properly. In many ways they're a cry for help :) : > The type of authentication deployed is a local decision made by the server > operator. Clients are likely to face authentication schemes that vary across > server deployments. At a minimum, client and server implementations *must* be > capable of being configured to use HTTP Basic Authentication [RFC2617]<#RFC2617> in > conjunction with a connection made with TLS 1.0[RFC2246] <#RFC2246> or a > subsequent standards-track version of TLS (such as [RFC4346] <#RFC4346>), > supporting the conventions for using HTTP over TLS described in [RFC2818]<#RFC2818> > . > > The choice of authentication mechanism will impact interoperability. The > minimum level of security referenced above (Basic Authentication with TLS) > is considered good practice for Internet applications at the time of > publication of this specification and sufficient for establishing a baseline > for interoperability. Implementers are encouraged to investigate and use > alternative mechanisms regarded as equivalently good or better at the time > of deployment. It is *recommended* that clients be implemented in such a > way that new authentication schemes can be deployed. > -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Tue, Dec 1, 2009 at 10:04 PM, Eran Hammer-Lahav wrote: > > > I would like to make an official request to the chair for a consensus call > on recommending SSL but keeping it optional in the various OAuth components. > We can figure out how strong to make the language (or how scary), and we may > make it mandatory in some flows/profiles, but I would like to be done with > this discussion (for the n time). > > If someone will want to raise new arguments, well, this is the IETF so who > can stop them? :-) > > EHL > > > -----Original Message----- > > From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] > > Sent: Tuesday, December 01, 2009 9:51 PM > > To: Brian Eaton > > Cc: Eran Hammer-Lahav; Peter Saint-Andre; ; > > Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org > > Subject: Re: [OAUTH-WG] why are we signing? > > > > > > On 2009-12-01, at 5:46 PM, Brian Eaton wrote: > > > > > On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav > > wrote: > > >>> Getting a Class 1 cert from the likes of StartSSL is easy as pie > > >>> these days. IMHO there is no excuse for not deploying SSL if you > > >>> care one whit about security. The problem is that too many > > >>> small-scale developers (and big companies!) simply don't care. > > >> > > >> Don't care, don't need that much security, don't understand it, etc. > > Bottom line is that requiring SSL is certain to fork this work if not > done right. > > > > > > Note, however, that someone who can't get SSL working and still > > > deploys OAuth has basically no security against eavesdroppers or MITM > > > attacks, and certainly can't expect OAuth to provide it. The issues > > > are in the token issuance phase: these organizations are sending user > > > passwords and session cookies in clear text! OAuth is the least of > > > their security concerns, > > > > > > If the cost of SSL outweighs the risk of a security breach, then why > would a > > developer deploying OAuth choose to sign their messages rather then use > > the simpler bearer token? > > > > Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think > > that is a good question. Perhaps it should be RECOMMENDED, and > > deployments can make their own benefit analysis. > > > > -- Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e68786b8b5f29f0479b925e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not sure what the practical impact will be, but for what it's= worth I support the concept of recommending TLS (SHOULD, not MUST) in gene= ral, and also the concept of moving forward.

Side note:= =A0In prior IETF standards efforts I've been involved with, having ver= y specific spec language proposals to get consensus around was helpful. =A0= In this case that'd be premature but I think that getting to the point = where we can start doing that would help bring these discussions to closure= earlier, and make it stick. =A0 (To change a prior consensus, new specific= language would need to be drafted that replaces the old language, and that= would need a new consensus; this is a much higher bar than just passively = opposing something).

Side note 2: =A0RFC 5023 (AtomPub) has a pair of paragraphs = that are pertinent, though you may need a standards wonk to interpret them = properly. =A0In many ways they're a cry for help :) :

The type of authentication deployed= is a local decision made by the server operator. Clients are likely to fac= e authentication schemes that vary across server deployments. At a minimum,= client and server implementations=A0must= =A0be capable of being configured to use HTTP Basic Authentication=A0[RFC2617]=A0in conjunction with a connection made with TLS= 1.0[RFC2246]=A0or a subsequent standards-track version of TLS (such as=A0[RFC4346]), supporting the conventions for using HTTP over TLS = described in=A0[RFC2818].

recommended=A0that clien= ts be implemented in such a way that new authentication schemes can be depl= oyed.


--
John Panzer / Google<= br>jpanzer@google.com / abstractioneer.org / @jpanzer



On Tue, Dec 1, 2009 at 10:04 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
<smiling but not joking>

I would like to make an official request to the chair for a consensus call = on recommending SSL but keeping it optional in the various OAuth components= . We can figure out how strong to make the language (or how scary), and we = may make it mandatory in some flows/profiles, but I would like to be done w= ith this discussion (for the n time).

If someone will want to raise new arguments, well, this is the IETF so who = can stop them? :-)

EHL

> -----Original Message-----
> From: Dick Hardt [mailto:D= ick.Hardt@microsoft.com]
> Sent: Tuesday, December 01, 2009 9:51 PM
> To: Brian Eaton
> Cc: Eran Hammer-Lahav; Peter Saint-Andre; <ext@core3.amsl.com>;
> Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org
> Subject: Re: [OAUTH-WG] why are we signing?
>
>
> On 2009-12-01, at 5:46 PM, Bri= an Eaton wrote:
>
> > On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav
> <eran@hueniverse.com>= wrote:
> >>> Getting a Class 1 cert from the likes of StartSSL is easy= as pie
> >>> these days. IMHO there is no excuse for not deploying SSL= if you
> >>> care one whit about security. The problem is that too man= y
> >>> small-scale developers (and big companies!) simply don= 9;t care.
> >>
> >> Don't care, don't need that much security, don't = understand it, etc.
> Bottom line is that requiring SSL is certain to fork this work if not = done right.
> >
> > Note, however, that someone who can't get SSL working and sti= ll
> > deploys OAuth has basically no security against eavesdroppers or = MITM
> > attacks, and certainly can't expect OAuth to provide it. =A0T= he issues
> > are in the token issuance phase: these organizations are sending = user
> > passwords and session cookies in clear text! =A0OAuth is the leas= t of
> > their security concerns,
>
>
> If the cost of SSL outweighs the risk of a security breach, then why w= ould a
> developer deploying OAuth choose to sign their messages rather then us= e
> the simpler bearer token?
>
> Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I thi= nk
> that is a good question. Perhaps it should be RECOMMENDED, and
> deployments can make their own benefit analysis.
>
> -- Dick
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e68786b8b5f29f0479b925e1-- From stephen.farrell@cs.tcd.ie Wed Dec 2 01:48:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F8028C0E7 for ; Wed, 2 Dec 2009 01:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.626 X-Spam-Level: X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO62WnmOzxBl for ; Wed, 2 Dec 2009 01:48:36 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 7916428C15D for ; Wed, 2 Dec 2009 01:48:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 8A450360084 for ; Wed, 2 Dec 2009 09:48:27 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFYZbCAy6Dsk for ; Wed, 2 Dec 2009 09:48:26 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id A8DC2360059 for ; Wed, 2 Dec 2009 09:48:26 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id A2A3D7C315 for ; Wed, 2 Dec 2009 09:48:26 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKwZA1l7Uy6Z for ; Wed, 2 Dec 2009 09:48:26 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id 0811D7C30A for ; Wed, 2 Dec 2009 09:48:26 +0000 (GMT) Message-ID: <4B1637EB.5080502@cs.tcd.ie> Date: Wed, 02 Dec 2009 09:48:27 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: "oauth@ietf.org" References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 09:48:37 -0000 I think we'll need an analysis of where we end up wanting TLS for the protocols we produce. I wouldn't expect any big surprises, but right now I don't think we can be sure since things seems to be in flux to some extent. Then, I'd be for saying that TLS MUST be used for those operations. However, I can well believe that there may be some niches where using TLS isn't easy, so I could live with something like: it MUST be possible to use TLS, and that deployments SHOULD use it, with guidance as to the type of scenario where we think TLS really has to be turned on, and maybe text about why sometimes people can't do that. So I don't think we can finish this discussion at this stage. S. Eran Hammer-Lahav wrote: > > > I would like to make an official request to the chair for a consensus call on recommending SSL but keeping it optional in the various OAuth components. We can figure out how strong to make the language (or how scary), and we may make it mandatory in some flows/profiles, but I would like to be done with this discussion (for the n time). > > If someone will want to raise new arguments, well, this is the IETF so who can stop them? :-) > > EHL > >> -----Original Message----- >> From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] >> Sent: Tuesday, December 01, 2009 9:51 PM >> To: Brian Eaton >> Cc: Eran Hammer-Lahav; Peter Saint-Andre; ; >> Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org >> Subject: Re: [OAUTH-WG] why are we signing? >> >> >> On 2009-12-01, at 5:46 PM, Brian Eaton wrote: >> >>> On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav >> wrote: >>>>> Getting a Class 1 cert from the likes of StartSSL is easy as pie >>>>> these days. IMHO there is no excuse for not deploying SSL if you >>>>> care one whit about security. The problem is that too many >>>>> small-scale developers (and big companies!) simply don't care. >>>> Don't care, don't need that much security, don't understand it, etc. >> Bottom line is that requiring SSL is certain to fork this work if not done right. >>> Note, however, that someone who can't get SSL working and still >>> deploys OAuth has basically no security against eavesdroppers or MITM >>> attacks, and certainly can't expect OAuth to provide it. The issues >>> are in the token issuance phase: these organizations are sending user >>> passwords and session cookies in clear text! OAuth is the least of >>> their security concerns, >> >> If the cost of SSL outweighs the risk of a security breach, then why would a >> developer deploying OAuth choose to sign their messages rather then use >> the simpler bearer token? >> >> Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think >> that is a good question. Perhaps it should be RECOMMENDED, and >> deployments can make their own benefit analysis. >> >> -- Dick > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From idan@pixane.com Wed Dec 2 02:16:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57FF428C0E7 for ; Wed, 2 Dec 2009 02:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plc9w035PBg9 for ; Wed, 2 Dec 2009 02:16:20 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id E46233A67FB for ; Wed, 2 Dec 2009 02:16:19 -0800 (PST) Received: by ewy7 with SMTP id 7so42758ewy.28 for ; Wed, 02 Dec 2009 02:16:09 -0800 (PST) Received: by 10.216.90.1 with SMTP id d1mr62329wef.136.1259748968636; Wed, 02 Dec 2009 02:16:08 -0800 (PST) Received: from ?10.0.0.5? (93-173-158-244.bb.netvision.net.il [93.173.158.244]) by mx.google.com with ESMTPS id p37sm2234681gvf.23.2009.12.02.02.16.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 02:16:07 -0800 (PST) Message-Id: <53ABC19D-22F9-49D2-A06C-D8B7BD9375FD@pixane.com> From: Idan Gazit To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209F70@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Dec 2009 12:16:05 +0200 References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <90C41DD21FB7C64BB94121FBBC2E72343785209F70@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 10:16:21 -0000 It's been a while since I last looked at it, quite possibly before June, so it might have been the 1.0 spec. From looking at oauth.net now, it seems that more introductory material was added (or made more prominent) since last I saw it. My experience with the spec was sitting down to read it every once in a while and getting bogged down in signature methods and precise language describing the various entities in an OAuth transaction. I came to the spec with a good idea of what OAuth is and what it is supposed to accomplish, I just wanted a non-authoritative list of steps for a run-of-the-mill OAuth transaction written for ease of understanding rather than maximal specificity. Not instead of the spec, but in addition to, something that I could use to orient myself within the spec. Again, I'd like to emphasize that I'm not criticizing the spec. I think my needs are representative of a common use-case: experienced web developer looking to provide or consume an OAuth service, probably using an existing library, and therefore disinterested in signature methods and other things which are already abstracted away. If I had to learn how HTTP worked by reading RFC2516 I'd probably be hopelessly lost too, but thankfully the internets are chock-full of diagrams which make the learning curve less steep. Hope I haven't added too much noise to the list! I'm happy to provide a "cold eye" to future writing if it will be of help. -I On Dec 2, 2009, at 4:43 AM, Eran Hammer-Lahav wrote: > Which version of the 'long and detailed' spec? > > EHL From paul.madsen@gmail.com Wed Dec 2 05:23:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4433B3A6AC8 for ; Wed, 2 Dec 2009 05:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5umd4L-l27my for ; Wed, 2 Dec 2009 05:23:58 -0800 (PST) Received: from mail-vw0-f184.google.com (mail-vw0-f184.google.com [209.85.212.184]) by core3.amsl.com (Postfix) with ESMTP id ECA6D3A6AB2 for ; Wed, 2 Dec 2009 05:23:57 -0800 (PST) Received: by vws14 with SMTP id 14so69452vws.32 for ; Wed, 02 Dec 2009 05:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ib+/JY0Ur1vxkS+TmnmI9yK0caQtkzl+ZDRE6dspm9s=; b=E/+cLZytvuNdkjYSnYmWhwSILI+8dOLrh8ahWEtTGmHfcv4p1Lj3KvOpJUK9xkJiTy Mp0zlWLzH6L+Nr7DzohMCxbWas+Psm1k4VMLpBLZFmDIod5LBpSy+UmE77cNMrGsRJfr Yvajcda8APVel8PDFBwQG2C3JE5wuk/7E6c08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XPskbgMlRa5Ea4DYjFCeqOXf979uL83kLGIQSXPYW/XoQOwGEP7mfJA+330hLDnrOM Pkjb//wMr6+IcGmUSrmKiMJtVqNDyKv2Jd+yLJ7oF+EyEnK29UDv92TNwZgnSztYXOqc LimuFluYS8z+r8FqDSvFQuK3VIAJjLZ8xFcLg= Received: by 10.220.127.2 with SMTP id e2mr145760vcs.10.1259760226677; Wed, 02 Dec 2009 05:23:46 -0800 (PST) Received: from ?192.168.0.195? (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.180.160]) by mx.google.com with ESMTPS id 22sm2210380vws.14.2009.12.02.05.23.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 05:23:45 -0800 (PST) Message-ID: <4B166A53.1040708@gmail.com> Date: Wed, 02 Dec 2009 08:23:31 -0500 From: Paul Madsen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Idan Gazit References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> In-Reply-To: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 13:23:59 -0000 Idan, typo in Step E 'oauth_vesion (optional)' paul Idan Gazit wrote: > Hey folks, > > I redrew/updated an old diagram > (http://documentation.fring.com/images/1/11/Oauth_diagram.png) > outlining the OAuth authentication flow. The old one didn't reflect > the changes in 1.0a. > > The updated diagrams are here: > > http://s3.pixane.com/Oauth_diagram.png > http://s3.pixane.com/Oauth_diagram.pdf > > Please feel free to use them, I hereby place them in the public domain. > > I was pointed in their direction by Mike Malone, after having looked > for exactly such a thing (for quite a while). He mentioned that the > reason it was chucked from the documentation is that it doesn't > reflect the changes made in the wake of the session fixation attack. I > took the old diagram, took the spec, and updated as required, with > some minor changes for legibility and aesthetics. > > Speaking as somebody who has tried (and failed) to digest OAuth by > means of the long and detailed spec, this sort of diagram is extremely > helpful in getting the "big picture" across. I'm not knocking the need > for a good spec, but a one-page overview that pulls it all together > without going into too much detail is sorely missing from the docs. > This diagram goes a long way towards meeting that need. > > Just my $0.02! Thanks for authoring this standard, hope this is useful! > > -Idan > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From idan@pixane.com Wed Dec 2 05:30:20 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F223A688D for ; Wed, 2 Dec 2009 05:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9atUxpQqpK3W for ; Wed, 2 Dec 2009 05:30:20 -0800 (PST) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 6451C3A6862 for ; Wed, 2 Dec 2009 05:30:19 -0800 (PST) Received: by ewy6 with SMTP id 6so226522ewy.29 for ; Wed, 02 Dec 2009 05:30:08 -0800 (PST) Received: by 10.216.87.5 with SMTP id x5mr38755wee.75.1259760605646; Wed, 02 Dec 2009 05:30:05 -0800 (PST) Received: from ?10.0.0.5? (93-173-158-244.bb.netvision.net.il [93.173.158.244]) by mx.google.com with ESMTPS id p37sm2582375gvf.23.2009.12.02.05.30.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 05:30:05 -0800 (PST) Message-Id: <940468BA-16AF-4322-BB0C-C6985A06CA6E@pixane.com> From: Idan Gazit To: Paul Madsen In-Reply-To: <4B166A53.1040708@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Dec 2009 15:29:56 +0200 References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B166A53.1040708@gmail.com> X-Mailer: Apple Mail (2.936) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 13:30:20 -0000 Whoops, fixed. Good catch! Replaced the old versions, same URLs: http://s3.pixane.com/Oauth_diagram.png http://s3.pixane.com/Oauth_diagram.pdf Thanks! -I On Dec 2, 2009, at 3:23 PM, Paul Madsen wrote: > Idan, typo in Step E > > 'oauth_vesion (optional)' > > paul From prateek.mishra@oracle.com Wed Dec 2 07:19:54 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC96728C207 for ; Wed, 2 Dec 2009 07:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyxgNxeajdzA for ; Wed, 2 Dec 2009 07:19:53 -0800 (PST) Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by core3.amsl.com (Postfix) with ESMTP id 3F0EC28C203 for ; Wed, 2 Dec 2009 07:19:52 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nB2FJVja013858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Dec 2009 15:19:32 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id nB25ggVU012112; Wed, 2 Dec 2009 15:19:45 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 744604121259767169; Wed, 02 Dec 2009 07:19:29 -0800 Received: from [192.168.1.2] (/209.6.179.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Dec 2009 07:19:29 -0800 Message-ID: <4B16855C.90209@oracle.com> Date: Wed, 02 Dec 2009 10:18:52 -0500 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stephen Farrell References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1637EB.5080502@cs.tcd.ie> In-Reply-To: <4B1637EB.5080502@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4B168589.000F:SCFMA4539814,ss=1,fgs=0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 15:19:54 -0000 Stephen, +1 from our side. Here is a newbie question: does the IETF process require a discussion of threats and countermeasures as part of the specification? - explaining the specific situations that rely on SSL or signing and what the consequences of "turning it off" might be... - prateek > I think we'll need an analysis of where we end up wanting TLS > for the protocols we produce. I wouldn't expect any big > surprises, but right now I don't think we can be sure since > things seems to be in flux to some extent. > > Then, I'd be for saying that TLS MUST be used for those operations. > However, I can well believe that there may be some niches where > using TLS isn't easy, so I could live with something like: it MUST > be possible to use TLS, and that deployments SHOULD use it, with > guidance as to the type of scenario where we think TLS really > has to be turned on, and maybe text about why sometimes people > can't do that. > > So I don't think we can finish this discussion at this stage. > > S. > > Eran Hammer-Lahav wrote: > >> >> >> I would like to make an official request to the chair for a consensus call on recommending SSL but keeping it optional in the various OAuth components. We can figure out how strong to make the language (or how scary), and we may make it mandatory in some flows/profiles, but I would like to be done with this discussion (for the n time). >> >> If someone will want to raise new arguments, well, this is the IETF so who can stop them? :-) >> >> EHL >> >> >>> -----Original Message----- >>> From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] >>> Sent: Tuesday, December 01, 2009 9:51 PM >>> To: Brian Eaton >>> Cc: Eran Hammer-Lahav; Peter Saint-Andre; ; >>> Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org >>> Subject: Re: [OAUTH-WG] why are we signing? >>> >>> >>> On 2009-12-01, at 5:46 PM, Brian Eaton wrote: >>> >>> >>>> On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav >>>> >>> wrote: >>> >>>>>> Getting a Class 1 cert from the likes of StartSSL is easy as pie >>>>>> these days. IMHO there is no excuse for not deploying SSL if you >>>>>> care one whit about security. The problem is that too many >>>>>> small-scale developers (and big companies!) simply don't care. >>>>>> >>>>> Don't care, don't need that much security, don't understand it, etc. >>>>> >>> Bottom line is that requiring SSL is certain to fork this work if not done right. >>> >>>> Note, however, that someone who can't get SSL working and still >>>> deploys OAuth has basically no security against eavesdroppers or MITM >>>> attacks, and certainly can't expect OAuth to provide it. The issues >>>> are in the token issuance phase: these organizations are sending user >>>> passwords and session cookies in clear text! OAuth is the least of >>>> their security concerns, >>>> >>> If the cost of SSL outweighs the risk of a security breach, then why would a >>> developer deploying OAuth choose to sign their messages rather then use >>> the simpler bearer token? >>> >>> Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think >>> that is a good question. Perhaps it should be RECOMMENDED, and >>> deployments can make their own benefit analysis. >>> >>> -- Dick >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From zachary.zeltsan@alcatel-lucent.com Wed Dec 2 08:16:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 403B128C0E5 for ; Wed, 2 Dec 2009 08:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wlrf5uDoEtvz for ; Wed, 2 Dec 2009 08:16:13 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 2241328C1FC for ; Wed, 2 Dec 2009 08:16:12 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id nB2GG0Sc011684; Wed, 2 Dec 2009 10:16:00 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id nB2GG0VM000670; Wed, 2 Dec 2009 10:16:00 -0600 (CST) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 2 Dec 2009 10:15:59 -0600 From: "Zeltsan, Zachary (Zachary)" To: Mike Malone , John Panzer Date: Wed, 2 Dec 2009 10:15:57 -0600 Thread-Topic: [OAUTH-WG] why are we signing?; OAuth 2.0 / Charter Thread-Index: Acpys0y+MmOWYlK7SZqw1SBCsPL0WAAss0VA Message-ID: <5710F82C0E73B04FA559560098BF95B124EEB6B910@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: Dick Hardt , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing?; OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:16:14 -0000 On Tue, Dec 1, 2009 at 1:23 PM, Mike Malone =20 wrote: =20 > On Tue, Dec 1, 2009 at 8:52 AM, John Panzer=20 > wrote: > > On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone=20 > wrote: > >> > >> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt=20 > >> > >> wrote: > >> > > >> > On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: > >> >> > >> >> I for one, see great value in offering some form of=20 > crypto-based=20 > >> >> security for cases where TLS is not suitable. > >> > > >> > Are these use cases enumerated somewhere? > >> > >> I'm not completely opposed to the TLS route, but since you asked... > >> off the top of my head, here are a couple drawbacks to using TLS=20 > >> instead of signing: > >> =A0- Bigger burden on developers who need to debug this stuff (i.e.,=20 > >> you can't sniff your own traffic to debug requests & responses). > >> =A0- Properly setting up TLS can be complicated and expensive. For=20 > >> developers who don't have a lot of ops skills the barrier=20 > may be too=20 > >> high. > >> =A0- You can no longer pass around signed URLs as another level of=20 > >> delegation (a use case that I use regularly for making XHR & POST=20 > >> requests from the browser). This could be a non-issue if=20 > some other=20 > >> mechanism for fourth-party delegation existed. > >> > > Can you elaborate on the above? =A0For OAuth, signatures (bound to a=20 > > particular Consumer Secret that can't be leaked to=20 > subcontractors) is=20 > > a barrier to multi-level delegation. >=20 > Right, but you can do poor-man's delegation by signing a URL=20 > and passing it off to a third (er, fourth) party to use. I've=20 > seen this most often with web apps, where the app (the OAuth=20 > Consumer) wants to make a request to the Provider directly=20 > from the browser (e.g., POSTing a large file). They can't=20 > sign the URL in javascript without compromising the Consumer=20 > Secret, so the the URL is signed server side and passed to=20 > the browser for use. There is another way to do a multi-level delegation without revealing a cli= ent's secret. The method described in the draft http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-00 along with a use case for re-delegating authorization. In my opinion, the multi-level delegation should be on a new charter. (This= makes this message relevant to the thread with the subject "OAuth 2.0 / Ch= arter") > Mike >=20 Zachary > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > = From eran@hueniverse.com Wed Dec 2 08:18:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C33F28C1FD for ; Wed, 2 Dec 2009 08:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aztN49gszkUJ for ; Wed, 2 Dec 2009 08:18:36 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D64EA28C1EC for ; Wed, 2 Dec 2009 08:18:36 -0800 (PST) Received: (qmail 31240 invoked from network); 2 Dec 2009 16:18:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 16:18:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 2 Dec 2009 09:18:27 -0700 From: Eran Hammer-Lahav To: Idan Gazit Date: Wed, 2 Dec 2009 09:18:37 -0700 Thread-Topic: [OAUTH-WG] OAuth 1.0a flow diagram Thread-Index: AcpzOHjIU/AKHtPXTM6WT3brAc/nigAMmQfw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A0C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <90C41DD21FB7C64BB94121FBBC2E72343785209F70@P3PW5EX1MB01.EX1.SECURESERVER.NET> <53ABC19D-22F9-49D2-A06C-D8B7BD9375FD@pixane.com> In-Reply-To: <53ABC19D-22F9-49D2-A06C-D8B7BD9375FD@pixane.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:18:39 -0000 I want you to criticize the spec! I already called it worse names than most= people so you are not likely to offend anyone. Take a look at the new spec= [1] and let me know if it makes understanding the protocol easier for your= target audience. EHL [1] http://tools.ietf.org/html/draft-hammer-oauth-07 > -----Original Message----- > From: Idan Gazit [mailto:idan@pixane.com] > Sent: Wednesday, December 02, 2009 2:16 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram >=20 > It's been a while since I last looked at it, quite possibly before June, = so it > might have been the 1.0 spec. >=20 > From looking at oauth.net now, it seems that more introductory material > was added (or made more prominent) since last I saw it. >=20 > My experience with the spec was sitting down to read it every once in a > while and getting bogged down in signature methods and precise language > describing the various entities in an OAuth transaction. I came to the sp= ec > with a good idea of what OAuth is and what it is supposed to accomplish, = I > just wanted a non-authoritative list of steps for a run-of-the-mill OAuth > transaction written for ease of understanding rather than maximal specifi= city. > Not instead of the spec, but in addition to, something that I could use t= o > orient myself within the spec. >=20 > Again, I'd like to emphasize that I'm not criticizing the spec. I think m= y needs > are representative of a common use-case: experienced web developer > looking to provide or consume an OAuth service, probably using an existin= g > library, and therefore disinterested in signature methods and other thing= s > which are already abstracted away. If I had to learn how HTTP worked by > reading RFC2516 I'd probably be hopelessly lost too, but thankfully the > internets are chock-full of diagrams which make the learning curve less > steep. >=20 > Hope I haven't added too much noise to the list! I'm happy to provide a "= cold > eye" to future writing if it will be of help. >=20 > -I >=20 >=20 > On Dec 2, 2009, at 4:43 AM, Eran Hammer-Lahav wrote: >=20 > > Which version of the 'long and detailed' spec? > > > > EHL From eran@hueniverse.com Wed Dec 2 08:27:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15C628C1F2 for ; Wed, 2 Dec 2009 08:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f98U9iR+hnRQ for ; Wed, 2 Dec 2009 08:27:10 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 17D503A6768 for ; Wed, 2 Dec 2009 08:27:10 -0800 (PST) Received: (qmail 4012 invoked from network); 2 Dec 2009 16:27:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 16:27:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Dec 2009 09:27:00 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Wed, 2 Dec 2009 09:27:09 -0700 Thread-Topic: Remove client credentials from protected resource requests Thread-Index: AcpzbEt79CF4z/DcQ0qGsnV8DDZl6A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AZGc AjQL BBkC BTJ3 Bacn BzXw B27v Coks DMEB DbSW EFYc Fm0l Gd0M HJhw JTqT KaLK; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {138F86BE-BE4C-4525-A607-BE1AA95B3B77}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Wed, 02 Dec 2009 16:27:09 GMT; UgBlAG0AbwB2AGUAIABjAGwAaQBlAG4AdAAgAGMAcgBlAGQAZQBuAHQAaQBhAGwAcwAgAGYAcgBvAG0AIABwAHIAbwB0AGUAYwB0AGUAZAAgAHIAZQBzAG8AdQByAGMAZQAgAHIAZQBxAHUAZQBzAHQAcwA= x-cr-puzzleid: {138F86BE-BE4C-4525-A607-BE1AA95B3B77} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:27:11 -0000 We seem to have consensus around dropping the client credentials from prote= cted resource requests, using only the token (with optional secret or key) = to authenticate the request. This means clients will be free to share token= s with other clients without the server being able to authenticate the clie= nt. Client authentication is already a problematic feature in 1.0 as it only wo= rks for web-based applications capable of keeping the client credentials se= cret. WRAP dropped it to support crypto-free client experience. It is curre= ntly optional in 1.0. I would very much like us to drop client credentials from protected resourc= es requests, but want to make sure people are aware of the consequences. I = plan to drop it in my first draft of the Token scheme. EHL From leah.culver@gmail.com Wed Dec 2 08:41:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880983A6AE3 for ; Wed, 2 Dec 2009 08:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZFKjmWK9MLE for ; Wed, 2 Dec 2009 08:41:21 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 979F23A6ADB for ; Wed, 2 Dec 2009 08:41:21 -0800 (PST) Received: by pwi19 with SMTP id 19so258111pwi.29 for ; Wed, 02 Dec 2009 08:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=LO7nzw7K8gcZdrmO5oiZ7OaFwGLwdSuK5GtNxSieaLY=; b=YTr8kseAhfdgyZT6M7+QvYYTSzFD6fGf5I5sfh8RZ9JiK5Q7cOsNoll59eeUKKPwS6 7n+8ZE4fjn/LkOZfYrAGtz4rsEtMRAItz6/3VTG+gh3qJKrlO8G5p3/M5jbi0Lq+XE68 qmM4QSHOtG/2uufQn9IBZxFowsUQCvp5cSdU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=iBxu/WhdDgkhEBdZ7xXQZZrg4lWvvan/7pM1Bk1VJPJgGou9FW/ppxr6PExWVKP4Uq 4xWy5k13YhUNjzoebduB5YnXOKpK4VDzBcvrcAh9sP1kTBkPP0cmjbtJrERVAWs7GQVl C0q3EX5DDO2FjVkssOTBB8Hx9M3y53CZNGJME= MIME-Version: 1.0 Received: by 10.140.191.12 with SMTP id o12mr20746rvf.163.1259772071160; Wed, 02 Dec 2009 08:41:11 -0800 (PST) In-Reply-To: <940468BA-16AF-4322-BB0C-C6985A06CA6E@pixane.com> References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B166A53.1040708@gmail.com> <940468BA-16AF-4322-BB0C-C6985A06CA6E@pixane.com> From: Leah Culver Date: Wed, 2 Dec 2009 08:40:51 -0800 Message-ID: <9184e2a80912020840g25105ceqb873be28a922127a@mail.gmail.com> To: Idan Gazit Content-Type: multipart/alternative; boundary=000e0cd2297accab370479c18a39 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:41:22 -0000 --000e0cd2297accab370479c18a39 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the new diagrams! I'm giving an OAuth talk today and I'll probably use them. They look great! Thanks! Leah On Wed, Dec 2, 2009 at 5:29 AM, Idan Gazit wrote: > Whoops, fixed. Good catch! > > Replaced the old versions, same URLs: > > > http://s3.pixane.com/Oauth_diagram.png > http://s3.pixane.com/Oauth_diagram.pdf > > Thanks! > > -I > > > On Dec 2, 2009, at 3:23 PM, Paul Madsen wrote: > > Idan, typo in Step E >> >> 'oauth_vesion (optional)' >> >> paul >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd2297accab370479c18a39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the new diagrams! I'm giving an OAuth talk today and I'l= l probably use them. They look great!

Thanks!
Leah


On Wed, Dec 2, 2009 at 5:29 AM, Idan Gazit <idan@pixane.com>= ; wrote:
Whoops, fixed. Go= od catch!

Replaced the old versions, same URLs:


http:/= /s3.pixane.com/Oauth_diagram.png
http:/= /s3.pixane.com/Oauth_diagram.pdf

Thanks!

-I


On Dec 2, 2009, at 3:23 PM, Paul Madsen wrote:

Idan, typo in Step E

'oauth_vesion (optional)'

paul

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--000e0cd2297accab370479c18a39-- From leah.culver@gmail.com Wed Dec 2 08:46:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB643A6943 for ; Wed, 2 Dec 2009 08:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rd8hVf+EOtJ0 for ; Wed, 2 Dec 2009 08:46:40 -0800 (PST) Received: from mail-px0-f184.google.com (mail-px0-f184.google.com [209.85.216.184]) by core3.amsl.com (Postfix) with ESMTP id 08AB03A67F4 for ; Wed, 2 Dec 2009 08:46:40 -0800 (PST) Received: by pxi14 with SMTP id 14so283662pxi.31 for ; Wed, 02 Dec 2009 08:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=ytDv0rOjv4DRETAgDYMWyOELWGrCkmLkr3nKOCH2XWI=; b=TXEonXyerCgAymg3YLKV21IV4rSO2xjZKY7XBxmJ+VTo9JbZuABhx0PyiDJBXhjSA7 6nwJj3s6IPRbJY3pDLny7umayOo0opx/bXJmusZj+i/TEJJ+o24PsEtDbqkl0FeDlZKV lgWiktJY3yvKgEmox+JnX+ZMpa4AD4JNEZR5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=x7gLmAy+VraJgEdCOGc4DTmV7IfqZdHCkDpiAqxS/pjgpAflXZrTsOwImFvXJc1UgD o8qNr84bkLuN1X+SdjmLKAYFq2GEh2ydlUmKNe4iBTUKYc7yFOEKcYiKPWBghnvHOKTL vKQmg0J2ngZ0ymPiibhhP/+lbZpA5suZb7kTU= MIME-Version: 1.0 Received: by 10.141.33.8 with SMTP id l8mr24240rvj.177.1259772389489; Wed, 02 Dec 2009 08:46:29 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Leah Culver Date: Wed, 2 Dec 2009 08:46:09 -0800 Message-ID: <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd1b6bec5fba40479c19d92 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:46:41 -0000 --000e0cd1b6bec5fba40479c19d92 Content-Type: text/plain; charset=ISO-8859-1 One issue with dropping client credentials may be that it's more difficult for providers to identify the client. For example, Twitter might be using the client credentials to add "from Tweetie" to their tweet meta data. This is just an example, I have no idea if this is how Twitter identifies clients. Do any providers have a problem with this? Is there another way to identify clients? Should the client information be saved server-side with the token data for future reference? I'm okay with dropping the client credentials but I'd like to make sure we still address this use case via other mechanisms. Thanks! Leah On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav wrote: > We seem to have consensus around dropping the client credentials from > protected resource requests, using only the token (with optional secret or > key) to authenticate the request. This means clients will be free to share > tokens with other clients without the server being able to authenticate the > client. > > Client authentication is already a problematic feature in 1.0 as it only > works for web-based applications capable of keeping the client credentials > secret. WRAP dropped it to support crypto-free client experience. It is > currently optional in 1.0. > > I would very much like us to drop client credentials from protected > resources requests, but want to make sure people are aware of the > consequences. I plan to drop it in my first draft of the Token scheme. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000e0cd1b6bec5fba40479c19d92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One issue with dropping client credentials may be that it's more diffic= ult for providers to identify the client.

For example, Twitter might= be using the client credentials to add "from Tweetie" to their t= weet meta data. This is just an example, I have no idea if this is how Twit= ter identifies clients.

Do any providers have a problem with this? Is there another way to iden= tify clients? Should the client information be saved server-side with the t= oken data for future reference?

I'm okay with dropping the clien= t credentials but I'd like to make sure we still address this use case = via other mechanisms.

Thanks!
Leah


On Wed, Dec 2, 20= 09 at 8:27 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
We seem to have consensus around dropping the client credentials from prote= cted resource requests, using only the token (with optional secret or key) = to authenticate the request. This means clients will be free to share token= s with other clients without the server being able to authenticate the clie= nt.

Client authentication is already a problematic feature in 1.0 as it only wo= rks for web-based applications capable of keeping the client credentials se= cret. WRAP dropped it to support crypto-free client experience. It is curre= ntly optional in 1.0.

I would very much like us to drop client credentials from protected resourc= es requests, but want to make sure people are aware of the consequences. I = plan to drop it in my first draft of the Token scheme.

EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--000e0cd1b6bec5fba40479c19d92-- From idan@pixane.com Wed Dec 2 08:47:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06EC3A6870 for ; Wed, 2 Dec 2009 08:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LsNqApsqVOh for ; Wed, 2 Dec 2009 08:47:59 -0800 (PST) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id AEA453A6AD8 for ; Wed, 2 Dec 2009 08:47:58 -0800 (PST) Received: by fxm10 with SMTP id 10so477000fxm.14 for ; Wed, 02 Dec 2009 08:47:45 -0800 (PST) Received: by 10.216.90.198 with SMTP id e48mr105797wef.188.1259772465340; Wed, 02 Dec 2009 08:47:45 -0800 (PST) Received: from ?10.0.0.5? (93-173-158-244.bb.netvision.net.il [93.173.158.244]) by mx.google.com with ESMTPS id u14sm2961676gvf.4.2009.12.02.08.47.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 08:47:41 -0800 (PST) Message-Id: <022D5168-DBB6-40F4-8C0E-1B376A8FCE23@pixane.com> From: Idan Gazit To: oauth@ietf.org In-Reply-To: <9184e2a80912020840g25105ceqb873be28a922127a@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Dec 2009 18:47:38 +0200 References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B166A53.1040708@gmail.com> <940468BA-16AF-4322-BB0C-C6985A06CA6E@pixane.com> <9184e2a80912020840g25105ceqb873be28a922127a@mail.gmail.com> X-Mailer: Apple Mail (2.936) Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:47:59 -0000 Honestly, somebody else made these first -- I just updated and prettified. I'd love to know who laid out the original and thank *them* -- it is extremely well-designed. -I On Dec 2, 2009, at 6:40 PM, Leah Culver wrote: > Thanks for the new diagrams! I'm giving an OAuth talk today and I'll > probably use them. They look great! > > Thanks! > Leah From GFFletch@aol.com Wed Dec 2 09:12:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57BCB28C0FA for ; Wed, 2 Dec 2009 09:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcDHdw3eO+4W for ; Wed, 2 Dec 2009 09:12:27 -0800 (PST) Received: from imr-db02.mx.aol.com (imr-db02.mx.aol.com [205.188.91.96]) by core3.amsl.com (Postfix) with ESMTP id 1E68928C21C for ; Wed, 2 Dec 2009 09:12:17 -0800 (PST) Received: from imo-ma03.mx.aol.com (imo-ma03.mx.aol.com [64.12.78.138]) by imr-db02.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB2HBjE9015378; Wed, 2 Dec 2009 12:11:45 -0500 Received: from GFFletch@aol.com by imo-ma03.mx.aol.com (mail_out_v42.5.) id l.d09.54897447 (37589); Wed, 2 Dec 2009 12:11:40 -0500 (EST) Received: from palantir.local ([10.181.87.216]) by cia-mb06.mx.aol.com (v126.13) with ESMTP id MAILCIAMB062-92d54b169fcb395; Wed, 02 Dec 2009 12:11:39 -0500 Message-ID: <4B169FCB.2010908@aol.com> Date: Wed, 02 Dec 2009 12:11:39 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> In-Reply-To: <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.87.216 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:12:43 -0000 I'm more concerned with replay than the ability to identify the client. Basically, dropping this requirement means that the short lived bearer tokens are replay-able not only by the client that received them but also by any one who sees them (hence the need for SSL in WRAP). Other mechanisms can be employed to identify the "client" (i.e. mutual TLS) but they require rather closed deployment models. However, that may be OK for those cases where this is required. This doesn't solve the twitter/tweetie case. Though I'm not sure how well the current solution solves it either (meaning it's probably pretty easy for someone to extract the consumer token and secret from tweetie source code). Note that twitter could modify their API to provide this capability if critical to their model. I do think that a signing profile should be supported, in addition to the bearer token model, for those cases that care about replay and some assurance that the entity that received the token (from the token issuer) is the entity presenting the access_token. This doesn't directly identify the client but does constrain replay scope. This is a critical requirement for some of our APIs. Thanks, George Leah Culver wrote: > One issue with dropping client credentials may be that it's more > difficult for providers to identify the client. > > For example, Twitter might be using the client credentials to add > "from Tweetie" to their tweet meta data. This is just an example, I > have no idea if this is how Twitter identifies clients. > > Do any providers have a problem with this? Is there another way to > identify clients? Should the client information be saved server-side > with the token data for future reference? > > I'm okay with dropping the client credentials but I'd like to make > sure we still address this use case via other mechanisms. > > Thanks! > Leah > > > On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav > wrote: > > We seem to have consensus around dropping the client credentials > from protected resource requests, using only the token (with > optional secret or key) to authenticate the request. This means > clients will be free to share tokens with other clients without > the server being able to authenticate the client. > > Client authentication is already a problematic feature in 1.0 as > it only works for web-based applications capable of keeping the > client credentials secret. WRAP dropped it to support crypto-free > client experience. It is currently optional in 1.0. > > I would very much like us to drop client credentials from > protected resources requests, but want to make sure people are > aware of the consequences. I plan to drop it in my first draft of > the Token scheme. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jpanzer@google.com Wed Dec 2 09:18:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1513A6807 for ; Wed, 2 Dec 2009 09:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.945 X-Spam-Level: X-Spam-Status: No, score=-105.945 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTaOTHJS-JBT for ; Wed, 2 Dec 2009 09:18:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id E8FB03A67A5 for ; Wed, 2 Dec 2009 09:18:53 -0800 (PST) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id nB2HIhrO003085 for ; Wed, 2 Dec 2009 17:18:44 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259774324; bh=sZ1V+VlP8GkEbh0ZRsJEEjKdhyA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TX5a6LDPpnpEf2pqwEKPdAeh5AE94mAjQrA7EAvojArNqxg4R06KomNgj27qq7jX4 8UZlHZOg+dT2QwIUNr+lg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=fZDfn1mjoj0qx4rVHOu8vh6kqIg0PorRiintrpBxlLy9lpaxqFw3lgvhAzkDcD+NK b1GW8lprEDWZosuYTb4Ag== Received: from pxi1 (pxi1.prod.google.com [10.243.27.1]) by zps18.corp.google.com with ESMTP id nB2HIQJY026427 for ; Wed, 2 Dec 2009 09:18:41 -0800 Received: by pxi1 with SMTP id 1so337446pxi.29 for ; Wed, 02 Dec 2009 09:18:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.33.33 with SMTP id g33mr718844wag.212.1259774319380; Wed, 02 Dec 2009 09:18:39 -0800 (PST) In-Reply-To: <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> From: John Panzer Date: Wed, 2 Dec 2009 09:18:19 -0800 Message-ID: To: Leah Culver Content-Type: multipart/alternative; boundary=001636b1461dcdc8b70479c21079 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:18:55 -0000 --001636b1461dcdc8b70479c21079 Content-Type: text/plain; charset=ISO-8859-1 I'm +1 on dropping explicit support for client credentials in the protected resource requests, because: 1. It is always possible to embed or reference a client ID in the opaque token sent along with the request, so no fundamental functionality is lost -- servers can always recover the data needed to add "from Tweetie"; 2. It simplifies accessing the protected resource; 3. (Speculative) I think it simplifies possible extensions to allow for controlled sub-delegation from one client to another. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Dec 2, 2009 at 8:46 AM, Leah Culver wrote: > One issue with dropping client credentials may be that it's more difficult > for providers to identify the client. > > For example, Twitter might be using the client credentials to add "from > Tweetie" to their tweet meta data. This is just an example, I have no idea > if this is how Twitter identifies clients. > > Do any providers have a problem with this? Is there another way to identify > clients? Should the client information be saved server-side with the token > data for future reference? > > I'm okay with dropping the client credentials but I'd like to make sure we > still address this use case via other mechanisms. > > Thanks! > Leah > > > > On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav wrote: > >> We seem to have consensus around dropping the client credentials from >> protected resource requests, using only the token (with optional secret or >> key) to authenticate the request. This means clients will be free to share >> tokens with other clients without the server being able to authenticate the >> client. >> >> Client authentication is already a problematic feature in 1.0 as it only >> works for web-based applications capable of keeping the client credentials >> secret. WRAP dropped it to support crypto-free client experience. It is >> currently optional in 1.0. >> >> I would very much like us to drop client credentials from protected >> resources requests, but want to make sure people are aware of the >> consequences. I plan to drop it in my first draft of the Token scheme. >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001636b1461dcdc8b70479c21079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm +1 on dropping explicit support for client credentials in the prote= cted resource requests, because:

1. It is always possibl= e to embed or reference a client ID in the opaque token sent along with the= request, so no fundamental functionality is lost -- servers can always rec= over the data needed to add "from Tweetie";
2. It simplifies accessing the protected resource;
3. (Specu= lative) I think it simplifies possible extensions to allow for controlled s= ub-delegation from one client to another.

--
John Panzer / Google
jpanzer@googl= e.com / abstractioneer.org / = @jpanzer



On Wed, Dec 2, 2009 at 8:46 AM, Leah Cul= ver <leah.cul= ver@gmail.com> wrote:
One issue with dropping client credentials may be that it's more diffic= ult for providers to identify the client.

For example, Twitter might= be using the client credentials to add "from Tweetie" to their t= weet meta data. This is just an example, I have no idea if this is how Twit= ter identifies clients.

Do any providers have a problem with this? Is there another way to iden= tify clients? Should the client information be saved server-side with the t= oken data for future reference?

I'm okay with dropping the clien= t credentials but I'd like to make sure we still address this use case = via other mechanisms.

Thanks!
Leah



On Wed, Dec 2, 2009 at 8:27= AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
We seem to have consensus around dropping the client credentials from prote= cted resource requests, using only the token (with optional secret or key) = to authenticate the request. This means clients will be free to share token= s with other clients without the server being able to authenticate the clie= nt.

Client authentication is already a problematic feature in 1.0 as it only wo= rks for web-based applications capable of keeping the client credentials se= cret. WRAP dropped it to support crypto-free client experience. It is curre= ntly optional in 1.0.

I would very much like us to drop client credentials from protected resourc= es requests, but want to make sure people are aware of the consequences. I = plan to drop it in my first draft of the Token scheme.

EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--001636b1461dcdc8b70479c21079-- From esjewett@gmail.com Wed Dec 2 09:21:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01E393A6953 for ; Wed, 2 Dec 2009 09:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVdR+pXQpUpc for ; Wed, 2 Dec 2009 09:21:02 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id E5A113A694C for ; Wed, 2 Dec 2009 09:21:01 -0800 (PST) Received: by pwi19 with SMTP id 19so287828pwi.29 for ; Wed, 02 Dec 2009 09:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=1RZC+wpSVHoWT4ZL4CaXeTAMhKKMc3Pi6tuj5FqFTIw=; b=IB5m5H1pXTWy9SvrEIPXvuvJDaoAtyvhmoFdFWhSXsnizUZbEHjpVixAtgmkYnyYay CIRLRoTg0yCvzJFAfrQKGYmE79toIvwK/pRos09ENyufRIty6NAGct8mhHKgIDq7/ULp I5aRQPosBLsKKO5KR1Qt+48n7w2A/Ir0FSY1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=oFJBEBuI0YAQ2FdVdy4tzT4XZEs++zbiKOswxOk5j+Pb1BEfdNyj/K0LCTZ4aVhpli 1LyyHyf5Sf8JL2d+3nhkeuCI9V6oT83VlVDhUe50UJSRYDvUpt45ZxxhRjHzbnm88TqX PSh/f/LGtCGVjuYlarmoZ6Mlj9PqRKni9IZcI= MIME-Version: 1.0 Received: by 10.141.28.19 with SMTP id f19mr23932rvj.60.1259774449437; Wed, 02 Dec 2009 09:20:49 -0800 (PST) In-Reply-To: <4B169FCB.2010908@aol.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> <4B169FCB.2010908@aol.com> Date: Wed, 2 Dec 2009 12:20:48 -0500 Message-ID: <68f4a0e80912020920k249dce49uecb3277279fd68b5@mail.gmail.com> From: Ethan Jewett To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:21:03 -0000 +1 to Eran's proposal. The optional token secret/key constrains replay scope, I think. Further clients are already free to share tokens with other clients. They just need to share the token, the token secret, the consumer key, and the consumer secret. This change (I believe) just gets rid of the fiction that the existence of a consumer key and secret gives the service provider some control over the actions of the client. Ethan On Wed, Dec 2, 2009 at 12:11 PM, George Fletcher wrote: > I'm more concerned with replay than the ability to identify the client. > Basically, dropping this requirement means that the short lived bearer > tokens are replay-able not only by the client that received them but also= by > any one who sees them (hence the need for SSL in WRAP). > > Other mechanisms can be employed to identify the "client" (i.e. mutual TL= S) > but they require rather closed deployment models. However, that may be OK > for those cases where this is required. > > This doesn't solve the twitter/tweetie case. Though I'm not sure how well > the current solution solves it either (meaning it's probably pretty easy = for > someone to extract the consumer token and secret from tweetie source code= ). > Note that twitter could modify their API to provide this capability if > critical to their model. > > I do think that a signing profile should be supported, in addition to the > bearer token model, for those cases that care about replay and some > assurance that the entity that received the token (from the token issuer)= is > the entity presenting the access_token. This doesn't directly identify th= e > client but does constrain replay scope. This is a critical requirement fo= r > some of our APIs. > > Thanks, > George > > Leah Culver wrote: >> >> One issue with dropping client credentials may be that it's more difficu= lt >> for providers to identify the client. >> >> For example, Twitter might be using the client credentials to add "from >> Tweetie" to their tweet meta data. This is just an example, I have no id= ea >> if this is how Twitter identifies clients. >> >> Do any providers have a problem with this? Is there another way to >> identify clients? Should the client information be saved server-side wit= h >> the token data for future reference? >> >> I'm okay with dropping the client credentials but I'd like to make sure = we >> still address this use case via other mechanisms. >> >> Thanks! >> Leah >> >> >> On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav > > wrote: >> >> =A0 =A0We seem to have consensus around dropping the client credentials >> =A0 =A0from protected resource requests, using only the token (with >> =A0 =A0optional secret or key) to authenticate the request. This means >> =A0 =A0clients will be free to share tokens with other clients without >> =A0 =A0the server being able to authenticate the client. >> >> =A0 =A0Client authentication is already a problematic feature in 1.0 as >> =A0 =A0it only works for web-based applications capable of keeping the >> =A0 =A0client credentials secret. WRAP dropped it to support crypto-free >> =A0 =A0client experience. It is currently optional in 1.0. >> >> =A0 =A0I would very much like us to drop client credentials from >> =A0 =A0protected resources requests, but want to make sure people are >> =A0 =A0aware of the consequences. I plan to drop it in my first draft of >> =A0 =A0the Token scheme. >> >> =A0 =A0EHL >> =A0 =A0_______________________________________________ >> =A0 =A0OAuth mailing list >> =A0 =A0OAuth@ietf.org >> =A0 =A0https://www.ietf.org/mailman/listinfo/oauth >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jpanzer@google.com Wed Dec 2 09:21:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32083A694C for ; Wed, 2 Dec 2009 09:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.947 X-Spam-Level: X-Spam-Status: No, score=-105.947 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKh3ltm9g2l2 for ; Wed, 2 Dec 2009 09:21:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1A4E73A6ADA for ; Wed, 2 Dec 2009 09:21:22 -0800 (PST) Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id nB2HLEfA006095 for ; Wed, 2 Dec 2009 17:21:14 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259774474; bh=VXfa9NqJ2DU+nfegTtlokSuUuAU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=yr7o/gexxo7BJgowwlHBuuYowQsxkWxbI/03K5v9rMF1VaX/1g6IxVN9zE3hwCq49 j7nQW5OdPTj2/HAFszcCw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=AKWMPiC/JxqzGYR/M/H+mFOIb/Y5NwUdm3Wj9MbnrOoHX7hrwDf+LPbS50aI8K5Ty MmGtTC2bW4rMGGUmOWT8Q== Received: from pxi29 (pxi29.prod.google.com [10.243.27.29]) by spaceape13.eur.corp.google.com with ESMTP id nB2HK4de025619 for ; Wed, 2 Dec 2009 09:21:12 -0800 Received: by pxi29 with SMTP id 29so297415pxi.1 for ; Wed, 02 Dec 2009 09:21:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.248.33 with SMTP id v33mr828577wah.77.1259774471331; Wed, 02 Dec 2009 09:21:11 -0800 (PST) In-Reply-To: <4B169FCB.2010908@aol.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> <4B169FCB.2010908@aol.com> From: John Panzer Date: Wed, 2 Dec 2009 09:20:51 -0800 Message-ID: To: George Fletcher Content-Type: multipart/alternative; boundary=0016e64ddb7edc61d80479c219ba X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:21:24 -0000 --0016e64ddb7edc61d80479c219ba Content-Type: text/plain; charset=ISO-8859-1 I think that a client id is orthogonal to replay attacks -- if I can see a client ID, why can't I copy it as easily as I could an opaque token and replay it? In other words, yes I agree that replay is a concern given other proposals, but I don't see how this proposal itself changes the story. (And I believe the replay concern is mitigated sufficiently by the other arguments on the other threads.) -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Dec 2, 2009 at 9:11 AM, George Fletcher wrote: > I'm more concerned with replay than the ability to identify the client. > Basically, dropping this requirement means that the short lived bearer > tokens are replay-able not only by the client that received them but also by > any one who sees them (hence the need for SSL in WRAP). > > Other mechanisms can be employed to identify the "client" (i.e. mutual TLS) > but they require rather closed deployment models. However, that may be OK > for those cases where this is required. > > This doesn't solve the twitter/tweetie case. Though I'm not sure how well > the current solution solves it either (meaning it's probably pretty easy for > someone to extract the consumer token and secret from tweetie source code). > Note that twitter could modify their API to provide this capability if > critical to their model. > > I do think that a signing profile should be supported, in addition to the > bearer token model, for those cases that care about replay and some > assurance that the entity that received the token (from the token issuer) is > the entity presenting the access_token. This doesn't directly identify the > client but does constrain replay scope. This is a critical requirement for > some of our APIs. > > Thanks, > George > > Leah Culver wrote: > >> One issue with dropping client credentials may be that it's more difficult >> for providers to identify the client. >> >> For example, Twitter might be using the client credentials to add "from >> Tweetie" to their tweet meta data. This is just an example, I have no idea >> if this is how Twitter identifies clients. >> >> Do any providers have a problem with this? Is there another way to >> identify clients? Should the client information be saved server-side with >> the token data for future reference? >> >> I'm okay with dropping the client credentials but I'd like to make sure we >> still address this use case via other mechanisms. >> >> Thanks! >> Leah >> >> >> On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav > eran@hueniverse.com>> wrote: >> >> We seem to have consensus around dropping the client credentials >> from protected resource requests, using only the token (with >> optional secret or key) to authenticate the request. This means >> clients will be free to share tokens with other clients without >> the server being able to authenticate the client. >> >> Client authentication is already a problematic feature in 1.0 as >> it only works for web-based applications capable of keeping the >> client credentials secret. WRAP dropped it to support crypto-free >> client experience. It is currently optional in 1.0. >> >> I would very much like us to drop client credentials from >> protected resources requests, but want to make sure people are >> aware of the consequences. I plan to drop it in my first draft of >> the Token scheme. >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64ddb7edc61d80479c219ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that a client id is orthogonal to replay attacks -- if I can see a = client ID, why can't I copy it as easily as I could an opaque token and= replay it?

In other words, yes I agree that replay is a= concern given other proposals, but I don't see how this proposal itsel= f changes the story. =A0(And I believe the replay concern is mitigated suff= iciently by the other arguments on the other threads.)

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Wed, Dec 2, 2009 at 9:11 AM, George F= letcher <gffletch@= aol.com> wrote:
I'm more concerned with replay than the ability to identify the client.= Basically, dropping this requirement means that the short lived bearer tok= ens are replay-able not only by the client that received them but also by a= ny one who sees them (hence the need for SSL in WRAP).

Other mechanisms can be employed to identify the "client" (i.e. m= utual TLS) but they require rather closed deployment models. However, that = may be OK for those cases where this is required.

This doesn't solve the twitter/tweetie case. Though I'm not sure ho= w well the current solution solves it either (meaning it's probably pre= tty easy for someone to extract the consumer token and secret from tweetie = source code). Note that twitter could modify their API to provide this capa= bility if critical to their model.

I do think that a signing profile should be supported, in addition to the b= earer token model, for those cases that care about replay and some assuranc= e that the entity that received the token (from the token issuer) is the en= tity presenting the access_token. This doesn't directly identify the cl= ient but does constrain replay scope. This is a critical requirement for so= me of our APIs.

Thanks,
George

Leah Culver wrote:
One issue with dropping client credentials may be that it's more diffic= ult for providers to identify the client.

For example, Twitter might be using the client credentials to add "fro= m Tweetie" to their tweet meta data. This is just an example, I have n= o idea if this is how Twitter identifies clients.

Do any providers have a problem with this? Is there another way to identify= clients? Should the client information be saved server-side with the token= data for future reference?

I'm okay with dropping the client credentials but I'd like to make = sure we still address this use case via other mechanisms.

Thanks!
Leah


On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav <eran@hueniverse.com <mailto:eran@hueniverse.com>> wrote:

=A0 =A0We seem to have consensus around dropping the client credentials =A0 =A0from protected resource requests, using only the token (with
=A0 =A0optional secret or key) to authenticate the request. This means
=A0 =A0clients will be free to share tokens with other clients without
=A0 =A0the server being able to authenticate the client.

=A0 =A0Client authentication is already a problematic feature in 1.0 as =A0 =A0it only works for web-based applications capable of keeping the
=A0 =A0client credentials secret. WRAP dropped it to support crypto-free =A0 =A0client experience. It is currently optional in 1.0.

=A0 =A0I would very much like us to drop client credentials from
=A0 =A0protected resources requests, but want to make sure people are
=A0 =A0aware of the consequences. I plan to drop it in my first draft of =A0 =A0the Token scheme.

=A0 =A0EHL
=A0 =A0_______________________________________________
=A0 =A0OAuth mailing list
=A0 =A0OAuth@ietf.org<= /a> <mailto:OAuth@ie= tf.org>

=A0 =A0https://www.ietf.org/mailman/listinfo/oauth


------------------------------------------------------------------------

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth
=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e64ddb7edc61d80479c219ba-- From jpanzer@google.com Wed Dec 2 09:49:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1863A69FD for ; Wed, 2 Dec 2009 09:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjVzhgTaXREU for ; Wed, 2 Dec 2009 09:49:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 554493A695F for ; Wed, 2 Dec 2009 09:49:54 -0800 (PST) Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id nB2HnjjV005501 for ; Wed, 2 Dec 2009 09:49:45 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259776185; bh=Yxg9imQdB9YRrnWc6lG0PCT32jU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Hr+c0llLqKrWvFisnAn9xWbl6vN1qvlD13jsKI9X70SO9Layv2B7pB/BdEIPHhQwR RjBT/cSr+ph7CQMaSU9YQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=I+XjiBWoHzXkmiekgiyIJqLydsmuVZOY4SWJ2NQV9DN7UfGeRscOxyf9aesqLlmbL 1LSjsgfOZaFihzm1Bm6CA== Received: from pxi33 (pxi33.prod.google.com [10.243.27.33]) by zps77.corp.google.com with ESMTP id nB2Hmdpe012667 for ; Wed, 2 Dec 2009 09:49:43 -0800 Received: by pxi33 with SMTP id 33so313525pxi.10 for ; Wed, 02 Dec 2009 09:49:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.114.11 with SMTP id r11mr145844wam.195.1259776182806; Wed, 02 Dec 2009 09:49:42 -0800 (PST) In-Reply-To: <4B16855C.90209@oracle.com> References: <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1637EB.5080502@cs.tcd.ie> <4B16855C.90209@oracle.com> From: John Panzer Date: Wed, 2 Dec 2009 09:49:21 -0800 Message-ID: To: Prateek Mishra Content-Type: multipart/alternative; boundary=0016e64ee34cdf69ce0479c27fa5 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:49:56 -0000 --0016e64ee34cdf69ce0479c27fa5 Content-Type: text/plain; charset=ISO-8859-1 It requires a security considerations section :). -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Dec 2, 2009 at 7:18 AM, Prateek Mishra wrote: > Stephen, > > +1 from our side. > > Here is a newbie question: does the IETF process require a discussion of > threats and countermeasures > as part of the specification? - explaining the specific situations that > rely on SSL or signing and what the consequences > of "turning it off" might be... > > - prateek > > I think we'll need an analysis of where we end up wanting TLS >> for the protocols we produce. I wouldn't expect any big >> surprises, but right now I don't think we can be sure since >> things seems to be in flux to some extent. >> >> Then, I'd be for saying that TLS MUST be used for those operations. >> However, I can well believe that there may be some niches where >> using TLS isn't easy, so I could live with something like: it MUST >> be possible to use TLS, and that deployments SHOULD use it, with >> guidance as to the type of scenario where we think TLS really >> has to be turned on, and maybe text about why sometimes people >> can't do that. >> >> So I don't think we can finish this discussion at this stage. >> >> S. >> >> Eran Hammer-Lahav wrote: >> >> >>> >>> >>> I would like to make an official request to the chair for a consensus >>> call on recommending SSL but keeping it optional in the various OAuth >>> components. We can figure out how strong to make the language (or how >>> scary), and we may make it mandatory in some flows/profiles, but I would >>> like to be done with this discussion (for the n time). >>> >>> If someone will want to raise new arguments, well, this is the IETF so >>> who can stop them? :-) >>> >>> EHL >>> >>> >>> >>>> -----Original Message----- >>>> From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] >>>> Sent: Tuesday, December 01, 2009 9:51 PM >>>> To: Brian Eaton >>>> Cc: Eran Hammer-Lahav; Peter Saint-Andre; ; >>>> Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] why are we signing? >>>> >>>> >>>> On 2009-12-01, at 5:46 PM, Brian Eaton wrote: >>>> >>>> >>>> >>>>> On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav >>>>> >>>>> >>>> wrote: >>>> >>>> >>>>> Getting a Class 1 cert from the likes of StartSSL is easy as pie >>>>>>> these days. IMHO there is no excuse for not deploying SSL if you >>>>>>> care one whit about security. The problem is that too many >>>>>>> small-scale developers (and big companies!) simply don't care. >>>>>>> >>>>>>> >>>>>> Don't care, don't need that much security, don't understand it, etc. >>>>>> >>>>>> >>>>> Bottom line is that requiring SSL is certain to fork this work if not >>>> done right. >>>> >>>> >>>>> Note, however, that someone who can't get SSL working and still >>>>> deploys OAuth has basically no security against eavesdroppers or MITM >>>>> attacks, and certainly can't expect OAuth to provide it. The issues >>>>> are in the token issuance phase: these organizations are sending user >>>>> passwords and session cookies in clear text! OAuth is the least of >>>>> their security concerns, >>>>> >>>>> >>>> If the cost of SSL outweighs the risk of a security breach, then why >>>> would a >>>> developer deploying OAuth choose to sign their messages rather then use >>>> the simpler bearer token? >>>> >>>> Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think >>>> that is a good question. Perhaps it should be RECOMMENDED, and >>>> deployments can make their own benefit analysis. >>>> >>>> -- Dick >>>> >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64ee34cdf69ce0479c27fa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It requires a security considerations section :).
--
Jo= hn Panzer / Google
jpanzer@google.= com / abstractioneer.org / @j= panzer



On Wed, Dec 2, 2009 at 7:18 AM, Prateek = Mishra <p= rateek.mishra@oracle.com> wrote:
Stephen,

+1 from our side.

Here is a newbie question: does the IETF process require a discussion of th= reats and countermeasures
as part of the specification? - explaining the specific situations that rel= y on SSL or signing and what the consequences
of "turning it off" might be...

- prateek

I think we'll need an analysis of where we end up wanting TLS
for the protocols we produce. I wouldn't expect any big
surprises, but right now I don't think we can be sure since
things seems to be in flux to some extent.

Then, I'd be for saying that TLS MUST be used for those operations.
However, I can well believe that there may be some niches where
using TLS isn't easy, so I could live with something like: it MUST
be possible to use TLS, and that deployments SHOULD use it, with
guidance as to the type of scenario where we think TLS really
has to be turned on, and maybe text about why sometimes people
can't do that.

So I don't think we can finish this discussion at this stage.

S.

Eran Hammer-Lahav wrote:
=A0
<smiling but not joking>

I would like to make an official request to the chair for a consensus call = on recommending SSL but keeping it optional in the various OAuth components= . We can figure out how strong to make the language (or how scary), and we = may make it mandatory in some flows/profiles, but I would like to be done w= ith this discussion (for the n time).

If someone will want to raise new arguments, well, this is the IETF so who = can stop them? :-)

EHL

=A0 =A0
-----Original Message-----
From: Dick Hardt [mailto:Dick.Hardt@microsoft.com]
Sent: Tuesday, December 01, 2009 9:51 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; Peter Saint-Andre; <ext@core3.amsl.com>;
Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org
Subject: Re: [OAUTH-WG] why are we signing?


On 2009-12-01, at 5:46 PM, Brian Eaton wrote:

=A0 =A0 =A0
On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav
=A0 =A0 =A0 =A0
<eran@huenivers= e.com> wrote:
=A0 =A0 =A0
Getting a Class 1 cert from the likes of StartSSL is easy as pie
these days. IMHO there is no excuse for not deploying SSL if you
care one whit about security. The problem is that too many
small-scale developers (and big companies!) simply don't care.
=A0 =A0 =A0 =A0 =A0 =A0
Don't care, don't need that much security, don't understand it,= etc.
=A0 =A0 =A0 =A0 =A0
Bottom line is that requiring SSL is certain to fork this work if not done = right.
=A0 =A0 =A0
Note, however, that someone who can't get SSL working and still
deploys OAuth has basically no security against eavesdroppers or MITM
attacks, and certainly can't expect OAuth to provide it. =A0The issues<= br> are in the token issuance phase: these organizations are sending user
passwords and session cookies in clear text! =A0OAuth is the least of
their security concerns,
=A0 =A0 =A0 =A0
If the cost of SSL outweighs the risk of a security breach, then why would = a
developer deploying OAuth choose to sign their messages rather then use
the simpler bearer token?

Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think that is a good question. Perhaps it should be RECOMMENDED, and
deployments can make their own benefit analysis.

-- Dick
=A0 =A0 =A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0 =A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e64ee34cdf69ce0479c27fa5-- From GFFletch@aol.com Wed Dec 2 10:06:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02BF73A6912 for ; Wed, 2 Dec 2009 10:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOgUkRnPRS1e for ; Wed, 2 Dec 2009 10:06:45 -0800 (PST) Received: from imr-ma05.mx.aol.com (imr-ma05.mx.aol.com [64.12.100.31]) by core3.amsl.com (Postfix) with ESMTP id 836243A6927 for ; Wed, 2 Dec 2009 10:06:45 -0800 (PST) Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imr-ma05.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB2I6KfF015906; Wed, 2 Dec 2009 13:06:20 -0500 Received: from GFFletch@aol.com by imo-da01.mx.aol.com (mail_out_v42.5.) id y.c12.698afd31 (34970); Wed, 2 Dec 2009 13:06:16 -0500 (EST) Received: from palantir.local ([10.181.87.216]) by cia-da07.mx.aol.com (v126.13) with ESMTP id MAILCIADA077-889a4b16ac9820c; Wed, 02 Dec 2009 13:06:16 -0500 Message-ID: <4B16AC98.7000406@aol.com> Date: Wed, 02 Dec 2009 13:06:16 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: John Panzer References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> <4B169FCB.2010908@aol.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.181.87.216 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 18:06:47 -0000 John Panzer wrote: > I think that a client id is orthogonal to replay attacks -- if I can > see a client ID, why can't I copy it as easily as I could an opaque > token and replay it? You are correct that client id/secret is orthogonal to replay attacks as in the current spec there is nothing that requires the access_token to be bound to the consumer token (though there is nothing stopping a provider from doing this). So a tight coupling is possible in the current spec though I don't know of anyone doing so. It's not the id that protects replay scope but rather the secret (which of course is relatively easily discovered in client code) that proves the "client" can present that client id. As Ethan pointed out, if a client wants to share it can, so removing the requirement and making it optional makes those sharing cases easier. So +1 to not making it mandatory. > > In other words, yes I agree that replay is a concern given other > proposals, but I don't see how this proposal itself changes the story. > (And I believe the replay concern is mitigated sufficiently by the > other arguments on the other threads.) I'm still not convinced that SSL + short-lived bearer tokens solve the replay "risk" problem. Thanks, George > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org > / @jpanzer > > > > On Wed, Dec 2, 2009 at 9:11 AM, George Fletcher > wrote: > > I'm more concerned with replay than the ability to identify the > client. Basically, dropping this requirement means that the short > lived bearer tokens are replay-able not only by the client that > received them but also by any one who sees them (hence the need > for SSL in WRAP). > > Other mechanisms can be employed to identify the "client" (i.e. > mutual TLS) but they require rather closed deployment models. > However, that may be OK for those cases where this is required. > > This doesn't solve the twitter/tweetie case. Though I'm not sure > how well the current solution solves it either (meaning it's > probably pretty easy for someone to extract the consumer token and > secret from tweetie source code). Note that twitter could modify > their API to provide this capability if critical to their model. > > I do think that a signing profile should be supported, in addition > to the bearer token model, for those cases that care about replay > and some assurance that the entity that received the token (from > the token issuer) is the entity presenting the access_token. This > doesn't directly identify the client but does constrain replay > scope. This is a critical requirement for some of our APIs. > > Thanks, > George > > Leah Culver wrote: > > One issue with dropping client credentials may be that it's > more difficult for providers to identify the client. > > For example, Twitter might be using the client credentials to > add "from Tweetie" to their tweet meta data. This is just an > example, I have no idea if this is how Twitter identifies clients. > > Do any providers have a problem with this? Is there another > way to identify clients? Should the client information be > saved server-side with the token data for future reference? > > I'm okay with dropping the client credentials but I'd like to > make sure we still address this use case via other mechanisms. > > Thanks! > Leah > > > On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav > > >> wrote: > > We seem to have consensus around dropping the client > credentials > from protected resource requests, using only the token (with > optional secret or key) to authenticate the request. This means > clients will be free to share tokens with other clients without > the server being able to authenticate the client. > > Client authentication is already a problematic feature in > 1.0 as > it only works for web-based applications capable of keeping the > client credentials secret. WRAP dropped it to support > crypto-free > client experience. It is currently optional in 1.0. > > I would very much like us to drop client credentials from > protected resources requests, but want to make sure people are > aware of the consequences. I plan to drop it in my first > draft of > the Token scheme. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Wed Dec 2 10:19:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0563A68E6 for ; Wed, 2 Dec 2009 10:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYRyDB6LT9wC for ; Wed, 2 Dec 2009 10:19:07 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id F2EA33A6359 for ; Wed, 2 Dec 2009 10:19:06 -0800 (PST) Received: (qmail 8301 invoked from network); 2 Dec 2009 18:18:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 18:18:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Dec 2009 11:18:58 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Wed, 2 Dec 2009 11:19:09 -0700 Thread-Topic: [OAUTH-WG] Remove client credentials from protected resource requests Thread-Index: Acpzc4K1XREHgWYcQ9K8pS1rMOxjFAABwaDA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A202@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9184e2a80912020846v9a83b20xcd12559cb6683096@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 18:19:08 -0000 > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Wednesday, December 02, 2009 9:18 AM =20 > 1. It is always possible to embed or reference a client ID in the opaque = token > sent along with the request, so no fundamental functionality is lost -- s= ervers > can always recover the data needed to add "from Tweetie"; Yep. The server is free to encode whatever it wants inside the token or in = its database with a token lookup. This works for both opaque and structured= tokens, as well as server-issued or otherwise (which is outside the scope)= . > 2. It simplifies accessing the protected resource; It is required to support the plain bearer token use case which has been th= e most sought after feature lately. > 3. (Speculative) I think it simplifies possible > extensions to allow for controlled sub-delegation from one client to anot= her. This is not a requirement and while it does make it easier, clients are fre= e (technically) to share tokens as well as their client credentials with ot= hers. This just makes it less offensive. =20 > On Wed, Dec 2, 2009 at 8:46 AM, Leah Culver > wrote: > One issue with dropping client credentials may be that it's more difficul= t for > providers to identify the client. It might not even be more work since the server can embed the client identi= ty in the token and would save itself another database look up for the clie= nt credentials. The server always knows who it issued a token to in the fir= st place. In addition, the Twitter example is useful to demonstrate an API = where a large number of applications are desktop which means the client cre= dentials can be considered a hint at best. > -----Original Message----- > From: George Fletcher [mailto:gffletch@aol.com] > Sent: Wednesday, December 02, 2009 9:12 AM > I'm more concerned with replay than the ability to identify the client. > Basically, dropping this requirement means that the short lived bearer to= kens > are replay-able not only by the client that received them but also by any= one > who sees them (hence the need for SSL in WRAP). Requiring client credentials with a bearer token request misses the point a= nyway since the appeal of a bearer token is lack of crypto. > Other mechanisms can be employed to identify the "client" (i.e. mutual > TLS) but they require rather closed deployment models. However, that may > be OK for those cases where this is required. The client is still being identified when requesting a token. This is about= being able to "ensure" that the client making the request is the same clie= nt who received the token. Of course, if the client shares its credentials,= the whole assumption is broken. > This doesn't solve the twitter/tweetie case. Though I'm not sure how well > the current solution solves it either (meaning it's probably pretty easy = for > someone to extract the consumer token and secret from tweetie source > code). Note that twitter could modify their API to provide this capabilit= y if > critical to their model. No. They just need to store client information as part of their token recor= ds. > I do think that a signing profile should be supported, in addition to the= bearer > token model, for those cases that care about replay and some assurance th= at > the entity that received the token (from the token > issuer) is the entity presenting the access_token. This doesn't directly > identify the client but does constrain replay scope. This is a critical > requirement for some of our APIs. This has nothing to do with the question... which was, is a single set of c= redentials (token) enough. Whether those credentials include a secret or ke= y is another matter. EHL From eran@hueniverse.com Wed Dec 2 10:19:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5109E3A6359 for ; Wed, 2 Dec 2009 10:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3W38Z8HWC++M for ; Wed, 2 Dec 2009 10:19:37 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E6B5C3A68C1 for ; Wed, 2 Dec 2009 10:19:36 -0800 (PST) Received: (qmail 947 invoked from network); 2 Dec 2009 18:19:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 18:19:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Dec 2009 11:19:27 -0700 From: Eran Hammer-Lahav To: John Panzer , Prateek Mishra Date: Wed, 2 Dec 2009 11:19:38 -0700 Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: Acpzd9lU/sD+LKvUQhOn0+DpNqexCQABCBmA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A203@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1637EB.5080502@cs.tcd.ie> <4B16855C.90209@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234378520A203P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 18:19:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234378520A203P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And we are always looking for people to write those... EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ohn Panzer Sent: Wednesday, December 02, 2009 9:49 AM To: Prateek Mishra Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? It requires a security considerations section :). -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Dec 2, 2009 at 7:18 AM, Prateek Mishra > wrote: Stephen, +1 from our side. Here is a newbie question: does the IETF process require a discussion of th= reats and countermeasures as part of the specification? - explaining the specific situations that rel= y on SSL or signing and what the consequences of "turning it off" might be... - prateek I think we'll need an analysis of where we end up wanting TLS for the protocols we produce. I wouldn't expect any big surprises, but right now I don't think we can be sure since things seems to be in flux to some extent. Then, I'd be for saying that TLS MUST be used for those operations. However, I can well believe that there may be some niches where using TLS isn't easy, so I could live with something like: it MUST be possible to use TLS, and that deployments SHOULD use it, with guidance as to the type of scenario where we think TLS really has to be turned on, and maybe text about why sometimes people can't do that. So I don't think we can finish this discussion at this stage. S. Eran Hammer-Lahav wrote: I would like to make an official request to the chair for a consensus call = on recommending SSL but keeping it optional in the various OAuth components= . We can figure out how strong to make the language (or how scary), and we = may make it mandatory in some flows/profiles, but I would like to be done w= ith this discussion (for the n time). If someone will want to raise new arguments, well, this is the IETF so who = can stop them? :-) EHL -----Original Message----- From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] Sent: Tuesday, December 01, 2009 9:51 PM To: Brian Eaton Cc: Eran Hammer-Lahav; Peter Saint-Andre; >; Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org Subject: Re: [OAUTH-WG] why are we signing? On 2009-12-01, at 5:46 PM, Brian Eaton wrote: On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav > wrote: Getting a Class 1 cert from the likes of StartSSL is easy as pie these days. IMHO there is no excuse for not deploying SSL if you care one whit about security. The problem is that too many small-scale developers (and big companies!) simply don't care. Don't care, don't need that much security, don't understand it, etc. Bottom line is that requiring SSL is certain to fork this work if not done = right. Note, however, that someone who can't get SSL working and still deploys OAuth has basically no security against eavesdroppers or MITM attacks, and certainly can't expect OAuth to provide it. The issues are in the token issuance phase: these organizations are sending user passwords and session cookies in clear text! OAuth is the least of their security concerns, If the cost of SSL outweighs the risk of a security breach, then why would = a developer deploying OAuth choose to sign their messages rather then use the simpler bearer token? Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I think that is a good question. Perhaps it should be RECOMMENDED, and deployments can make their own benefit analysis. -- Dick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E7234378520A203P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And we ar= e always looking for people to write those…

 

EHL

 =

From: oauth-bounces@ietf= .org [mailto:oauth-bounces@ietf.org] On Behalf Of John Panzer
= Sent: Wednesday, December 02, 2009 9:49 AM
To: Prateek Mishra=
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] why are we = signing?

 <= /o:p>

It requires a = security considerations section :).
--
John Panzer / Goog= le
jpanzer@google.com / abstractioneer.org / @jpanzer

On Wed, Dec 2, 2009 at 7:18 AM, = Prateek Mishra <prateek.mis= hra@oracle.com> wrote:

Stephen,
+1 from our side.

Here is a newbie question: does the IETF pro= cess require a discussion of threats and countermeasures
as part of the = specification? - explaining the specific situations that rely on SSL or sig= ning and what the consequences
of "turning it off" might be...=

- prateek

<= div>

 

I think we'll need an analysis = of where we end up wanting TLS
for the protocols we produce. I wouldn't = expect any big
surprises, but right now I don't think we can be sure sin= ce
things seems to be in flux to some extent.

Then, I'd be for sa= ying that TLS MUST be used for those operations.
However, I can well bel= ieve that there may be some niches where
using TLS isn't easy, so I coul= d live with something like: it MUST
be possible to use TLS, and that dep= loyments SHOULD use it, with
guidance as to the type of scenario where w= e think TLS really
has to be turned on, and maybe text about why sometim= es people
can't do that.

So I don't think we can finish this disc= ussion at this stage.

S.

Eran Hammer-Lahav wrote:
 

<smiling but not joking>

I w= ould like to make an official request to the chair for a consensus call on = recommending SSL but keeping it optional in the various OAuth components. W= e can figure out how strong to make the language (or how scary), and we may= make it mandatory in some flows/profiles, but I would like to be done with= this discussion (for the n time).

If someone will want to raise new= arguments, well, this is the IETF so who can stop them? :-)

EHL
=
   

-----Original Message-= ----
From: Dick Hardt [mailto:Dick.Hardt@microsoft.com]
Sent: Tuesday, Decembe= r 01, 2009 9:51 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; Peter Saint= -Andre; <ext@cor= e3.amsl.com>;
Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org
Subject: Re: [O= AUTH-WG] why are we signing?


On 2009-12-01, at 5:46 PM, Brian Ea= ton wrote:

     

O= n Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav
      &n= bsp;

<eran@hueniverse.com> wrote:
  &nbs= p;  

G= etting a Class 1 cert from the likes of StartSSL is easy as pie
these da= ys. IMHO there is no excuse for not deploying SSL if you
care one whit a= bout security. The problem is that too many
small-scale developers (and = big companies!) simply don't care.
          &n= bsp;

Don't care, don't need= that much security, don't understand it, etc.
      &nbs= p;  

Bottom line is th= at requiring SSL is certain to fork this work if not done right.
  =    

Note, however, that someon= e who can't get SSL working and still
deploys OAuth has basically no sec= urity against eavesdroppers or MITM
attacks, and certainly can't expect = OAuth to provide it.  The issues
are in the token issuance phase: t= hese organizations are sending user
passwords and session cookies in cle= ar text!  OAuth is the least of
their security concerns,
  =      

If the cost of SSL = outweighs the risk of a security breach, then why would a
developer depl= oying OAuth choose to sign their messages rather then use
the simpler be= arer token?

Peter Saint-Andre questioned why SSL was required in OAu= th WRAP. I think
that is a good question. Perhaps it should be RECOMMEND= ED, and
deployments can make their own benefit analysis.

-- Dick<= br>     

________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth

   

_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

___________________________________= ____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234378520A203P3PW5EX1MB01E_-- From mjmalone@gmail.com Wed Dec 2 11:30:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8B53A6AC8 for ; Wed, 2 Dec 2009 11:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0DFNzZHU7cr for ; Wed, 2 Dec 2009 11:30:20 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id C81743A68D9 for ; Wed, 2 Dec 2009 11:30:19 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so99415qwb.31 for ; Wed, 02 Dec 2009 11:30:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=1JPjvohwx4caQ8WX0X+ODvaxoMU3xIsnQp5KMx0Sf+I=; b=niyRVrpO3D1QzpXwlxU9rsm4EqBxP2CA5eI10vu/0Zt56y0pB485tZ1sxB38kBHQK4 hW+hfv7vYaYHYGk+QcgW9OIZpAgL6dPOuEj5Sw/CxlFi/caQXp9AJoyc78Z07dkFUSwR luTAdm3V6fO1iuwnApmokDTdMMGLx9Q5Y3LKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=AeNLwxS2bFnDl+nA92rF6yvQT95a30eWsbnOVfmOs7Ng72/+l6VFySDEHYi9q3HkLa d1wOiCMIzpmAQUbveX8N5FCD1oNBI3K7oJxtBGcsiw6sA8tutmWq8w0FCyzc2JZs0SRu +dF+/jEM6SdBVq2Oo591QkoWXzlOgJoORwCL8= MIME-Version: 1.0 Received: by 10.229.28.16 with SMTP id k16mr76826qcc.70.1259782209066; Wed, 02 Dec 2009 11:30:09 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Mike Malone Date: Wed, 2 Dec 2009 11:29:49 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:30:21 -0000 I'm +1 on this proposal too. Sounds like most of the relevant points have been made, but I'll reiterate that I think the bearer token should be sufficient for authentication, and I think it will simplify delegation significantly. You're talking about dropping the key/secret. Does that mean we'd be moving to a WRAP-like model that uses SSL? Without signing, the bearer token becomes as good as a username/password. If there's no secret/signature then all of the relevant info for forging a request is sent along with every legitimate request. Am I missing something? Mike On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav wro= te: > We seem to have consensus around dropping the client credentials from pro= tected resource requests, using only the token (with optional secret or key= ) to authenticate the request. This means clients will be free to share tok= ens with other clients without the server being able to authenticate the cl= ient. > > Client authentication is already a problematic feature in 1.0 as it only = works for web-based applications capable of keeping the client credentials = secret. WRAP dropped it to support crypto-free client experience. It is cur= rently optional in 1.0. > > I would very much like us to drop client credentials from protected resou= rces requests, but want to make sure people are aware of the consequences. = I plan to drop it in my first draft of the Token scheme. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jpanzer@google.com Wed Dec 2 11:37:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157BF3A6ACB for ; Wed, 2 Dec 2009 11:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.951 X-Spam-Level: X-Spam-Status: No, score=-105.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnQaKon+qyeO for ; Wed, 2 Dec 2009 11:37:33 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 84BA63A6B05 for ; Wed, 2 Dec 2009 11:37:32 -0800 (PST) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id nB2JbM7W016533 for ; Wed, 2 Dec 2009 19:37:22 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259782643; bh=sE0Uue4ThlZq3CTlAu13XT/Yboo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=xcoJumZL6gqyXjLowBlM1fLAHhc6U2ygwx8J3M1HNGXOG37bJ2MWByb6+Jw226ig9 p/bNx1r9SiBJ9eiBCloCw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Nw/koG2o0Y3ygWmyb42stnhJTHZdru+k5NVLswfM1Mk6IxxAxi5/g4FliDAVCzh6d 9HZ++zFKcWa7kQ+DB0snA== Received: from pzk42 (pzk42.prod.google.com [10.243.19.170]) by zps38.corp.google.com with ESMTP id nB2JaKQn026869 for ; Wed, 2 Dec 2009 11:37:19 -0800 Received: by pzk42 with SMTP id 42so443903pzk.31 for ; Wed, 02 Dec 2009 11:37:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.187.30 with SMTP id k30mr1113930waf.10.1259782639555; Wed, 02 Dec 2009 11:37:19 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Wed, 2 Dec 2009 11:36:59 -0800 Message-ID: To: Mike Malone Content-Type: multipart/alternative; boundary=0016e64cd744b999330479c4003e X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:37:34 -0000 --0016e64cd744b999330479c4003e Content-Type: text/plain; charset=ISO-8859-1 Not to extend this thread without necessity (I'm still +1 on the proposal for someone scanning): On Wed, Dec 2, 2009 at 11:29 AM, Mike Malone wrote: > I'm +1 on this proposal too. Sounds like most of the relevant points > have been made, but I'll reiterate that I think the bearer token > should be sufficient for authentication, and I think it will simplify > delegation significantly. > > You're talking about dropping the key/secret. Does that mean we'd be > moving to a WRAP-like model that uses SSL? Without signing, the bearer > token becomes as good as a username/password. It's actually strictly better than username/password, albeit not quite as good as TLS: (a) It can be rotated without user involvement or pain, even every few minutes, mitigating many attacks. (b) It can be guaranteed not to be the same as the secret used for unrelated services, which is a huge problem for passwords even if they're secure (your password is only as secure as the _least_ secure service you use it on, and regular users re-use passwords everywhere). (c) The token can be capability-limited so as to mitigate damage of leaking; e.g., I personally would nearly rather that Mint only had a token granting read-only access to my financial information, even if not sent over SSL, than having all of the usernames and passwords for all of my financial institutions, even if they're sent over SSL. > If there's no > secret/signature then all of the relevant info for forging a request > is sent along with every legitimate request. Am I missing something? > > Mike > > On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav > wrote: > > We seem to have consensus around dropping the client credentials from > protected resource requests, using only the token (with optional secret or > key) to authenticate the request. This means clients will be free to share > tokens with other clients without the server being able to authenticate the > client. > > > > Client authentication is already a problematic feature in 1.0 as it only > works for web-based applications capable of keeping the client credentials > secret. WRAP dropped it to support crypto-free client experience. It is > currently optional in 1.0. > > > > I would very much like us to drop client credentials from protected > resources requests, but want to make sure people are aware of the > consequences. I plan to drop it in my first draft of the Token scheme. > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64cd744b999330479c4003e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not to extend this thread without necessity (I'm still +1 on the propos= al for someone scanning):

On Wed, Dec 2, = 2009 at 11:29 AM, Mike Malone <mjmalone@gmail.com> wrote:
I'm +1 on this proposal too. Sounds lik= e most of the relevant points
have been made, but I'll reiterate that I think the bearer token
should be sufficient for authentication, and I think it will simplify
delegation significantly.

You're talking about dropping the key/secret. Does that mean we'd b= e
moving to a WRAP-like model that uses SSL? Without signing, the bearer
token becomes as good as a username/password.

It's actually strictly better than username/password, albeit not qui= te as good as TLS:

(a) It can be rotated without u= ser involvement or pain, even every few minutes, mitigating many attacks.
(b) It can be guaranteed not to be the same as the secret used for unr= elated services, which is a huge problem for passwords even if they're = secure (your password is only as secure as the _least_ secure service you u= se it on, and regular users re-use passwords everywhere).
(c) The token can be capability-limited so as to mitigate damage of le= aking; e.g., I personally would nearly rather that Mint only had a token gr= anting read-only access to my financial information, even if not sent over = SSL, than having all of the usernames and passwords for all of my financial= institutions, even if they're sent over SSL.

=A0
If there'= s no
secret/signature then all of the relevant info for forging a request
is sent along with every legitimate request. Am I missing something?

Mike

On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> We seem to have consensus around dropping the client credentials from = protected resource requests, using only the token (with optional secret or = key) to authenticate the request. This means clients will be free to share = tokens with other clients without the server being able to authenticate the= client.
>
> Client authentication is already a problematic feature in 1.0 as it on= ly works for web-based applications capable of keeping the client credentia= ls secret. WRAP dropped it to support crypto-free client experience. It is = currently optional in 1.0.
>
> I would very much like us to drop client credentials from protected re= sources requests, but want to make sure people are aware of the consequence= s. I plan to drop it in my first draft of the Token scheme.
>
> EHL
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e64cd744b999330479c4003e-- From rbarnes@bbn.com Wed Dec 2 11:39:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2453A6AEB for ; Wed, 2 Dec 2009 11:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCXxlKqTf4bF for ; Wed, 2 Dec 2009 11:39:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 474563A6403 for ; Wed, 2 Dec 2009 11:39:51 -0800 (PST) Received: from [128.89.253.85] (helo=[10.1.2.164]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NFv37-0006Iy-Cf; Wed, 02 Dec 2009 14:39:42 -0500 Message-Id: From: Richard Barnes To: John Panzer In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3-155222020 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Dec 2009 09:39:39 -1000 References: <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1637EB.5080502@cs.tcd.ie> <4B16855C.90209@oracle.com> X-Mailer: Apple Mail (2.936) Cc: "oauth@ietf.org" , Prateek Mishra Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:39:52 -0000 --Apple-Mail-3-155222020 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Right. Generally the expectation is that the Security Considerations section will discuss what the threats are against the protocol in question, how security features mitigate those threats, and what the risks are of not using those features. At least that's what I look for when I do a SECDIR review :) The authoritative guide is RFC 3552: --Richard On Dec 2, 2009, at 7:49 AM, John Panzer wrote: > It requires a security considerations section :). > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > On Wed, Dec 2, 2009 at 7:18 AM, Prateek Mishra > wrote: > Stephen, > > +1 from our side. > > Here is a newbie question: does the IETF process require a > discussion of threats and countermeasures > as part of the specification? - explaining the specific situations > that rely on SSL or signing and what the consequences > of "turning it off" might be... > > - prateek > > I think we'll need an analysis of where we end up wanting TLS > for the protocols we produce. I wouldn't expect any big > surprises, but right now I don't think we can be sure since > things seems to be in flux to some extent. > > Then, I'd be for saying that TLS MUST be used for those operations. > However, I can well believe that there may be some niches where > using TLS isn't easy, so I could live with something like: it MUST > be possible to use TLS, and that deployments SHOULD use it, with > guidance as to the type of scenario where we think TLS really > has to be turned on, and maybe text about why sometimes people > can't do that. > > So I don't think we can finish this discussion at this stage. > > S. > > Eran Hammer-Lahav wrote: > > > > I would like to make an official request to the chair for a > consensus call on recommending SSL but keeping it optional in the > various OAuth components. We can figure out how strong to make the > language (or how scary), and we may make it mandatory in some flows/ > profiles, but I would like to be done with this discussion (for the > n time). > > If someone will want to raise new arguments, well, this is the IETF > so who can stop them? :-) > > EHL > > > -----Original Message----- > From: Dick Hardt [mailto:Dick.Hardt@microsoft.com] > Sent: Tuesday, December 01, 2009 9:51 PM > To: Brian Eaton > Cc: Eran Hammer-Lahav; Peter Saint-Andre; ; > Tschofenig, Hannes (NSN - FI/Espoo); oauth@ietf.org > Subject: Re: [OAUTH-WG] why are we signing? > > > On 2009-12-01, at 5:46 PM, Brian Eaton wrote: > > > On Tue, Dec 1, 2009 at 7:08 PM, Eran Hammer-Lahav > > wrote: > > Getting a Class 1 cert from the likes of StartSSL is easy as pie > these days. IMHO there is no excuse for not deploying SSL if you > care one whit about security. The problem is that too many > small-scale developers (and big companies!) simply don't care. > > Don't care, don't need that much security, don't understand it, etc. > > Bottom line is that requiring SSL is certain to fork this work if > not done right. > > Note, however, that someone who can't get SSL working and still > deploys OAuth has basically no security against eavesdroppers or MITM > attacks, and certainly can't expect OAuth to provide it. The issues > are in the token issuance phase: these organizations are sending user > passwords and session cookies in clear text! OAuth is the least of > their security concerns, > > If the cost of SSL outweighs the risk of a security breach, then why > would a > developer deploying OAuth choose to sign their messages rather then > use > the simpler bearer token? > > Peter Saint-Andre questioned why SSL was required in OAuth WRAP. I > think > that is a good question. Perhaps it should be RECOMMENDED, and > deployments can make their own benefit analysis. > > -- Dick > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3-155222020 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Right.  Generally the = expectation is that the Security Considerations section will discuss = what the threats are against the protocol in question, how security = features mitigate those threats, and what the risks are of not using = those features.  At least that's what I look for when I do a SECDIR = review :)

The authoritative guide is RFC = 3552:

--Richard


On Dec 2, 2009, at 7:49 AM, John Panzer = wrote:

It requires a security considerations section :).
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer
=


On Wed, Dec 2, 2009 at 7:18 AM, = Prateek Mishra <prateek.mishra@oracle.com>= ; wrote:
Stephen,

= +1 from our side.

Here is a newbie question: does the IETF = process require a discussion of threats and countermeasures
as part = of the specification? - explaining the specific situations that rely on = SSL or signing and what the consequences
of "turning it off" might = be...

- = prateek

I think we'll need an analysis of where we end = up wanting TLS
for the protocols we produce. I wouldn't expect any = big
surprises, but right now I don't think we can be sure since
= things seems to be in flux to some extent.

Then, I'd be for = saying that TLS MUST be used for those operations.
However, I can = well believe that there may be some niches where
using TLS isn't = easy, so I could live with something like: it MUST
be possible to = use TLS, and that deployments SHOULD use it, with
guidance as to the = type of scenario where we think TLS really
has to be turned on, and = maybe text about why sometimes people
can't do that.

So I = don't think we can finish this discussion at this stage.

S.
=
Eran Hammer-Lahav wrote:
 
<smiling but not joking>

I would = like to make an official request to the chair for a consensus call on = recommending SSL but keeping it optional in the various OAuth = components. We can figure out how strong to make the language (or how = scary), and we may make it mandatory in some flows/profiles, but I would = like to be done with this discussion (for the n time).

If = someone will want to raise new arguments, well, this is the IETF so who = can stop them? :-)

EHL

   
-----Original Message-----
From: Dick Hardt = [mailto:Dick.Hardt@microsoft.com]
Sent: Tuesday, = December 01, 2009 9:51 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; = Peter Saint-Andre; <ext@core3.amsl.com>;
Tschofenig, Hannes = (NSN - FI/Espoo); oauth@ietf.org
Subject: Re: [OAUTH-WG] why are = we signing?


On 2009-12-01, at 5:46 PM, Brian Eaton = wrote:

     
On Tue, Dec 1, 2009 at 7:08 PM, Eran = Hammer-Lahav
       
<eran@hueniverse.com> wrote:
    =  
= Getting a Class 1 cert from the likes of StartSSL is easy as pie
= these days. IMHO there is no excuse for not deploying SSL if you
= care one whit about security. The problem is that too many
= small-scale developers (and big companies!) simply don't care.
=            
Don't care, = don't need that much security, don't understand it, etc.
  =        
Bottom line = is that requiring SSL is certain to fork this work if not done = right.
     
= Note, however, that someone who can't get SSL working and still
= deploys OAuth has basically no security against eavesdroppers or = MITM
attacks, and certainly can't expect OAuth to provide it. =  The issues
are in the token issuance phase: these = organizations are sending user
passwords and session cookies in = clear text!  OAuth is the least of
their security concerns,
=        
If the cost of SSL = outweighs the risk of a security breach, then why would a
developer = deploying OAuth choose to sign their messages rather then use
the = simpler bearer token?

Peter Saint-Andre questioned why SSL was = required in OAuth WRAP. I think
that is a good question. Perhaps it = should be RECOMMENDED, and
deployments can make their own benefit = analysis.

-- Dick
     
= _______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=
   
= _______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=
 
= _______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=

= _______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail-3-155222020-- From mjmalone@gmail.com Wed Dec 2 11:59:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECC13A6829 for ; Wed, 2 Dec 2009 11:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkUHyoUpBq7m for ; Wed, 2 Dec 2009 11:59:54 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id A46333A6403 for ; Wed, 2 Dec 2009 11:59:54 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so105028qwb.31 for ; Wed, 02 Dec 2009 11:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=GWHEEmFJZw0KXhmluzY0Fi3k1gZkG8xTlMNJFscD9Po=; b=jPb/gQvYBWFIOJ00ao0BMBwRcE9PpU8ZRNDS5SarmLw2pWFw+a+O1WVmfloW09fAuq xMRtxSYuiHaTIQfF1v7ZFRT/YPjdmvJMeiX1+6GvpBMpFRgdxtbUAjv4hJKL7BNAkpkY iLS9EaX2FPRaFF0bzbrZJnqIMFXyuJI8Zr78k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=AT6GMQtucANyrlaBAgxwCo87pfkOVIno9lgP+xqrw2Z7UvBhBYEFBeixv4IkwrM16g g8Y32/ioNnNAw2zolf4LLnJcutCEyVemoEunXq1hlBeGFvwouqn633c/DwyRowwMcUdH ev7DwW5+QMWjD0ryjiYPJRjuuBLjCmyysSxn4= MIME-Version: 1.0 Received: by 10.229.10.13 with SMTP id n13mr76304qcn.103.1259783983107; Wed, 02 Dec 2009 11:59:43 -0800 (PST) In-Reply-To: <4B15D7C2.2070901@stpeter.im> References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> From: Mike Malone Date: Wed, 2 Dec 2009 11:57:42 -0800 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: ext Dick Hardt , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:59:55 -0000 On Tue, Dec 1, 2009 at 6:58 PM, Peter Saint-Andre wrote: > > > On 11/30/09 1:27 PM, Eran Hammer-Lahav wrote: >> OAuth is being proposed as a generally useful method for securing API >> calls. I expect many open source libraries to implement it on the >> server side and use it for blog plugins, widgets, and other highly >> distributed software. If OAuth required the use of TLS, it would >> simply be ignored by all those applications which will likely >> continue using Basic. >> >> With all due respect to big companies, their resources, and ability >> to effortlessly deploy SSL/TLS, it is still an expensive and complex >> process for more developers deploying small scale server components. > > With all due respect, I think it can be harder for big companies to > deploy TLS -- they have a lot more users, need more hardware (special > SSL accelerators and the like), have more layers of employees (so it can > be more difficult to find the person who controls the hostmaster or > whois-listed email address), etc. > > Getting a Class 1 cert from the likes of StartSSL is easy as pie these > days. IMHO there is no excuse for not deploying SSL if you care one whit > about security. The problem is that too many small-scale developers (and > big companies!) simply don't care. I'm far from an expert on TLS/PKI, but here's a thought (and I'm pretty sure this has come up before)... If TLS is simpler than signatures then why not just use PKI for everything. A lot of the problems that have come up with OAuth are solved by PKI - client certs replace tokens, you can delegate authority by creating sub-certificates, the consumer provisioning problem is largely solved, etc. It seems like WRAP is using bits of PKI to solve half of the problem and then re-inventing other bits of PKI for the other half. If TLS/PKI is the solution, why not go whole hog? Mike From jpanzer@google.com Wed Dec 2 12:27:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF943A657C for ; Wed, 2 Dec 2009 12:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.952 X-Spam-Level: X-Spam-Status: No, score=-105.952 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyTHnLyeRkED for ; Wed, 2 Dec 2009 12:27:37 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 39A0B3A692A for ; Wed, 2 Dec 2009 12:27:37 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id nB2KRR7X012310 for ; Wed, 2 Dec 2009 20:27:28 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259785648; bh=suipGbfolCErOBfT7JiJkvsBIuc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=EBCAHa3n7hTlvtOl4qiCgEXA9Q2M5zvY4iFvqFSMCxPGThwD0MhO0RCiHVDkjs61P 8t2i3CRJkes8tIPRqCZ+A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Esz7lIxE+CDbya7Y/S8YitYqvUwexQMcJvqRhYyf0UbZlRLg5iPPNzGxLzxgWJqVT 70P8k1Jc9UEOi8XpRAiaA== Received: from pzk38 (pzk38.prod.google.com [10.243.19.166]) by wpaz5.hot.corp.google.com with ESMTP id nB2KROBL024997 for ; Wed, 2 Dec 2009 12:27:24 -0800 Received: by pzk38 with SMTP id 38so475305pzk.9 for ; Wed, 02 Dec 2009 12:27:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.165.15 with SMTP id n15mr1152211wae.83.1259785643679; Wed, 02 Dec 2009 12:27:23 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> From: John Panzer Date: Wed, 2 Dec 2009 12:27:03 -0800 Message-ID: To: Mike Malone Content-Type: multipart/alternative; boundary=0016367f92a7c8e16a0479c4b328 X-System-Of-Record: true Cc: ext Dick Hardt , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 20:27:38 -0000 --0016367f92a7c8e16a0479c4b328 Content-Type: text/plain; charset=ISO-8859-1 I think there are multiple positions here. Just to be clear, my position is: A combination of optional TLS, required bearer tokens, and optional token rotation (refresh) is sufficiently secure and deployable. I believe that mandatory TLS would unacceptably reduce deployability (and mandatory dependence on certificate chains more so). -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Wed, Dec 2, 2009 at 11:57 AM, Mike Malone wrote: > On Tue, Dec 1, 2009 at 6:58 PM, Peter Saint-Andre > wrote: > > > > > > On 11/30/09 1:27 PM, Eran Hammer-Lahav wrote: > >> OAuth is being proposed as a generally useful method for securing API > >> calls. I expect many open source libraries to implement it on the > >> server side and use it for blog plugins, widgets, and other highly > >> distributed software. If OAuth required the use of TLS, it would > >> simply be ignored by all those applications which will likely > >> continue using Basic. > >> > >> With all due respect to big companies, their resources, and ability > >> to effortlessly deploy SSL/TLS, it is still an expensive and complex > >> process for more developers deploying small scale server components. > > > > With all due respect, I think it can be harder for big companies to > > deploy TLS -- they have a lot more users, need more hardware (special > > SSL accelerators and the like), have more layers of employees (so it can > > be more difficult to find the person who controls the hostmaster or > > whois-listed email address), etc. > > > > Getting a Class 1 cert from the likes of StartSSL is easy as pie these > > days. IMHO there is no excuse for not deploying SSL if you care one whit > > about security. The problem is that too many small-scale developers (and > > big companies!) simply don't care. > > I'm far from an expert on TLS/PKI, but here's a thought (and I'm > pretty sure this has come up before)... If TLS is simpler than > signatures then why not just use PKI for everything. A lot of the > problems that have come up with OAuth are solved by PKI - client certs > replace tokens, you can delegate authority by creating > sub-certificates, the consumer provisioning problem is largely solved, > etc. > > It seems like WRAP is using bits of PKI to solve half of the problem > and then re-inventing other bits of PKI for the other half. If TLS/PKI > is the solution, why not go whole hog? > > Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016367f92a7c8e16a0479c4b328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think there are multiple positions here. =A0Just to be clear, my position= is:

A combination of optional TLS, required bearer toke= ns, and optional token rotation (refresh) is sufficiently secure and deploy= able. =A0I believe that mandatory TLS would unacceptably reduce deployabili= ty (and mandatory dependence on certificate chains more so).

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Wed, Dec 2, 2009 at 11:57 AM, Mike Ma= lone <mjmalone@g= mail.com> wrote:
On Tue, Dec 1, 2009 at 6:58 PM, Peter Sai= nt-Andre <stpeter@stpeter.im&g= t; wrote:
> <hat type=3D'individual'/>
>
> On 11/30/09 1:27 PM, Eran Hammer-Lahav wrote:
>> OAuth is being proposed as a generally useful method for securing = API
>> calls. I expect many open source libraries to implement it on the<= br> >> server side and use it for blog plugins, widgets, and other highly=
>> distributed software. If OAuth required the use of TLS, it would >> simply be ignored by all those applications which will likely
>> continue using Basic.
>>
>> With all due respect to big companies, their resources, and abilit= y
>> to effortlessly deploy SSL/TLS, it is still an expensive and compl= ex
>> process for more developers deploying small scale server component= s.
>
> With all due respect, I think it can be harder for big companies to > deploy TLS -- they have a lot more users, need more hardware (special<= br> > SSL accelerators and the like), have more layers of employees (so it c= an
> be more difficult to find the person who controls the hostmaster or > whois-listed email address), etc.
>
> Getting a Class 1 cert from the likes of StartSSL is easy as pie these=
> days. IMHO there is no excuse for not deploying SSL if you care one wh= it
> about security. The problem is that too many small-scale developers (a= nd
> big companies!) simply don't care.

I'm far from an expert on TLS/PKI, but here's a thought= (and I'm
pretty sure this has come up before)... If TLS is simpler than
signatures then why not just use PKI for everything. A lot of the
problems that have come up with OAuth are solved by PKI - client certs
replace tokens, you can delegate authority by creating
sub-certificates, the consumer provisioning problem is largely solved,
etc.

It seems like WRAP is using bits of PKI to solve half of the problem
and then re-inventing other bits of PKI for the other half. If TLS/PKI
is the solution, why not go whole hog?

Mike
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016367f92a7c8e16a0479c4b328-- From Dick.Hardt@microsoft.com Wed Dec 2 13:14:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DEB93A690D for ; Wed, 2 Dec 2009 13:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjxSt674T+1s for ; Wed, 2 Dec 2009 13:14:41 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 19F453A6849 for ; Wed, 2 Dec 2009 13:14:41 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 2 Dec 2009 13:14:59 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.27]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Wed, 2 Dec 2009 13:14:32 -0800 From: Dick Hardt To: Mike Malone Thread-Topic: [OAUTH-WG] why are we signing? Thread-Index: AQHKYPpiJlPvjbF+7Eug3PbIB1m6s5EuVfSAgAED2ACAAt81AIAAASmAgABrE4CAAH1JAIABBIUAgACcJwCAAAx/gIAa2A2A//97K4CAAA8m8IACiKgAgAEc2gCAABV1AA== Date: Wed, 2 Dec 2009 21:14:30 +0000 Message-ID: <18811A0A-0FA7-4481-8B7F-83A6C4DF2F7C@microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <1b265f40-cbf9-4963-abd4-a8392c116335> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 21:14:44 -0000 On 2009-12-02, at 9:57 AM, Mike Malone wrote: > I'm far from an expert on TLS/PKI, but here's a thought (and I'm > pretty sure this has come up before)... If TLS is simpler than > signatures then why not just use PKI for everything. A lot of the > problems that have come up with OAuth are solved by PKI - client certs > replace tokens, you can delegate authority by creating > sub-certificates, the consumer provisioning problem is largely solved, > etc. >=20 > It seems like WRAP is using bits of PKI to solve half of the problem > and then re-inventing other bits of PKI for the other half. If TLS/PKI > is the solution, why not go whole hog? I'm confused by your PKI references to WRAP. The token in WRAP is not just about identifying the Client, it also enables= authorization. In the implementations we (Microsoft) have done, the token contains all the= claims that the Protected Resource needs to make an access control decisio= n. I hope to have the OAuth WRAP spec reformated as an I-D late next week. -- Dick= From eran@hueniverse.com Wed Dec 2 15:04:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C043A3A699D for ; Wed, 2 Dec 2009 15:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTmR4JbJUI-A for ; Wed, 2 Dec 2009 15:04:42 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EF4483A6816 for ; Wed, 2 Dec 2009 15:04:38 -0800 (PST) Received: (qmail 27770 invoked from network); 2 Dec 2009 23:04:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Dec 2009 23:04:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Dec 2009 16:04:30 -0700 From: Eran Hammer-Lahav To: Mike Malone Date: Wed, 2 Dec 2009 16:04:41 -0700 Thread-Topic: [OAUTH-WG] Remove client credentials from protected resource requests Thread-Index: Acpzhd0HuDkedCTyTv24xp+5vTjD7AAHTAlQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A3C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 23:04:42 -0000 > -----Original Message----- > From: Mike Malone [mailto:mjmalone@gmail.com] > Sent: Wednesday, December 02, 2009 11:30 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Remove client credentials from protected > resource requests >=20 > I'm +1 on this proposal too. Sounds like most of the relevant points have > been made, but I'll reiterate that I think the bearer token should be suf= ficient > for authentication, and I think it will simplify delegation significantly= . >=20 > You're talking about dropping the key/secret. Does that mean we'd be > moving to a WRAP-like model that uses SSL? Without signing, the bearer > token becomes as good as a username/password. If there's no > secret/signature then all of the relevant info for forging a request is s= ent > along with every legitimate request. Am I missing something? No. We are talking about an authentication method with 3 options: 1. Use Token and optional symmetric secret sent in the clear (Bearer token)= with or without TLS. 2. Use Token and a symmetric secret with a MAC-based algorithm signature. T= LS not required for securing secrets, only for other reasons (privacy, MITM= , etc.). 3. User Token and an asymmetric secret (private key) to sign the request. S= erver validates using the public key. TLC not required for securing keys, o= nly for other reasons. The server may issue any kind of token it wishes to support, or any combina= tion of it. The client uses the method appropriate for the token type it re= ceived. The crypto algorithm is negotiable for #2 and #3. A draft is coming shortly. EHL From rbarnes@bbn.com Wed Dec 2 16:10:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC8F3A69B0 for ; Wed, 2 Dec 2009 16:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OujX3EeQ+ZoC for ; Wed, 2 Dec 2009 16:10:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 80DD13A69B1 for ; Wed, 2 Dec 2009 16:10:51 -0800 (PST) Received: from [128.89.253.144] (helo=[10.1.2.164]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NFzHO-0003vs-AE; Wed, 02 Dec 2009 19:10:42 -0500 Message-Id: From: Richard Barnes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A3C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Dec 2009 14:10:36 -1000 References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378520A3C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 00:10:52 -0000 So this sounds like the token is a username by any other name? Instead of a username/password pair, we have a token/PSK pair? --Richard On Dec 2, 2009, at 1:04 PM, Eran Hammer-Lahav wrote: > > >> -----Original Message----- >> From: Mike Malone [mailto:mjmalone@gmail.com] >> Sent: Wednesday, December 02, 2009 11:30 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Remove client credentials from protected >> resource requests >> >> I'm +1 on this proposal too. Sounds like most of the relevant >> points have >> been made, but I'll reiterate that I think the bearer token should >> be sufficient >> for authentication, and I think it will simplify delegation >> significantly. >> >> You're talking about dropping the key/secret. Does that mean we'd be >> moving to a WRAP-like model that uses SSL? Without signing, the >> bearer >> token becomes as good as a username/password. If there's no >> secret/signature then all of the relevant info for forging a >> request is sent >> along with every legitimate request. Am I missing something? > > No. We are talking about an authentication method with 3 options: > > 1. Use Token and optional symmetric secret sent in the clear (Bearer > token) with or without TLS. > 2. Use Token and a symmetric secret with a MAC-based algorithm > signature. TLS not required for securing secrets, only for other > reasons (privacy, MITM, etc.). > 3. User Token and an asymmetric secret (private key) to sign the > request. Server validates using the public key. TLC not required for > securing keys, only for other reasons. > > The server may issue any kind of token it wishes to support, or any > combination of it. The client uses the method appropriate for the > token type it received. The crypto algorithm is negotiable for #2 > and #3. > > A draft is coming shortly. > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Dec 2 16:40:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A2D3A67F9 for ; Wed, 2 Dec 2009 16:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tscnRk76qUB for ; Wed, 2 Dec 2009 16:40:26 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D42B63A67B4 for ; Wed, 2 Dec 2009 16:40:26 -0800 (PST) Received: (qmail 437 invoked from network); 3 Dec 2009 00:40:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 00:40:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 2 Dec 2009 17:40:18 -0700 From: Eran Hammer-Lahav To: Richard Barnes Date: Wed, 2 Dec 2009 17:40:29 -0700 Thread-Topic: [OAUTH-WG] Remove client credentials from protected resource requests Thread-Index: AcpzrQ/gIUGL9b3cS72+gJsHtXXWZAAA+qAA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A437@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378520A3C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 00:40:28 -0000 Yeah... I have been working for the past two days on the introductory prose for thi= s Token scheme, trying to nail what exactly I am proposing and how it is di= fferent from Basic/Digest. Stay tuned. EHL > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Wednesday, December 02, 2009 4:11 PM > To: Eran Hammer-Lahav > Cc: Mike Malone; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Remove client credentials from protected > resource requests >=20 > So this sounds like the token is a username by any other name? > Instead of a username/password pair, we have a token/PSK pair? > --Richard >=20 >=20 >=20 > On Dec 2, 2009, at 1:04 PM, Eran Hammer-Lahav wrote: >=20 > > > > > >> -----Original Message----- > >> From: Mike Malone [mailto:mjmalone@gmail.com] > >> Sent: Wednesday, December 02, 2009 11:30 AM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Remove client credentials from protected > >> resource requests > >> > >> I'm +1 on this proposal too. Sounds like most of the relevant points > >> have been made, but I'll reiterate that I think the bearer token > >> should be sufficient for authentication, and I think it will simplify > >> delegation significantly. > >> > >> You're talking about dropping the key/secret. Does that mean we'd be > >> moving to a WRAP-like model that uses SSL? Without signing, the > >> bearer token becomes as good as a username/password. If there's no > >> secret/signature then all of the relevant info for forging a request > >> is sent along with every legitimate request. Am I missing something? > > > > No. We are talking about an authentication method with 3 options: > > > > 1. Use Token and optional symmetric secret sent in the clear (Bearer > > token) with or without TLS. > > 2. Use Token and a symmetric secret with a MAC-based algorithm > > signature. TLS not required for securing secrets, only for other > > reasons (privacy, MITM, etc.). > > 3. User Token and an asymmetric secret (private key) to sign the > > request. Server validates using the public key. TLC not required for > > securing keys, only for other reasons. > > > > The server may issue any kind of token it wishes to support, or any > > combination of it. The client uses the method appropriate for the > > token type it received. The crypto algorithm is negotiable for #2 and > > #3. > > > > A draft is coming shortly. > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From rbarnes@bbn.com Wed Dec 2 16:50:41 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA3128C0F7 for ; Wed, 2 Dec 2009 16:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Addytb+-NKjs for ; Wed, 2 Dec 2009 16:50:40 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BC5D028C0EB for ; Wed, 2 Dec 2009 16:50:40 -0800 (PST) Received: from [128.89.253.144] (helo=[10.1.2.164]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NFztv-0004Ys-BG; Wed, 02 Dec 2009 19:50:31 -0500 Message-Id: From: Richard Barnes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A437@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 2 Dec 2009 14:50:24 -1000 References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378520A3C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378520A437@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 00:50:42 -0000 I'm pretty sure I've said this before, but I always understood the main difference to be that it works in a single RTT, using timing and nonces instead of the challenge/response of Digest. That, and the signature covers a few different things. --Richard On Dec 2, 2009, at 2:40 PM, Eran Hammer-Lahav wrote: > Yeah... > > I have been working for the past two days on the introductory prose > for this Token scheme, trying to nail what exactly I am proposing > and how it is different from Basic/Digest. > > Stay tuned. > > EHL > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, December 02, 2009 4:11 PM >> To: Eran Hammer-Lahav >> Cc: Mike Malone; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Remove client credentials from protected >> resource requests >> >> So this sounds like the token is a username by any other name? >> Instead of a username/password pair, we have a token/PSK pair? >> --Richard >> >> >> >> On Dec 2, 2009, at 1:04 PM, Eran Hammer-Lahav wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: Mike Malone [mailto:mjmalone@gmail.com] >>>> Sent: Wednesday, December 02, 2009 11:30 AM >>>> To: Eran Hammer-Lahav >>>> Cc: OAuth WG (oauth@ietf.org) >>>> Subject: Re: [OAUTH-WG] Remove client credentials from protected >>>> resource requests >>>> >>>> I'm +1 on this proposal too. Sounds like most of the relevant >>>> points >>>> have been made, but I'll reiterate that I think the bearer token >>>> should be sufficient for authentication, and I think it will >>>> simplify >>>> delegation significantly. >>>> >>>> You're talking about dropping the key/secret. Does that mean we'd >>>> be >>>> moving to a WRAP-like model that uses SSL? Without signing, the >>>> bearer token becomes as good as a username/password. If there's no >>>> secret/signature then all of the relevant info for forging a >>>> request >>>> is sent along with every legitimate request. Am I missing >>>> something? >>> >>> No. We are talking about an authentication method with 3 options: >>> >>> 1. Use Token and optional symmetric secret sent in the clear (Bearer >>> token) with or without TLS. >>> 2. Use Token and a symmetric secret with a MAC-based algorithm >>> signature. TLS not required for securing secrets, only for other >>> reasons (privacy, MITM, etc.). >>> 3. User Token and an asymmetric secret (private key) to sign the >>> request. Server validates using the public key. TLC not required for >>> securing keys, only for other reasons. >>> >>> The server may issue any kind of token it wishes to support, or any >>> combination of it. The client uses the method appropriate for the >>> token type it received. The crypto algorithm is negotiable for #2 >>> and >>> #3. >>> >>> A draft is coming shortly. >>> >>> EHL >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Wed Dec 2 16:55:04 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A817928C0EB for ; Wed, 2 Dec 2009 16:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBOLX6vVLe8V for ; Wed, 2 Dec 2009 16:55:03 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C14773A68E7 for ; Wed, 2 Dec 2009 16:55:03 -0800 (PST) Received: (qmail 14752 invoked from network); 3 Dec 2009 00:54:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 00:54:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 2 Dec 2009 17:54:55 -0700 From: Eran Hammer-Lahav To: Richard Barnes Date: Wed, 2 Dec 2009 17:55:07 -0700 Thread-Topic: [OAUTH-WG] Remove client credentials from protected resource requests Thread-Index: Acpzsp+UD1/tSz83RgeeLjOETkETlQAAG+og Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A43D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A0D8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378520A3C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378520A437@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Remove client credentials from protected resource requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 00:55:04 -0000 >From a technical perspective, yes. But there is also the widely deployed us= er-agent behavior when encountering Basic which is problematic for using Ba= sic with tokens. The proposed Plain method works very much like Basic but i= t doesn't "suffer" from existing experience. EHL > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Wednesday, December 02, 2009 4:50 PM > To: Eran Hammer-Lahav > Cc: Mike Malone; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Remove client credentials from protected > resource requests >=20 > I'm pretty sure I've said this before, but I always understood the main > difference to be that it works in a single RTT, using timing and nonces i= nstead > of the challenge/response of Digest. That, and the signature covers a fe= w > different things. > --Richard >=20 >=20 >=20 >=20 > On Dec 2, 2009, at 2:40 PM, Eran Hammer-Lahav wrote: >=20 > > Yeah... > > > > I have been working for the past two days on the introductory prose > > for this Token scheme, trying to nail what exactly I am proposing and > > how it is different from Basic/Digest. > > > > Stay tuned. > > > > EHL > > > >> -----Original Message----- > >> From: Richard Barnes [mailto:rbarnes@bbn.com] > >> Sent: Wednesday, December 02, 2009 4:11 PM > >> To: Eran Hammer-Lahav > >> Cc: Mike Malone; OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Remove client credentials from protected > >> resource requests > >> > >> So this sounds like the token is a username by any other name? > >> Instead of a username/password pair, we have a token/PSK pair? > >> --Richard > >> > >> > >> > >> On Dec 2, 2009, at 1:04 PM, Eran Hammer-Lahav wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Mike Malone [mailto:mjmalone@gmail.com] > >>>> Sent: Wednesday, December 02, 2009 11:30 AM > >>>> To: Eran Hammer-Lahav > >>>> Cc: OAuth WG (oauth@ietf.org) > >>>> Subject: Re: [OAUTH-WG] Remove client credentials from protected > >>>> resource requests > >>>> > >>>> I'm +1 on this proposal too. Sounds like most of the relevant > >>>> points have been made, but I'll reiterate that I think the bearer > >>>> token should be sufficient for authentication, and I think it will > >>>> simplify delegation significantly. > >>>> > >>>> You're talking about dropping the key/secret. Does that mean we'd > >>>> be moving to a WRAP-like model that uses SSL? Without signing, the > >>>> bearer token becomes as good as a username/password. If there's no > >>>> secret/signature then all of the relevant info for forging a > >>>> request is sent along with every legitimate request. Am I missing > >>>> something? > >>> > >>> No. We are talking about an authentication method with 3 options: > >>> > >>> 1. Use Token and optional symmetric secret sent in the clear (Bearer > >>> token) with or without TLS. > >>> 2. Use Token and a symmetric secret with a MAC-based algorithm > >>> signature. TLS not required for securing secrets, only for other > >>> reasons (privacy, MITM, etc.). > >>> 3. User Token and an asymmetric secret (private key) to sign the > >>> request. Server validates using the public key. TLC not required for > >>> securing keys, only for other reasons. > >>> > >>> The server may issue any kind of token it wishes to support, or any > >>> combination of it. The client uses the method appropriate for the > >>> token type it received. The crypto algorithm is negotiable for #2 > >>> and #3. > >>> > >>> A draft is coming shortly. > >>> > >>> EHL > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Wed Dec 2 22:53:04 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3253A6A6C for ; Wed, 2 Dec 2009 22:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9kM43Q6SO59 for ; Wed, 2 Dec 2009 22:52:34 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 21F263A6A51 for ; Wed, 2 Dec 2009 22:52:33 -0800 (PST) Received: (qmail 4037 invoked from network); 3 Dec 2009 06:52:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 06:52:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 2 Dec 2009 23:52:24 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Wed, 2 Dec 2009 23:52:36 -0700 Thread-Topic: Timestamp and sync Thread-Index: Acpz5TJ/a6EP95buTeG7Gk55u4Dt1A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 06:53:04 -0000 I am going to base the new HMAC method closely after the current HMAC-SHA1 = method (SHA1 will be negotiable and might be replaced as the base protocol = to something more current, but this is off topic). This means we will need = to deal with timestamps to prevent replay attacks. Tim Polk made a comment today on the 1.0 RFC draft that the server should b= e able to simply tell the client to use a trusted time service for clock sy= nchronization. Since timestamp management has been a problematic issue for = many, I feel we need to address it in the new spec to ensure it will not ca= use interop issues. The two main options are: 1. Create a new simple mechanism for clock sync (via error message or API c= all). 2. Have the server point the client to a trusted time service (which the se= rver can run if desired), using a protocol we pick such as NTP (RFC 1305). Comments? EHL From eran@hueniverse.com Wed Dec 2 22:55:16 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961D23A6A51 for ; Wed, 2 Dec 2009 22:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNyCZJtEp-fa for ; Wed, 2 Dec 2009 22:55:16 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D95A13A69F5 for ; Wed, 2 Dec 2009 22:55:15 -0800 (PST) Received: (qmail 18174 invoked from network); 3 Dec 2009 06:55:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 06:55:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 2 Dec 2009 23:55:02 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Wed, 2 Dec 2009 23:55:13 -0700 Thread-Topic: Debug mode Thread-Index: Acpz5ZAELKzJXoeCRZ+J2JZChK+n2w== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Bb9Z B4Yr CXbJ CX5D DW1k Dl8X DwCf EHVi E6tN G4pZ HEQP HYPR IA4p JKKi JX+f KG6c; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {353C5754-59E5-4ADA-BB3A-F2B80F7B6EF7}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Thu, 03 Dec 2009 06:55:13 GMT;RABlAGIAdQBnACAAbQBvAGQAZQA= x-cr-puzzleid: {353C5754-59E5-4ADA-BB3A-F2B80F7B6EF7} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 06:55:16 -0000 One of the most common requests I get is to add a debug mode to the protoco= l, allowing the client to request the server to provide the full signature = base string when the signature check fails. Since this part does not affect= security (since the base string is obvious from the request), it is a matt= er of preference whether we should specify such an interface. Comments? EHL From eran@hueniverse.com Thu Dec 3 00:01:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E73C3A6805 for ; Thu, 3 Dec 2009 00:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ncowomQZq3R for ; Thu, 3 Dec 2009 00:01:31 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AFDA93A67AB for ; Thu, 3 Dec 2009 00:01:31 -0800 (PST) Received: (qmail 26054 invoked from network); 3 Dec 2009 08:01:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 08:01:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 01:01:21 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Thu, 3 Dec 2009 01:01:32 -0700 Thread-Topic: Access to raw HTTP request body Thread-Index: Acpz7tPUIuAG8145TPSyH7nxAqnWPA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: yos= BCx7 DLzV Dig+ E2XB E9Zt FqOi Fw+i F48g GKj9 HuHd Jhzq Jnf3 KxwV K+of LyyU; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {4538A262-D515-43DB-BACB-50CB9E385CFB}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Thu, 03 Dec 2009 08:01:32 GMT; QQBjAGMAZQBzAHMAIAB0AG8AIAByAGEAdwAgAEgAVABUAFAAIAByAGUAcQB1AGUAcwB0ACAAYgBvAGQAeQA= x-cr-puzzleid: {4538A262-D515-43DB-BACB-50CB9E385CFB} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 08:01:32 -0000 While access to the raw HTTP request body is often hard to obtain (due to u= se of streams, protocol layers, etc.) for the purpose of generating a body = hash, is it reasonable to expect the client and server to have access to th= e raw body when sending a form-encoded body request? In other words, in the case of form-encoded bodies, is it reasonable to exp= ect the client and server to be able to simply hash the body instead of nor= malizing its key/value pairs content? We already established it is reasonable to expect the client and server to = have access to the raw HTTP request URI. If we can ask clients and servers = to include form-encoded bodies as-transmitted in the signature base string,= we will remove the need to decode, sort, encode, and concatenate the list = of parameters. Instead, each component can be given a fixed spot in the bas= e string. This and changing the separator characters to new line should mak= e producing the base string significantly easier (which has been a big conc= ern). Comments? (please don't dismiss access to the raw body without thinking clo= sely about the specific circumstances of a form-encoded body). EHL From esjewett@gmail.com Thu Dec 3 05:28:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB353A689C for ; Thu, 3 Dec 2009 05:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n2w8TES61hv for ; Thu, 3 Dec 2009 05:28:50 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 3D4BE3A6889 for ; Thu, 3 Dec 2009 05:28:50 -0800 (PST) Received: by pwi5 with SMTP id 5so348159pwi.29 for ; Thu, 03 Dec 2009 05:28:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3+XsVKhxH0dJP9i6rMd9p7EkMCx9Xv+SOGDSi3trxBw=; b=IQmChXpeFh7jjbtYKW18zjIouauD2vNnElMgYhK1v1GBR58+cp54UznNJnXfmOv1S3 TLC6tw0Ndor+oYTIF7PfaP5APY7LowiiDYyXK+nTTHdJ1VvirhBBI0wrVIeW9lLdzlQ0 7PYi3yh94WBvooUbnId+KEE2vSIU6xe2n0Ee0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=k+w1Re1Mxl8XuknXh/RuM5nyXQuKJMBluwZkcFo28MRSoDuxfviCvxcC3KJP62fAw9 g+ea6O1y3hSPpdSMTXfyQTsNdmcalCa+TI0ccW5ty/3enTq+FNb54y2gKS6E4NPyahh/ S/WQnLZe1J4saudgsoCcUZe5DTk0vjqxwjhwU= MIME-Version: 1.0 Received: by 10.140.247.21 with SMTP id u21mr106251rvh.1.1259846918955; Thu, 03 Dec 2009 05:28:38 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 3 Dec 2009 08:28:38 -0500 Message-ID: <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> From: Ethan Jewett To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 13:28:51 -0000 Unless this would somehow help clients to automatically deal with error conditions, I don't think it belongs in the base spec. We can certainly make some suggestion as to how to accomplish this for API designers, but it seems like something that should be left to the implementation. Ethan On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav wro= te: > One of the most common requests I get is to add a debug mode to the proto= col, allowing the client to request the server to provide the full signatur= e base string when the signature check fails. Since this part does not affe= ct security (since the base string is obvious from the request), it is a ma= tter of preference whether we should specify such an interface. > > Comments? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From James.H.Manger@team.telstra.com Thu Dec 3 05:57:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B16028C14A for ; Thu, 3 Dec 2009 05:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilV+CJB8pUX8 for ; Thu, 3 Dec 2009 05:57:54 -0800 (PST) Received: from mailipao.ntcif.telstra.com.au (mailipao.ntcif.telstra.com.au [202.12.233.27]) by core3.amsl.com (Postfix) with ESMTP id B002128C14D for ; Thu, 3 Dec 2009 05:57:53 -0800 (PST) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipai.ntcif.telstra.com.au with ESMTP; 04 Dec 2009 00:57:44 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id 2BC5AFF82 for ; Fri, 4 Dec 2009 00:57:44 +1100 (EST) Received: from WSMSG3705.srv.dir.telstra.com (wsmsg3705.srv.dir.telstra.com [172.49.40.203]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id B9C10485F1 for ; Fri, 4 Dec 2009 00:57:20 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 4 Dec 2009 00:57:43 +1100 From: "Manger, James H" To: "OAuth WG (oauth@ietf.org)" Date: Fri, 4 Dec 2009 00:57:40 +1100 Thread-Topic: authorization id in SASL mechanisms Thread-Index: Acp0IJQLwRQwHJX8QsiKkeqjDBHwXg== Message-ID: <255B9BB34FB7D647A506DC292726F6E1124A981AC8@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1124A981AC8WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: [OAUTH-WG] authorization id in SASL mechanisms X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 13:57:55 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1124A981AC8WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBub3RpY2VkIHRoYXQgYSBudW1iZXIgb2YgZXhpc3RpbmcgYXV0aGVudGljYXRpb24gc2NoZW1l cyBzdXBwb3J0IGFuIGF1dGhvcml6YXRpb24gaWQsIGluIGFkZGl0aW9uIHRvIGFuIGF1dGhlbnRp Y2F0aW9uIGlkLiBUaGlzIG1vZGVsIG1pZ2h0IGJlIGFwcGxpY2FibGUgdG8gYW55IE9BdXRoIGF1 dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMgYXMgdGhlIHJlc3VsdCBmcm9tIGFuIE9BdXRoIGRlbGVn YXRpb24gZmxvdyBsb29rcyBsaWtlIGEgcGVyZmVjdCBjYW5kaWRhdGUgZm9yIHRoZSBhdXRob3Jp emF0aW9uIGlkIGZpZWxkLg0KDQoNCg0KQSBwcmltZSBleGFtcGxlIHVzaW5nIHRoZXNlIHR3byBp ZGVudGl0aWVzIGlzIFJGQyA0NDIyIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkg TGF5ZXIgKFNBU0wpLg0KDQoNCg0KICAg4oCc4oCmIGNvbmNlcHR1YWxseSwgdGhlIFNBU0wgZnJh bWV3b3JrIGludm9sdmVzIHR3byBpZGVudGl0aWVzOg0KDQoNCg0KICAgICAgMSkgYW4gaWRlbnRp dHkgYXNzb2NpYXRlZCB3aXRoIHRoZSBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscw0KDQogICAg ICAgICAodGVybWVkIHRoZSBhdXRoZW50aWNhdGlvbiBpZGVudGl0eSksIGFuZA0KDQoNCg0KICAg ICAgMikgYW4gaWRlbnRpdHkgdG8gYWN0IGFzICh0ZXJtZWQgdGhlIGF1dGhvcml6YXRpb24gaWRl bnRpdHkpLg0KDQoNCg0KICAgU0FTTCBtZWNoYW5pc20gc3BlY2lmaWNhdGlvbnMgZGVzY3JpYmUg dGhlIGNyZWRlbnRpYWwgZm9ybShzKSAoZS5nLiwNCg0KICAgWC41MDkgY2VydGlmaWNhdGVzLCBL ZXJiZXJvcyB0aWNrZXRzLCBzaW1wbGUgdXNlcm5hbWUvcGFzc3dvcmQpIHVzZWQNCg0KICAgdG8g YXV0aGVudGljYXRlIHRoZSBjbGllbnQsIGluY2x1ZGluZyAod2hlcmUgYXBwcm9wcmlhdGUpIHRo ZSBzeW50YXgNCg0KICAgYW5kIHNlbWFudGljcyBvZiBhdXRoZW50aWNhdGlvbiBpZGVudGl0aWVz IGNhcnJpZWQgaW4gdGhlDQoNCiAgIGNyZWRlbnRpYWxzLiAgU0FTTCBwcm90b2NvbCBzcGVjaWZp Y2F0aW9ucyBkZXNjcmliZSB0aGUgaWRlbnRpdHkNCg0KICAgZm9ybShzKSB1c2VkIGluIGF1dGhv cml6YXRpb24gYW5kLCBpbiBwYXJ0aWN1bGFyLCBwcmVzY3JpYmUgdGhlDQoNCiAgIHN5bnRheCBh bmQgc2VtYW50aWNzIG9mIHRoZSBhdXRob3JpemF0aW9uIGlkZW50aXR5IGNoYXJhY3RlciBzdHJp bmcNCg0KICAgdG8gYmUgdHJhbnNmZXJyZWQgYnkgbWVjaGFuaXNtcy4NCg0KDQogICBUaGUgY2xp ZW50IHByb3ZpZGVzIGl0cyBjcmVkZW50aWFscyAod2hpY2ggaW5jbHVkZSBvciBpbXBseSBhbg0K ICAgYXV0aGVudGljYXRpb24gaWRlbnRpdHkpIGFuZCwgb3B0aW9uYWxseSwgYSBjaGFyYWN0ZXIg c3RyaW5nDQogICByZXByZXNlbnRpbmcgdGhlIHJlcXVlc3RlZCBhdXRob3JpemF0aW9uIGlkZW50 aXR5IGFzIHBhcnQgb2YgdGhlIFNBU0wNCiAgIGV4Y2hhbmdlLiAgV2hlbiB0aGlzIGNoYXJhY3Rl ciBzdHJpbmcgaXMgb21pdHRlZCBvciBlbXB0eSwgdGhlIGNsaWVudA0KICAgaXMgcmVxdWVzdGlu ZyB0byBhY3QgYXMgdGhlIGlkZW50aXR5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY3JlZGVudGlhbHMN CiAgIChlLmcuLCB0aGUgdXNlciBpcyByZXF1ZXN0aW5nIHRvIGFjdCBhcyB0aGUgYXV0aGVudGlj YXRpb24gaWRlbnRpdHkpLg0KDQogICBUaGUgc2VydmVyIGlzIHJlc3BvbnNpYmxlIGZvciB2ZXJp ZnlpbmcgdGhlIGNsaWVudCdzIGNyZWRlbnRpYWxzIGFuZA0KICAgdmVyaWZ5aW5nIHRoYXQgdGhl IGlkZW50aXR5IGl0IGFzc29jaWF0ZXMgd2l0aCB0aGUgY2xpZW50J3MNCiAgIGNyZWRlbnRpYWxz IChlLmcuLCB0aGUgYXV0aGVudGljYXRpb24gaWRlbnRpdHkpIGlzIGFsbG93ZWQgdG8gYWN0IGFz DQogICB0aGUgYXV0aG9yaXphdGlvbiBpZGVudGl0eS4gIEEgU0FTTCBleGNoYW5nZSBmYWlscyBp ZiBlaXRoZXIgKG9yDQogICBib3RoKSBvZiB0aGVzZSB2ZXJpZmljYXRpb25zIGZhaWxzLiAgKFRo ZSBTQVNMIGV4Y2hhbmdlIG1heSBmYWlsIGZvcg0KICAgb3RoZXIgcmVhc29ucywgc3VjaCBhcyBz ZXJ2aWNlIGF1dGhvcml6YXRpb24gZmFpbHVyZS4p4oCdDQoNCg0KDQoNCg0KU0FTTCBpcyBhIGZy YW1ld29yaywgYW5kIHRoZXJlIGFyZSBhIGhhbmRmdWwgb2Ygc3BlY2lmaWMgU0FTTCBtZWNoYW5p c21zIGRlZmluZWQuIE9mIHBhcnRpY3VsYXIgcmVsZXZhbmNlIHRvIE9BdXRoIGFyZTogRVhURVJO QUwgW1JGQyA0NDIyIEFwcGVuZGl4IEFdIGFuZCBQTEFJTiBbUkZDIDQ2MTZdLiBUaGVyZSBhcmUg YWxzbyBkaWdlc3QtbGlrZSBtZWNoYW5pc21zLg0KDQoNCg0KRVhURVJOQUwgaXMgYmFzaWNhbGx5 IGEgYmVhcmVyIHRva2VuLiBJdCBjYXJyaWVzIGFuIGF1dGhvcml6YXRpb24gaWQsIGJ1dCBubyBj bGllbnQgYXV0aGVudGljYXRpb24uDQoNCg0KDQpQTEFJTiBzZW5kcyBhbiBhdXRob3JpemF0aW9u IGlkLCBhdXRoZW50aWNhdGlvbiBpZCAoZWcgY2xpZW50IGlkKSwgYW5kIHBhc3N3b3JkIGluIHRo ZSBjbGVhci4NCg0KDQoNClNBU0wgaXMgZGVzaWduZWQgZm9yIGNvbm5lY3Rpb24tb3JpZW50ZWQg cHJvdG9jb2xzIHNvIGl0IGlzIG5vdCBkaXJlY3RseSBzdWl0YWJsZSBmb3IgbWVzc2FnZS1vcmll bnRlZCBIVFRQLiBIb3dldmVyLCB0aGUgY29uY2VwdCBvZiBhdXRob3JpemF0aW9uIGFuZCBhdXRo ZW50aWNhdGlvbiBpZGVudGl0aWVzIG1pZ2h0IGJlIGEgZ29vZCB3YXkgdG8gZnJhbWUgYW55IE9B dXRoIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuDQoNCg0KDQotLQ0KDQpKYW1lcyBNYW5nZXIN Cg0KDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E1124A981AC8WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJ e3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K IDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUFVIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgbm90aWNlZCB0aGF0IGEgbnVtYmVyIG9mIGV4aXN0aW5nIGF1dGhl bnRpY2F0aW9uIHNjaGVtZXMgc3VwcG9ydCBhbg0KPGI+YXV0aG9yaXphdGlvbiBpZDwvYj4sIGlu IGFkZGl0aW9uIHRvIGFuIDxiPmF1dGhlbnRpY2F0aW9uIGlkPC9iPi4gVGhpcyBtb2RlbCBtaWdo dCBiZSBhcHBsaWNhYmxlIHRvIGFueSBPQXV0aCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIGFz IHRoZSByZXN1bHQgZnJvbSBhbiBPQXV0aCBkZWxlZ2F0aW9uIGZsb3cgbG9va3MgbGlrZSBhIHBl cmZlY3QgY2FuZGlkYXRlIGZvciB0aGUgYXV0aG9yaXphdGlvbiBpZCBmaWVsZC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QSBwcmltZSBleGFtcGxlIHVzaW5nIHRoZXNlIHR3byBpZGVudGl0aWVz IGlzIFJGQyA0NDIyIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJpdHkgTGF5ZXIgKFNB U0wpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IOKAnOKA piBjb25jZXB0dWFsbHksIHRoZSBTQVNMIGZyYW1ld29yayBpbnZvbHZlcyB0d28gaWRlbnRpdGll czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxKSBhbiBpZGVudGl0eSBhc3NvY2lh dGVkIHdpdGggdGhlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAodGVybWVkIHRoZSBhdXRoZW50aWNhdGlvbiBp ZGVudGl0eSksIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIpIGFuIGlkZW50 aXR5IHRvIGFjdCBhcyAodGVybWVkIHRoZSBhdXRob3JpemF0aW9uIGlkZW50aXR5KS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBTQVNMIG1lY2hhbmlzbSBzcGVjaWZpY2F0aW9ucyBkZXNjcmliZSB0aGUgY3JlZGVu dGlhbCBmb3JtKHMpIChlLmcuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgWC41MDkgY2VydGlmaWNhdGVzLCBLZXJiZXJv cyB0aWNrZXRzLCBzaW1wbGUgdXNlcm5hbWUvcGFzc3dvcmQpIHVzZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRvIGF1 dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCBpbmNsdWRpbmcgKHdoZXJlIGFwcHJvcHJpYXRlKSB0aGUg c3ludGF4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBhbmQgc2VtYW50aWNzIG9mIGF1dGhlbnRpY2F0aW9uIGlkZW50aXRp ZXMgY2FycmllZCBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNyZWRlbnRpYWxzLiZuYnNwOyBTQVNMIHByb3Rv Y29sIHNwZWNpZmljYXRpb25zIGRlc2NyaWJlIHRoZSBpZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZm9ybShz KSB1c2VkIGluIGF1dGhvcml6YXRpb24gYW5kLCBpbiBwYXJ0aWN1bGFyLCBwcmVzY3JpYmUgdGhl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBzeW50YXggYW5kIHNlbWFudGljcyBvZiB0aGUgYXV0aG9yaXphdGlvbiBpZGVu dGl0eSBjaGFyYWN0ZXIgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0byBiZSB0cmFuc2ZlcnJlZCBieSBtZWNo YW5pc21zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBjbGllbnQgcHJvdmlkZXMgaXRzIGNyZWRlbnRpYWxz ICh3aGljaCBpbmNsdWRlIG9yIGltcGx5IGFuPG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNw OyZuYnNwO2F1dGhlbnRpY2F0aW9uIGlkZW50aXR5KSBhbmQsIG9wdGlvbmFsbHksIGEgY2hhcmFj dGVyIHN0cmluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyByZXByZXNlbnRp bmcgdGhlIHJlcXVlc3RlZCBhdXRob3JpemF0aW9uIGlkZW50aXR5IGFzIHBhcnQgb2YgdGhlIFNB U0w8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZXhjaGFuZ2UuJm5ic3A7IFdo ZW4gdGhpcyBjaGFyYWN0ZXIgc3RyaW5nIGlzIG9taXR0ZWQgb3IgZW1wdHksIHRoZSBjbGllbnQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaXMgcmVxdWVzdGluZyB0byBhY3Qg YXMgdGhlIGlkZW50aXR5IGFzc29jaWF0ZWQgd2l0aCB0aGUgY3JlZGVudGlhbHM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgKGUuZy4sIHRoZSB1c2VyIGlzIHJlcXVlc3Rpbmcg dG8gYWN0IGFzIHRoZSBhdXRoZW50aWNhdGlvbiBpZGVudGl0eSkuPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBzZXJ2 ZXIgaXMgcmVzcG9uc2libGUgZm9yIHZlcmlmeWluZyB0aGUgY2xpZW50J3MgY3JlZGVudGlhbHMg YW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHZlcmlmeWluZyB0aGF0IHRo ZSBpZGVudGl0eSBpdCBhc3NvY2lhdGVzIHdpdGggdGhlIGNsaWVudCdzPG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNyZWRlbnRpYWxzIChlLmcuLCB0aGUgYXV0aGVudGljYXRp b24gaWRlbnRpdHkpIGlzIGFsbG93ZWQgdG8gYWN0IGFzPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IHRoZSBhdXRob3JpemF0aW9uIGlkZW50aXR5LiZuYnNwOyBBIFNBU0wgZXhj aGFuZ2UgZmFpbHMgaWYgZWl0aGVyIChvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBib3RoKSBvZiB0aGVzZSB2ZXJpZmljYXRpb25zIGZhaWxzLiZuYnNwOyAoVGhlIFNBU0wg ZXhjaGFuZ2UgbWF5IGZhaWwgZm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IG90aGVyIHJlYXNvbnMsIHN1Y2ggYXMgc2VydmljZSBhdXRob3JpemF0aW9uIGZhaWx1cmUuKeKA nTxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNBU0wgaXMg YSBmcmFtZXdvcmssIGFuZCB0aGVyZSBhcmUgYSBoYW5kZnVsIG9mIHNwZWNpZmljIFNBU0wgbWVj aGFuaXNtcyBkZWZpbmVkLiBPZiBwYXJ0aWN1bGFyIHJlbGV2YW5jZSB0byBPQXV0aCBhcmU6IEVY VEVSTkFMIFtSRkMgNDQyMiBBcHBlbmRpeCBBXSBhbmQgUExBSU4gW1JGQyA0NjE2XS4gVGhlcmUg YXJlIGFsc28gZGlnZXN0LWxpa2UgbWVjaGFuaXNtcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RVhURVJOQUwgaXMgYmFzaWNhbGx5IGEgYmVhcmVyIHRva2VuLiBJdCBjYXJyaWVzIGFuIGF1dGhv cml6YXRpb24gaWQsIGJ1dCBubyBjbGllbnQgYXV0aGVudGljYXRpb24uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlBMQUlOIHNlbmRzIGFuIGF1dGhvcml6YXRpb24gaWQsIGF1dGhlbnRpY2F0aW9u IGlkIChlZyBjbGllbnQgaWQpLCBhbmQgcGFzc3dvcmQgaW4gdGhlIGNsZWFyLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TQVNMIGlzIGRlc2lnbmVkIGZvciBjb25uZWN0aW9uLW9yaWVudGVkIHBy b3RvY29scyBzbyBpdCBpcyBub3QgZGlyZWN0bHkgc3VpdGFibGUgZm9yIG1lc3NhZ2Utb3JpZW50 ZWQgSFRUUC4gSG93ZXZlciwgdGhlIGNvbmNlcHQgb2YgYXV0aG9yaXphdGlvbiBhbmQgYXV0aGVu dGljYXRpb24gaWRlbnRpdGllcyBtaWdodCBiZSBhIGdvb2Qgd2F5IHRvIGZyYW1lIGFueSBPQXV0 aCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbWVzIE1hbmdlcjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_255B9BB34FB7D647A506DC292726F6E1124A981AC8WSMSG3153Vsrv_-- From GFFletch@aol.com Thu Dec 3 06:07:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C4D28C15B for ; Thu, 3 Dec 2009 06:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3s2na+Gmmb7 for ; Thu, 3 Dec 2009 06:07:11 -0800 (PST) Received: from imr-ma06.mx.aol.com (imr-ma06.mx.aol.com [64.12.78.142]) by core3.amsl.com (Postfix) with ESMTP id 5AB6228C158 for ; Thu, 3 Dec 2009 06:07:10 -0800 (PST) Received: from imo-da03.mx.aol.com (imo-da03.mx.aol.com [205.188.169.201]) by imr-ma06.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB3E6tBE016320; Thu, 3 Dec 2009 09:06:55 -0500 Received: from GFFletch@aol.com by imo-da03.mx.aol.com (mail_out_v42.5.) id l.cf3.66bb0d0d (44000); Thu, 3 Dec 2009 09:06:53 -0500 (EST) Received: from c0a8016b.tipt.aol.com ([10.172.2.141]) by cia-dd07.mx.aol.com (v126.13) with ESMTP id MAILCIADD071-abe04b17c5fd3c0; Thu, 03 Dec 2009 09:06:53 -0500 Message-ID: <4B17C5FD.8030609@aol.com> Date: Thu, 03 Dec 2009 09:06:53 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> In-Reply-To: <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.172.2.141 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 14:07:12 -0000 +1 It's pretty easy to set up a http://example.com/debugOauth resource that takes the request and validates the signature, returning as much debug information as possible. Thanks, George Ethan Jewett wrote: > Unless this would somehow help clients to automatically deal with > error conditions, I don't think it belongs in the base spec. We can > certainly make some suggestion as to how to accomplish this for API > designers, but it seems like something that should be left to the > implementation. > > Ethan > > On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav wrote: > >> One of the most common requests I get is to add a debug mode to the protocol, allowing the client to request the server to provide the full signature base string when the signature check fails. Since this part does not affect security (since the base string is obvious from the request), it is a matter of preference whether we should specify such an interface. >> >> Comments? >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From stpeter@stpeter.im Thu Dec 3 06:21:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5125028C165 for ; Thu, 3 Dec 2009 06:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6BjuniEY+DH for ; Thu, 3 Dec 2009 06:21:25 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7E24D28C164 for ; Thu, 3 Dec 2009 06:21:25 -0800 (PST) Received: from squire.local (dsl-175-112.dynamic-dsl.frii.net [216.17.175.112]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 799C340337; Thu, 3 Dec 2009 07:21:16 -0700 (MST) Message-ID: <4B17C95B.3060507@stpeter.im> Date: Thu, 03 Dec 2009 07:21:15 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: George Fletcher References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> <4B17C5FD.8030609@aol.com> In-Reply-To: <4B17C5FD.8030609@aol.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050300040504070001000002" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 14:21:26 -0000 This is a cryptographically signed message in MIME format. --------------ms050300040504070001000002 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Agreed. I start to worry when a protocol needs a debug mode... On 12/3/09 7:06 AM, George Fletcher wrote: > +1 > > It's pretty easy to set up a http://example.com/debugOauth resource that > takes the request and validates the signature, returning as much debug > information as possible. > > Thanks, > George > > Ethan Jewett wrote: >> Unless this would somehow help clients to automatically deal with >> error conditions, I don't think it belongs in the base spec. We can >> certainly make some suggestion as to how to accomplish this for API >> designers, but it seems like something that should be left to the >> implementation. >> >> Ethan >> >> On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav >> wrote: >> >>> One of the most common requests I get is to add a debug mode to the >>> protocol, allowing the client to request the server to provide the >>> full signature base string when the signature check fails. Since this >>> part does not affect security (since the base string is obvious from >>> the request), it is a matter of preference whether we should specify >>> such an interface. >>> >>> Comments? >>> >>> EHL --------------ms050300040504070001000002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzE0MjExNVowIwYJKoZIhvcNAQkEMRYEFMMc7dEz021XQQjkgRX5 kHbZUWIWMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAgu6fGVGtf1aVVYztkTage2JiOWAQgI8uujwkZAew 0jZbDCE2i4GApunjjdMG4hVfV1qiAHglTLmCgCVVLCEU5APhjL2NlgIeePbTwHdcjMdPnIig hBoMbNRm3luYnaeGMnvHpvyV/RdXv3Io1u3JLB4nReVGdJnhZt7nGY+bSxk7yHTDzzOWpqbk G75a02KhvyOKJH0xJ5mzbinS+RO2DVovxZprsiSZ7ve+vz/46bcRMZlyyTwUvoH6N0qWuCYF YdYLioed4x6AF3ciM4HEPot8VItjCNxiMTYxSeD2jZVDGQYayh8m9KhnlQfYsUNk11fbYMH3 oVxBvfWnidI+eAAAAAAAAA== --------------ms050300040504070001000002-- From GFFletch@aol.com Thu Dec 3 06:24:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC0528C164 for ; Thu, 3 Dec 2009 06:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgZOCCK09nmY for ; Thu, 3 Dec 2009 06:24:15 -0800 (PST) Received: from imr-ma02.mx.aol.com (imr-ma02.mx.aol.com [64.12.206.40]) by core3.amsl.com (Postfix) with ESMTP id 0479A28C159 for ; Thu, 3 Dec 2009 06:24:14 -0800 (PST) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-ma02.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB3ENk6I027065; Thu, 3 Dec 2009 09:23:46 -0500 Received: from GFFletch@aol.com by imo-da04.mx.aol.com (mail_out_v42.5.) id l.d34.5f01c852 (43997); Thu, 3 Dec 2009 09:23:40 -0500 (EST) Received: from c0a8016b.tipt.aol.com ([10.172.2.141]) by cia-dd06.mx.aol.com (v126.13) with ESMTP id MAILCIADD066-abdd4b17c9ece0; Thu, 03 Dec 2009 09:23:40 -0500 Message-ID: <4B17C9EC.7090003@aol.com> Date: Thu, 03 Dec 2009 09:23:40 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.172.2.141 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 14:24:16 -0000 +1 to option #1 Given that some OAuth clients will be desktop apps (and not web servers), I think it's very scary to change the time on a person's machine who may have specifically changed it (for some reason). As for real-world implementations, this is what we use with our proprietary protocol today. The server returns it's time value and then the client can calculate the skew and process accordingly. Thanks, George Eran Hammer-Lahav wrote: > I am going to base the new HMAC method closely after the current HMAC-SHA1 method (SHA1 will be negotiable and might be replaced as the base protocol to something more current, but this is off topic). This means we will need to deal with timestamps to prevent replay attacks. > > Tim Polk made a comment today on the 1.0 RFC draft that the server should be able to simply tell the client to use a trusted time service for clock synchronization. Since timestamp management has been a problematic issue for many, I feel we need to address it in the new spec to ensure it will not cause interop issues. > > The two main options are: > > 1. Create a new simple mechanism for clock sync (via error message or API call). > 2. Have the server point the client to a trusted time service (which the server can run if desired), using a protocol we pick such as NTP (RFC 1305). > > Comments? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From stpeter@stpeter.im Thu Dec 3 06:37:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E93B3A6808 for ; Thu, 3 Dec 2009 06:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91fdW18ejvzO for ; Thu, 3 Dec 2009 06:37:07 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B00B13A67D3 for ; Thu, 3 Dec 2009 06:37:07 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F13F040337; Thu, 3 Dec 2009 07:36:58 -0700 (MST) Message-ID: <4B17CD09.5060402@stpeter.im> Date: Thu, 03 Dec 2009 07:36:57 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: George Fletcher References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> In-Reply-To: <4B17C9EC.7090003@aol.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050501000702070508040001" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 14:37:08 -0000 This is a cryptographically signed message in MIME format. --------------ms050501000702070508040001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/3/09 7:23 AM, George Fletcher wrote: > > Eran Hammer-Lahav wrote: >> I am going to base the new HMAC method closely after the current >> HMAC-SHA1 method (SHA1 will be negotiable and might be replaced as the >> base protocol to something more current, but this is off topic). This >> means we will need to deal with timestamps to prevent replay attacks. >> >> Tim Polk made a comment today on the 1.0 RFC draft that the server >> should be able to simply tell the client to use a trusted time service >> for clock synchronization. Since timestamp management has been a >> problematic issue for many, I feel we need to address it in the new >> spec to ensure it will not cause interop issues. >> >> The two main options are: >> >> 1. Create a new simple mechanism for clock sync (via error message or >> API call). >> 2. Have the server point the client to a trusted time service (which >> the server can run if desired), using a protocol we pick such as NTP >> (RFC 1305). > > +1 to option #1 > > Given that some OAuth clients will be desktop apps (and not web > servers), I think it's very scary to change the time on a person's > machine who may have specifically changed it (for some reason). As for > real-world implementations, this is what we use with our proprietary > protocol today. The server returns it's time value and then the client > can calculate the skew and process accordingly. I don't see a good reason to design around operating systems that can't be bothered to synchronize to recognized time servers via NTP. And I think it's extremely unlikely that a person will specifically change their machine's time to be, say, 10 minutes ahead of canonical time. By all means provide a way for the server to tell the client what its time is when returning an error related to expired tokens and the like, but don't let's reinvent NTP while we're at it. :) Peter --------------ms050501000702070508040001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzE0MzY1N1owIwYJKoZIhvcNAQkEMRYEFHO2h/1A19Gl4EVYeUbl e/GxUzQsMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAOlzTD4RGAjBxJ2HyTrebAC8rNnioECUg5tqaMaQi sNN1BHfeRDFkE+LBdI+95RTRGPR67k6zujIeMkhiHksz0tlLY9r93ImPozOmwTyx32u3Y2w6 8b2pxg8yH4LGHVbz+ECGlsaq3I3inh2gtjBXYXM1G/mgdgsqXRgMY574bTtG74umzI+vlPhD hLpmWZPB4SzP/oI4AqOmtTgrvi0B2SGe8slP4jzu2ruP+ADNkI9rwiY0u2LLLBrZ3XvOc3qB /7jPzZqXYqeWrxx6ZuvbSqkRQPaLzwFqsdM/j9I6z5v32l3vW2vxs+O9US+Fb1XUCvMTErzH PayTetnd/UnkjAAAAAAAAA== --------------ms050501000702070508040001-- From faynberg@alcatel-lucent.com Thu Dec 3 06:43:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D0C3A6A5C for ; Thu, 3 Dec 2009 06:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvDrsoUqN1CR for ; Thu, 3 Dec 2009 06:43:37 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 397FF3A6A36 for ; Thu, 3 Dec 2009 06:43:37 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nB3EhQXU005998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 08:43:26 -0600 (CST) Received: from [135.244.23.63] (faynberg.lra.lucent.com [135.244.23.63]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nB3EhPoY002639; Thu, 3 Dec 2009 08:43:26 -0600 (CST) Message-ID: <4B17CE8C.2030703@alcatel-lucent.com> Date: Thu, 03 Dec 2009 09:43:24 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: George Fletcher References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> In-Reply-To: <4B17C9EC.7090003@aol.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 14:43:38 -0000 I am actually +1 on both options (assuming that using GPS for time synchronizaion is implicitly included). While I agree with George that the client's clock may not be manipulated externally, I did not think that option #2 implied that. Igor George Fletcher wrote: > +1 to option #1 > > Given that some OAuth clients will be desktop apps (and not web > servers), I think it's very scary to change the time on a person's > machine who may have specifically changed it (for some reason). As > for real-world implementations, this is what we use with our > proprietary protocol today. The server returns it's time value and > then the client can calculate the skew and process accordingly. > > Thanks, > George > > Eran Hammer-Lahav wrote: >> I am going to base the new HMAC method closely after the current >> HMAC-SHA1 method (SHA1 will be negotiable and might be replaced as >> the base protocol to something more current, but this is off topic). >> This means we will need to deal with timestamps to prevent replay >> attacks. >> >> Tim Polk made a comment today on the 1.0 RFC draft that the server >> should be able to simply tell the client to use a trusted time >> service for clock synchronization. Since timestamp management has >> been a problematic issue for many, I feel we need to address it in >> the new spec to ensure it will not cause interop issues. >> >> The two main options are: >> >> 1. Create a new simple mechanism for clock sync (via error message or >> API call). >> 2. Have the server point the client to a trusted time service (which >> the server can run if desired), using a protocol we pick such as NTP >> (RFC 1305). >> >> Comments? >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Dec 3 07:30:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD323A680D for ; Thu, 3 Dec 2009 07:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tQ195dJBIh6 for ; Thu, 3 Dec 2009 07:30:00 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A7B243A62C1 for ; Thu, 3 Dec 2009 07:30:00 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7AF4740337; Thu, 3 Dec 2009 08:29:51 -0700 (MST) Message-ID: <4B17D96E.8030002@stpeter.im> Date: Thu, 03 Dec 2009 08:29:50 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: faynberg@alcatel-lucent.com References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> In-Reply-To: <4B17CE8C.2030703@alcatel-lucent.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070008070600070606050307" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:30:01 -0000 This is a cryptographically signed message in MIME format. --------------ms070008070600070606050307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/3/09 7:43 AM, Igor Faynberg wrote: > I am actually +1 on both options (assuming that using GPS for time > synchronizaion is implicitly included). While I agree with George that > the client's clock may not be manipulated externally, I did not think > that option #2 implied that. What confuses me about option #2 is this: why is it the OAuth server's responsibility to tell the OAuth client about a trusted NTP server? IMHO the device on which the OAuth client is running can already discover NTP servers on its own, and nothing the OAuth server tells the OAuth client will have an special influence here. /psa --------------ms070008070600070606050307 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzE1Mjk1MFowIwYJKoZIhvcNAQkEMRYEFLUGtgovW5kbD8JnKEs7 GBzqTuZlMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAOOOzbF+B+Glu7w8xk/b6sCqwCRJWd0zmwNEJUG3J nUzCp2BVfuzGIKFQu+DWI1Q/9QF8egC4rfQb3dBCROI34X1/uJ1E9KnCwaaKO4PIYhD+kJbU XCvzqpFl4oTBJvbG39OBCKtM14ZK3AoAU6nRVt4KmX4izHS13UHdOpiga2WLut9ZAoUitXd3 7EJvkTXfADmPOd3GuPZJeX07NGjggeYP8U+6chWYXHwPAeXz7iONd5MvEDrqKsnDBKkrBMrX TGI5RlPUeWkOF15aAbmgsoFMqLBzk7ncQ3RgUebzfcooe9O69ZD1XGDpfzT/BVqsCOn3GS+j x6vT71Tn6QBoBwAAAAAAAA== --------------ms070008070600070606050307-- From faynberg@alcatel-lucent.com Thu Dec 3 07:34:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B894D3A6864 for ; Thu, 3 Dec 2009 07:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L++r7QJubpoj for ; Thu, 3 Dec 2009 07:34:37 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id F013D3A6810 for ; Thu, 3 Dec 2009 07:34:36 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id nB3FYR6A000821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Dec 2009 09:34:27 -0600 (CST) Received: from [135.244.23.63] (faynberg.lra.lucent.com [135.244.23.63]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nB3FYQ6M019166; Thu, 3 Dec 2009 09:34:26 -0600 (CST) Message-ID: <4B17DA82.50006@alcatel-lucent.com> Date: Thu, 03 Dec 2009 10:34:26 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Saint-Andre References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> In-Reply-To: <4B17D96E.8030002@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:34:37 -0000 Ah, now I see the point. I agree. Igor Peter Saint-Andre wrote: > > > On 12/3/09 7:43 AM, Igor Faynberg wrote: > >> I am actually +1 on both options (assuming that using GPS for time >> synchronizaion is implicitly included). While I agree with George that >> the client's clock may not be manipulated externally, I did not think >> that option #2 implied that. >> > > What confuses me about option #2 is this: why is it the OAuth server's > responsibility to tell the OAuth client about a trusted NTP server? IMHO > the device on which the OAuth client is running can already discover NTP > servers on its own, and nothing the OAuth server tells the OAuth client > will have an special influence here. > > /psa > > From paul.madsen@gmail.com Thu Dec 3 07:44:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2413A6A65 for ; Thu, 3 Dec 2009 07:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqWHvzNWImLu for ; Thu, 3 Dec 2009 07:44:06 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 89EF83A67F6 for ; Thu, 3 Dec 2009 07:44:06 -0800 (PST) Received: by qyk41 with SMTP id 41so570788qyk.29 for ; Thu, 03 Dec 2009 07:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=ZzL0osIEU6ZjVHzfCULDAV3HTL02RGtr28U9u5QrzFw=; b=ikEWE1okfUKUgofKPE7EiryrnRFb9sis5gGJslwhCkyw77xKxt9nLlIII5fd6hN81S Drh/ENL5r0g3RqyBUpgD5PbBBebfmMTKutD4NDe6BoRrC9Ll6c4iXTgoFy70URHauLEH qiC8GN8UYAcgWU1RpCgIy+I7ztk2LA7/r2Vc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=xC0+8YUXUks6iQv51QBX7TF2x8rGDcPt2VaN8ka66OFklsbpmlY9NISsicFd1QMbgs ejCMc2XRJDA1LmGYx9EqHbzIhlU57kWqgclZg+csbhNpkbwhAUcvLeY8YnsJozBRQIwW c3NQOhq/oKtlxBQlzq1mGTye79mHm3ISZsBwY= Received: by 10.224.43.164 with SMTP id w36mr911411qae.336.1259855035439; Thu, 03 Dec 2009 07:43:55 -0800 (PST) Received: from ?192.168.0.195? (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.180.160]) by mx.google.com with ESMTPS id 7sm1087026yxg.32.2009.12.03.07.43.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 07:43:54 -0800 (PST) Message-ID: <4B17DCAC.9060201@gmail.com> Date: Thu, 03 Dec 2009 10:43:40 -0500 From: Paul Madsen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Saint-Andre References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> In-Reply-To: <4B17D96E.8030002@stpeter.im> Content-Type: multipart/alternative; boundary="------------060903060802000207020402" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:44:07 -0000 This is a multi-part message in MIME format. --------------060903060802000207020402 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Isn the point of #2 to allow the server to indicate to the client 'Hey use NTP - perhaps this server' when it is clear that the client wasnt already doing so? Peter Saint-Andre wrote: > > > On 12/3/09 7:43 AM, Igor Faynberg wrote: > >> I am actually +1 on both options (assuming that using GPS for time >> synchronizaion is implicitly included). While I agree with George that >> the client's clock may not be manipulated externally, I did not think >> that option #2 implied that. >> > > What confuses me about option #2 is this: why is it the OAuth server's > responsibility to tell the OAuth client about a trusted NTP server? IMHO > the device on which the OAuth client is running can already discover NTP > servers on its own, and nothing the OAuth server tells the OAuth client > will have an special influence here. > > /psa > > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------060903060802000207020402 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Isn the point of #2 to allow the server to indicate to the client 'Hey use NTP - perhaps this server' when it is clear that the client wasnt already doing so?

Peter Saint-Andre wrote: 
<hat type='individual'/>

On 12/3/09 7:43 AM, Igor Faynberg wrote:
  
I am actually +1 on both options (assuming that using GPS for time
synchronizaion is implicitly included). While I agree with George that
the client's clock may not be manipulated externally, I did not think
that option #2 implied that.
    

What confuses me about option #2 is this: why is it the OAuth server's
responsibility to tell the OAuth client about a trusted NTP server? IMHO
the device on which the OAuth client is running can already discover NTP
servers on its own, and nothing the OAuth server tells the OAuth client
will have an special influence here.

/psa

  

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------060903060802000207020402-- From GFFletch@aol.com Thu Dec 3 07:49:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEBBC3A6810 for ; Thu, 3 Dec 2009 07:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWQVN5xy-WK7 for ; Thu, 3 Dec 2009 07:49:55 -0800 (PST) Received: from imr-da04.mx.aol.com (imr-da04.mx.aol.com [205.188.105.146]) by core3.amsl.com (Postfix) with ESMTP id F145D3A67A8 for ; Thu, 3 Dec 2009 07:49:54 -0800 (PST) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-da04.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB3FnPPd025210; Thu, 3 Dec 2009 10:49:25 -0500 Received: from GFFletch@aol.com by imo-ma01.mx.aol.com (mail_out_v42.5.) id l.be1.6cbd4180 (37590); Thu, 3 Dec 2009 10:49:19 -0500 (EST) Received: from c0a8016b.tipt.aol.com ([10.172.2.141]) by cia-mb06.mx.aol.com (v126.13) with ESMTP id MAILCIAMB063-92d64b17ddff1aa; Thu, 03 Dec 2009 10:49:19 -0500 Message-ID: <4B17DDFF.5060001@aol.com> Date: Thu, 03 Dec 2009 10:49:19 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> <4B17DA82.50006@alcatel-lucent.com> In-Reply-To: <4B17DA82.50006@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.172.2.141 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:49:56 -0000 I agree that OAuth shouldn't try and solve the clock-sync problem at the device level. Rather provide a way to work with whatever skew the device the OAuth client is running on has. Of course, if we can get the device to sync it's clock that's better but it shouldn't be an OAuth protocol requirement. Data point: Given our history with deploying multiple desktop clients, we have lots of real-world data that says consumers have out-of-sync clocks. Thanks, George Igor Faynberg wrote: > > Ah, now I see the point. I agree. > > Igor > > > Peter Saint-Andre wrote: >> >> >> On 12/3/09 7:43 AM, Igor Faynberg wrote: >> >>> I am actually +1 on both options (assuming that using GPS for time >>> synchronizaion is implicitly included). While I agree with George that >>> the client's clock may not be manipulated externally, I did not think >>> that option #2 implied that. >>> >> >> What confuses me about option #2 is this: why is it the OAuth server's >> responsibility to tell the OAuth client about a trusted NTP server? IMHO >> the device on which the OAuth client is running can already discover NTP >> servers on its own, and nothing the OAuth server tells the OAuth client >> will have an special influence here. >> >> /psa >> >> > > From GFFletch@aol.com Thu Dec 3 07:50:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0BD3A6810 for ; Thu, 3 Dec 2009 07:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MUtoc6vJ689 for ; Thu, 3 Dec 2009 07:50:52 -0800 (PST) Received: from imr-mb01.mx.aol.com (imr-mb01.mx.aol.com [64.12.207.164]) by core3.amsl.com (Postfix) with ESMTP id DD7713A680D for ; Thu, 3 Dec 2009 07:50:51 -0800 (PST) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-mb01.mx.aol.com (8.14.1/8.14.1) with ESMTP id nB3FoPfd015957; Thu, 3 Dec 2009 10:50:26 -0500 Received: from GFFletch@aol.com by imo-ma01.mx.aol.com (mail_out_v42.5.) id o.bf6.483e0811 (37692); Thu, 3 Dec 2009 10:50:21 -0500 (EST) Received: from c0a8016b.tipt.aol.com ([10.172.2.141]) by cia-mb08.mx.aol.com (v126.13) with ESMTP id MAILCIAMB088-933c4b17de3d240; Thu, 03 Dec 2009 10:50:21 -0500 Message-ID: <4B17DE3D.3000204@aol.com> Date: Thu, 03 Dec 2009 10:50:21 -0500 From: George Fletcher Organization: AOL LLC User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Paul Madsen References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> <4B17DCAC.9060201@gmail.com> In-Reply-To: <4B17DCAC.9060201@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.172.2.141 X-Mailer: Unknown (No Version) X-AOL-SENDER: GFFletch@aol.com Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 15:50:54 -0000 But what can the client do with that message? Should the client modify the OS settings of the device to start syncing the clock? Thanks, George Paul Madsen wrote: > Isn the point of #2 to allow the server to indicate to the client 'Hey > use NTP - perhaps this server' when it is clear that the client wasnt > already doing so? > > Peter Saint-Andre wrote: >> >> >> On 12/3/09 7:43 AM, Igor Faynberg wrote: >> >>> I am actually +1 on both options (assuming that using GPS for time >>> synchronizaion is implicitly included). While I agree with George that >>> the client's clock may not be manipulated externally, I did not think >>> that option #2 implied that. >>> >> >> What confuses me about option #2 is this: why is it the OAuth server's >> responsibility to tell the OAuth client about a trusted NTP server? IMHO >> the device on which the OAuth client is running can already discover NTP >> servers on its own, and nothing the OAuth server tells the OAuth client >> will have an special influence here. >> >> /psa >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Thu Dec 3 08:56:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC883A6937 for ; Thu, 3 Dec 2009 08:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCeGIA9lBy0U for ; Thu, 3 Dec 2009 08:56:26 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E1F5A3A676A for ; Thu, 3 Dec 2009 08:56:25 -0800 (PST) Received: (qmail 28983 invoked from network); 3 Dec 2009 16:56:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 16:56:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 09:56:00 -0700 From: Eran Hammer-Lahav To: George Fletcher Date: Thu, 3 Dec 2009 09:55:45 -0700 Thread-Topic: [OAUTH-WG] Timestamp and sync Thread-Index: Acp0OX3q0HnEV3/ATlu/nqlCywmq5w== Message-ID: <1D38D21A-D81F-4E7C-A14C-C75368A0B725@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> <4B17DCAC.9060201@gmail.com> <4B17DE3D.3000204@aol.com> In-Reply-To: <4B17DE3D.3000204@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 16:56:26 -0000 Just use the NTP data to calculate the skew. No need to change the OS =20 level clock. That was not implied in my list. EHL On Dec 3, 2009, at 7:50, "George Fletcher" wrote: > But what can the client do with that message? Should the client modify > the OS settings of the device to start syncing the clock? > > Thanks, > George > > Paul Madsen wrote: >> Isn the point of #2 to allow the server to indicate to the client =20 >> 'Hey >> use NTP - perhaps this server' when it is clear that the client wasnt >> already doing so? >> >> Peter Saint-Andre wrote: >>> >>> >>> On 12/3/09 7:43 AM, Igor Faynberg wrote: >>> >>>> I am actually +1 on both options (assuming that using GPS for time >>>> synchronizaion is implicitly included). While I agree with George =20 >>>> that >>>> the client's clock may not be manipulated externally, I did not =20 >>>> think >>>> that option #2 implied that. >>>> >>> >>> What confuses me about option #2 is this: why is it the OAuth =20 >>> server's >>> responsibility to tell the OAuth client about a trusted NTP =20 >>> server? IMHO >>> the device on which the OAuth client is running can already =20 >>> discover NTP >>> servers on its own, and nothing the OAuth server tells the OAuth =20 >>> client >>> will have an special influence here. >>> >>> /psa >>> >>> >>> ---=20 >>> ---=20 >>> ------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Dec 3 09:19:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6602F3A677D for ; Thu, 3 Dec 2009 09:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr-C6Omhb8nb for ; Thu, 3 Dec 2009 09:19:14 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 97F153A672E for ; Thu, 3 Dec 2009 09:19:14 -0800 (PST) Received: (qmail 8332 invoked from network); 3 Dec 2009 17:19:05 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 17:19:05 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 3 Dec 2009 10:19:04 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , "faynberg@alcatel-lucent.com" Date: Thu, 3 Dec 2009 10:19:19 -0700 Thread-Topic: [OAUTH-WG] Timestamp and sync Thread-Index: Acp0LXg3zonEP02ORry6XV77ZrksFQABBYtQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529331F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> In-Reply-To: <4B17D96E.8030002@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:19:15 -0000 R2l2aW5nIHNvbWUgb3RoZXIgZW50aXR5IGNvbnRyb2wgb3ZlciB0aGUgc2VydmVyJ3MgdGltZSBp cyBhIHNlY3VyaXR5IHJpc2suIEl0IGlzIG9idmlvdXMgd2h5IHRoZSBzZXJ2ZXIgbWF5IHdhbnQg dG8gc3luYyB3aXRoIGEgc3BlY2lmaWMgdGltZSBzZXJ2ZXIgd2hpY2ggaXQgdHJ1c3RzIGNhbm5v dCBiZSBtYW5pcHVsYXRlZC4gVGhlIGNsaWVudCB3aWxsIHRoZW4gbmVlZCB0byBzeW5jIHdpdGgg YSBzZXJ2ZXIgdGhhdCB1c2VzIHRoZSBzYW1lIHRpbWUgc291cmNlLiBJIGFncmVlIHRoYXQgaWYg c2VydmVycyBpbXBsZW1lbnQgYSByZWFzb25hYmxlIHdpbmRvdyB0aGlzIHdpbGwgbm90IGJlIGFu IGlzc3VlLCByZWdhcmRsZXNzIG9mIHdoaWNoIHRpbWUgc2VydmVyIGlzIGJlaW5nIHVzZWQsIGJ1 dCBpdCBjYW4sIGFuZCB0aGUgc2VydmVyIG1pZ2h0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBhYm91 dCB3aGljaCB0aW1lIHNlcnZlcnMgaXQgd2FudHMgdG8gdXNlLg0KDQpFSEwNCg0KIA0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFBldGVyIFNhaW50 LUFuZHJlDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwMywgMjAwOSA3OjMwIEFNDQo+IFRv OiBmYXluYmVyZ0BhbGNhdGVsLWx1Y2VudC5jb20NCj4gQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRm Lm9yZykNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gVGltZXN0YW1wIGFuZCBzeW5jDQo+IA0K PiA8aGF0IHR5cGU9J2luZGl2aWR1YWwnLz4NCj4gDQo+IE9uIDEyLzMvMDkgNzo0MyBBTSwgSWdv ciBGYXluYmVyZyB3cm90ZToNCj4gPiBJIGFtIGFjdHVhbGx5ICsxIG9uIGJvdGggb3B0aW9ucyAo YXNzdW1pbmcgdGhhdCB1c2luZyBHUFMgZm9yIHRpbWUNCj4gPiBzeW5jaHJvbml6YWlvbiBpcyBp bXBsaWNpdGx5IGluY2x1ZGVkKS4gV2hpbGUgSSBhZ3JlZSB3aXRoIEdlb3JnZSB0aGF0DQo+ID4g dGhlIGNsaWVudCdzIGNsb2NrIG1heSBub3QgYmUgbWFuaXB1bGF0ZWQgZXh0ZXJuYWxseSwgSSBk aWQgbm90IHRoaW5rDQo+ID4gdGhhdCBvcHRpb24gIzIgaW1wbGllZCB0aGF0Lg0KPiANCj4gV2hh dCBjb25mdXNlcyBtZSBhYm91dCBvcHRpb24gIzIgaXMgdGhpczogd2h5IGlzIGl0IHRoZSBPQXV0 aCBzZXJ2ZXIncw0KPiByZXNwb25zaWJpbGl0eSB0byB0ZWxsIHRoZSBPQXV0aCBjbGllbnQgYWJv dXQgYSB0cnVzdGVkIE5UUCBzZXJ2ZXI/IElNSE8gdGhlDQo+IGRldmljZSBvbiB3aGljaCB0aGUg T0F1dGggY2xpZW50IGlzIHJ1bm5pbmcgY2FuIGFscmVhZHkgZGlzY292ZXIgTlRQIHNlcnZlcnMN Cj4gb24gaXRzIG93biwgYW5kIG5vdGhpbmcgdGhlIE9BdXRoIHNlcnZlciB0ZWxscyB0aGUgT0F1 dGggY2xpZW50IHdpbGwgaGF2ZSBhbg0KPiBzcGVjaWFsIGluZmx1ZW5jZSBoZXJlLg0KPiANCj4g L3BzYQ0KDQo= From lindner@inuus.com Thu Dec 3 09:23:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69AA03A672F for ; Thu, 3 Dec 2009 09:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PUtG2o0PQfs for ; Thu, 3 Dec 2009 09:23:11 -0800 (PST) Received: from mail-pz0-f187.google.com (mail-pz0-f187.google.com [209.85.222.187]) by core3.amsl.com (Postfix) with ESMTP id 79F7B3A677D for ; Thu, 3 Dec 2009 09:23:11 -0800 (PST) Received: by pzk17 with SMTP id 17so1528886pzk.6 for ; Thu, 03 Dec 2009 09:23:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.61.19 with SMTP id j19mr225241wfa.201.1259860980392; Thu, 03 Dec 2009 09:23:00 -0800 (PST) In-Reply-To: <1D38D21A-D81F-4E7C-A14C-C75368A0B725@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> <4B17DCAC.9060201@gmail.com> <4B17DE3D.3000204@aol.com> <1D38D21A-D81F-4E7C-A14C-C75368A0B725@hueniverse.com> Date: Thu, 3 Dec 2009 09:23:00 -0800 Message-ID: From: Paul Lindner To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636e0a6b233e3130479d63e2f Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:23:12 -0000 --001636e0a6b233e3130479d63e2f Content-Type: text/plain; charset=ISO-8859-1 How does this relate to the OAuth Problem Reporting extension? *timestamp_refused * the oauth_timestamp value is unacceptable to the Service Provider. In this case, the response SHOULD also contain an oauth_acceptable_timestamps parameter (described below). The parameter named *oauth_acceptable_timestamps* consists of two numbers in decimal notation, separated by '-' (hyphen). It's the range of timestamps acceptable to the sender. That is, it means the sender will currently accept an oauth_timestamp that's not less than the first number and not greater than the second number. If the client sees this error it can adjust the skew based on the server's clock, not some arbitrary NTP server... On Thu, Dec 3, 2009 at 8:55 AM, Eran Hammer-Lahav wrote: > Just use the NTP data to calculate the skew. No need to change the OS > level clock. That was not implied in my list. > > EHL > > On Dec 3, 2009, at 7:50, "George Fletcher" wrote: > > > But what can the client do with that message? Should the client modify > > the OS settings of the device to start syncing the clock? > > > > Thanks, > > George > > > > Paul Madsen wrote: > >> Isn the point of #2 to allow the server to indicate to the client > >> 'Hey > >> use NTP - perhaps this server' when it is clear that the client wasnt > >> already doing so? > >> > >> Peter Saint-Andre wrote: > >>> > >>> > >>> On 12/3/09 7:43 AM, Igor Faynberg wrote: > >>> > >>>> I am actually +1 on both options (assuming that using GPS for time > >>>> synchronizaion is implicitly included). While I agree with George > >>>> that > >>>> the client's clock may not be manipulated externally, I did not > >>>> think > >>>> that option #2 implied that. > >>>> > >>> > >>> What confuses me about option #2 is this: why is it the OAuth > >>> server's > >>> responsibility to tell the OAuth client about a trusted NTP > >>> server? IMHO > >>> the device on which the OAuth client is running can already > >>> discover NTP > >>> servers on its own, and nothing the OAuth server tells the OAuth > >>> client > >>> will have an special influence here. > >>> > >>> /psa > >>> > >>> > >>> --- > >>> --- > >>> ------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> --- > >> --------------------------------------------------------------------- > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001636e0a6b233e3130479d63e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How does this relate to the OAuth Problem Reporting extension?

timestamp_refuse= d=A0
the oauth_timestamp value is unacceptable to the Service= Provider. In this case, the response SHOULD also contain an oauth_acceptab= le_timestamps parameter (described below).

The parameter named=A0oauth_acceptable_timestamps=A0co= nsists of two numbers in decimal notation, separated by '-' (hyphen= ). It's the range of timestamps acceptable to the sender. That is, it m= eans the sender will currently accept an oauth_timestamp that's not les= s than the first number and not greater than the second number.

If the client sees this error = it can adjust the skew based on the server's clock, not some arbitrary = NTP server...


On Th= u, Dec 3, 2009 at 8:55 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Just use the NTP data to calculate the skew= . No need to change the OS
level clock. That was not implied in my list.

EHL

On Dec 3, 2009, at 7:50, "George Fletcher" <gffletch@aol.com> wrote:

> But what can the client do with that message? Should the client modify=
> the OS settings of the device to start syncing the clock?
>
> Thanks,
> George
>
> Paul Madsen wrote:
>> Isn the point of #2 to allow the server to indicate to the client<= br> >> 'Hey
>> use NTP - perhaps this server' when it is clear that the clien= t wasnt
>> already doing so?
>>
>> Peter Saint-Andre wrote:
>>> <hat type=3D'individual'/>
>>>
>>> On 12/3/09 7:43 AM, Igor Faynberg wrote:
>>>
>>>> I am actually +1 on both options (assuming that using GPS = for time
>>>> synchronizaion is implicitly included). While I agree with= George
>>>> that
>>>> the client's clock may not be manipulated externally, = I did not
>>>> think
>>>> that option #2 implied that.
>>>>
>>>
>>> What confuses me about option #2 is this: why is it the OAuth<= br> >>> server's
>>> responsibility to tell the OAuth client about a trusted NTP >>> server? IMHO
>>> the device on which the OAuth client is running can already >>> discover NTP
>>> servers on its own, and nothing the OAuth server tells the OAu= th
>>> client
>>> will have an special influence here.
>>>
>>> /psa
>>>
>>>
>>> ---
>>> ---
>>> --------------------------------------------------------------= ----
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> ---
>> ------------------------------------------------------------------= ---
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--001636e0a6b233e3130479d63e2f-- From benl@google.com Thu Dec 3 09:29:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC413A6984 for ; Thu, 3 Dec 2009 09:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpTTGscWdkw5 for ; Thu, 3 Dec 2009 09:29:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id D35A33A672F for ; Thu, 3 Dec 2009 09:29:06 -0800 (PST) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id nB3HSwbj028109 for ; Thu, 3 Dec 2009 09:28:58 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259861338; bh=vXLCCwPJ1APE/o9WcTm6uRQCLgE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gGC61HPnKslgrtqYSgbkYV5/q86MpW4Mx4Ae7xXpLnwSAKng0TIhSfbxOVSpx/UZr kADmMbjUneiXKhkDNKPfw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=DuKxyQa738qMKWBoHnp6uisXeszfieusNGPdc58S4rmKyDYhxfJWtgCagzcnXEAq1 KCn/YkVbgLd5frxs1Ibjg== Received: from ywh37 (ywh37.prod.google.com [10.192.8.37]) by zps76.corp.google.com with ESMTP id nB3HSTe6026160 for ; Thu, 3 Dec 2009 09:28:56 -0800 Received: by ywh37 with SMTP id 37so1418968ywh.17 for ; Thu, 03 Dec 2009 09:28:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.246.3 with SMTP id t3mr3310224ybh.256.1259861331633; Thu, 03 Dec 2009 09:28:51 -0800 (PST) In-Reply-To: <1D38D21A-D81F-4E7C-A14C-C75368A0B725@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> <4B17DCAC.9060201@gmail.com> <4B17DE3D.3000204@aol.com> <1D38D21A-D81F-4E7C-A14C-C75368A0B725@hueniverse.com> Date: Thu, 3 Dec 2009 09:28:51 -0800 Message-ID: <1b587cab0912030928n722399b3g9fe4d0ea2139c1b0@mail.gmail.com> From: Ben Laurie To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:29:07 -0000 On Thu, Dec 3, 2009 at 8:55 AM, Eran Hammer-Lahav wrote: > Just use the NTP data to calculate the skew. No need to change the OS > level clock. That was not implied in my list. If the server is the one that is not synced, then pointing the client at an NTP server gets you nowhere. Seems far more sensible to just have the server tell the client what time it thinks it is. > > EHL > > On Dec 3, 2009, at 7:50, "George Fletcher" wrote: > >> But what can the client do with that message? Should the client modify >> the OS settings of the device to start syncing the clock? >> >> Thanks, >> George >> >> Paul Madsen wrote: >>> Isn the point of #2 to allow the server to indicate to the client >>> 'Hey >>> use NTP - perhaps this server' when it is clear that the client wasnt >>> already doing so? >>> >>> Peter Saint-Andre wrote: >>>> >>>> >>>> On 12/3/09 7:43 AM, Igor Faynberg wrote: >>>> >>>>> I am actually +1 on both options (assuming that using GPS for time >>>>> synchronizaion is implicitly included). While I agree with George >>>>> that >>>>> the client's clock may not be manipulated externally, I did not >>>>> think >>>>> that option #2 implied that. >>>>> >>>> >>>> What confuses me about option #2 is this: why is it the OAuth >>>> server's >>>> responsibility to tell the OAuth client about a trusted NTP >>>> server? IMHO >>>> the device on which the OAuth client is running can already >>>> discover NTP >>>> servers on its own, and nothing the OAuth server tells the OAuth >>>> client >>>> will have an special influence here. >>>> >>>> /psa >>>> >>>> >>>> --- >>>> --- >>>> ------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> --- >>> --------------------------------------------------------------------- >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Thu Dec 3 09:37:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AC83A69E7 for ; Thu, 3 Dec 2009 09:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaY42kUUK81d for ; Thu, 3 Dec 2009 09:37:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 430303A6801 for ; Thu, 3 Dec 2009 09:37:02 -0800 (PST) Received: from spaceape7.eur.corp.google.com (spaceape7.eur.corp.google.com [172.28.16.141]) by smtp-out.google.com with ESMTP id nB3Haqfl015283 for ; Thu, 3 Dec 2009 17:36:52 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259861812; bh=YYG51y1f6iXl4BjEhhCu7r0JMT0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=oiLpYvKYIu0G39O4Ih2HNtfqXoDn3PCCGiAujETG5jrLqjo1n8Ai/p86et5kfVXMj E159L5geouuhDy4M/wyTA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=NA57Nk8lu/eiR/aceC3f5eay7GNNdemeuo3Ujo47XNV5Jv8BVXXx+seuHXEMQt/1U oH13TSFD3VoI/96SsjjIQ== Received: from pwi6 (pwi6.prod.google.com [10.241.219.6]) by spaceape7.eur.corp.google.com with ESMTP id nB3HaeLH028806 for ; Thu, 3 Dec 2009 09:36:50 -0800 Received: by pwi6 with SMTP id 6so1398247pwi.7 for ; Thu, 03 Dec 2009 09:36:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.201.3 with SMTP id y3mr121173rvf.288.1259861809362; Thu, 03 Dec 2009 09:36:49 -0800 (PST) In-Reply-To: <1b587cab0912030928n722399b3g9fe4d0ea2139c1b0@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> <4B17DCAC.9060201@gmail.com> <4B17DE3D.3000204@aol.com> <1D38D21A-D81F-4E7C-A14C-C75368A0B725@hueniverse.com> <1b587cab0912030928n722399b3g9fe4d0ea2139c1b0@mail.gmail.com> Date: Thu, 3 Dec 2009 09:36:49 -0800 Message-ID: From: Brian Eaton To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:37:03 -0000 On Thu, Dec 3, 2009 at 9:28 AM, Ben Laurie wrote: > If the server is the one that is not synced, then pointing the client > at an NTP server gets you nowhere. Seems far more sensible to just > have the server tell the client what time it thinks it is. Agreed, let's just have the server tell the client the timestamp it wants to use. That's what people are doing in the wild already. (And +1 to George's comment about this being a real problem, we've seen it too.) Cheers, Brian From eran@hueniverse.com Thu Dec 3 09:39:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F173728C150 for ; Thu, 3 Dec 2009 09:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q192m2KjoA+a for ; Thu, 3 Dec 2009 09:39:51 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BE33528C156 for ; Thu, 3 Dec 2009 09:39:51 -0800 (PST) Received: (qmail 4084 invoked from network); 3 Dec 2009 17:39:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 17:39:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 3 Dec 2009 10:39:40 -0700 From: Eran Hammer-Lahav To: Paul Lindner Date: Thu, 3 Dec 2009 10:39:53 -0700 Thread-Topic: [OAUTH-WG] Timestamp and sync Thread-Index: Acp0PUSDJJa54L7eRJyR369b+T4p/wAAiy4g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293332@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> <4B17DCAC.9060201@gmail.com> <4B17DE3D.3000204@aol.com> <1D38D21A-D81F-4E7C-A14C-C75368A0B725@hueniverse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785293332P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 17:39:53 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785293332P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It relates indirectly. The problem reporting extension provides one way to = implement #1. However, since we are proposing a new auth scheme, we are goi= ng to revisit error codes anyway. EHL From: Paul Lindner [mailto:lindner@inuus.com] Sent: Thursday, December 03, 2009 9:23 AM To: Eran Hammer-Lahav Cc: George Fletcher; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Timestamp and sync How does this relate to the OAuth Problem Reporting extension? timestamp_refused the oauth_timestamp value is unacceptable to the Service Provider. In this = case, the response SHOULD also contain an oauth_acceptable_timestamps param= eter (described below). The parameter named oauth_acceptable_timestamps consists of two numbers in = decimal notation, separated by '-' (hyphen). It's the range of timestamps a= cceptable to the sender. That is, it means the sender will currently accept= an oauth_timestamp that's not less than the first number and not greater t= han the second number. If the client sees this error it can adjust the skew based on the server's = clock, not some arbitrary NTP server... On Thu, Dec 3, 2009 at 8:55 AM, Eran Hammer-Lahav > wrote: Just use the NTP data to calculate the skew. No need to change the OS level clock. That was not implied in my list. EHL On Dec 3, 2009, at 7:50, "George Fletcher" > wrote: > But what can the client do with that message? Should the client modify > the OS settings of the device to start syncing the clock? > > Thanks, > George > > Paul Madsen wrote: >> Isn the point of #2 to allow the server to indicate to the client >> 'Hey >> use NTP - perhaps this server' when it is clear that the client wasnt >> already doing so? >> >> Peter Saint-Andre wrote: >>> >>> >>> On 12/3/09 7:43 AM, Igor Faynberg wrote: >>> >>>> I am actually +1 on both options (assuming that using GPS for time >>>> synchronizaion is implicitly included). While I agree with George >>>> that >>>> the client's clock may not be manipulated externally, I did not >>>> think >>>> that option #2 implied that. >>>> >>> >>> What confuses me about option #2 is this: why is it the OAuth >>> server's >>> responsibility to tell the OAuth client about a trusted NTP >>> server? IMHO >>> the device on which the OAuth client is running can already >>> discover NTP >>> servers on its own, and nothing the OAuth server tells the OAuth >>> client >>> will have an special influence here. >>> >>> /psa >>> >>> >>> --- >>> --- >>> ------------------------------------------------------------------ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> --- >> --------------------------------------------------------------------- >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343785293332P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It relate= s indirectly. The problem reporting extension provides one way to implement= #1. However, since we are proposing a new auth scheme, we are going to rev= isit error codes anyway.

<= o:p> 

EHL

 

From: Paul Lindner [mailto:lindner@inuus.com] Sent: Thursday, December 03, 2009 9:23 AM
To: Eran Hammer= -Lahav
Cc: George Fletcher; OAuth WG (oauth@ietf.org)
Subje= ct: Re: [OAUTH-WG] Timestamp and sync

=

 

How does thi= s relate to the OAuth Problem Reporting extension?

 

timestamp_refused 

=

the oauth= _timestamp value is unacceptable to the Service Provider. In this case, the= response SHOULD also contain an oauth_acceptable_timestamps parameter (des= cribed below).

&= nbsp;

The parameter named oauth_acceptable_timestamps&= nbsp;consists of two numbers in decimal notation, separated by '-' (hyphen)= . It's the range of timestamps acceptable to the sender. That is, it means = the sender will currently accept an oauth_timestamp that's not less than th= e first number and not greater than the second number.

If the client sees this error= it can adjust the skew based on the server's clock, not some arbitrary NTP= server...

 <= /p>

 

On Thu, Dec 3, 2009 at 8:55 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

<= p class=3DMsoNormal>Just use the NTP data to calculate the skew. No need to= change the OS
level clock. That was not implied in my list.

EHL


On Dec 3, 2009, at 7:50, "George Fletcher" <gffletch@aol.com> wrote:

> Bu= t what can the client do with that message? Should the client modify
>= ; the OS settings of the device to start syncing the clock?
>
>= Thanks,
> George
>
> Paul Madsen wrote:
>> Isn = the point of #2 to allow the server to indicate to the client
>> '= Hey
>> use NTP - perhaps this server' when it is clear that the cl= ient wasnt
>> already doing so?
>>
>> Peter Sain= t-Andre wrote:
>>> <hat type=3D'individual'/>
>>= >
>>> On 12/3/09 7:43 AM, Igor Faynberg wrote:
>>&g= t;
>>>> I am actually +1 on both options (assuming that usin= g GPS for time
>>>> synchronizaion is implicitly included). = While I agree with George
>>>> that
>>>> the = client's clock may not be manipulated externally, I did not
>>>= > think
>>>> that option #2 implied that.
>>>= >
>>>
>>> What confuses me about option #2 is th= is: why is it the OAuth
>>> server's
>>> responsibi= lity to tell the OAuth client about a trusted NTP
>>> server? I= MHO
>>> the device on which the OAuth client is running can alr= eady
>>> discover NTP
>>> servers on its own, and n= othing the OAuth server tells the OAuth
>>> client
>>&= gt; will have an special influence here.
>>>
>>> /p= sa
>>>
>>>
>>> ---
>>> ---<= br>>>> -----------------------------------------------------------= -------
>>>
>>> ___________________________________= ____________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.o= rg/mailman/listinfo/oauth
>>>
>> ---
>> -= --------------------------------------------------------------------
>= ;>
>> _______________________________________________
>&g= t; OAuth mailing list
>> OAuth@i= etf.org
>> https://www.ietf.org/mailman/listinfo/oauth
&= gt;>
> _______________________________________________
> OAu= th mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________= ________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth

 =

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785293332P3PW5EX1MB01E_-- From quigley@emerose.com Thu Dec 3 13:22:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F793A696C for ; Thu, 3 Dec 2009 13:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC89eY8WKG66 for ; Thu, 3 Dec 2009 13:22:18 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 8A47F3A696B for ; Thu, 3 Dec 2009 13:22:16 -0800 (PST) Received: by ywh15 with SMTP id 15so1793837ywh.5 for ; Thu, 03 Dec 2009 13:22:05 -0800 (PST) Received: by 10.101.211.36 with SMTP id n36mr2940134anq.93.1259875324322; Thu, 03 Dec 2009 13:22:04 -0800 (PST) Received: from ?10.0.1.2? (75-101-96-3.dsl.static.sonic.net [75.101.96.3]) by mx.google.com with ESMTPS id 5sm1236335yxd.17.2009.12.03.13.22.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 13:22:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Sam Quigley In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 3 Dec 2009 13:21:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1077) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:22:19 -0000 On Dec 2, 2009, at 10:52 PM, Eran Hammer-Lahav wrote: > The two main options are: >=20 > 1. Create a new simple mechanism for clock sync (via error message or = API call). > 2. Have the server point the client to a trusted time service (which = the server can run if desired), using a protocol we pick such as NTP = (RFC 1305). Isn't there a third option, actually? Namely: drop the requirement for = timestamps altogether. As long as the requirement for nonces remains, the protocol will = maintain its protection against replay attacks. Is there anything else = that timestamps are necessary for? -sq= From jonathan_moore@comcast.com Thu Dec 3 13:26:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3073A696B for ; Thu, 3 Dec 2009 13:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0kuS9sxDnGP for ; Thu, 3 Dec 2009 13:26:56 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 414703A62C1 for ; Thu, 3 Dec 2009 13:26:56 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.83569833; Thu, 03 Dec 2009 16:26:32 -0500 Received: from PACORPEXCMB03.cable.comcast.com ([24.40.15.85]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 16:26:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Dec 2009 16:26:32 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Timestamp and sync Thread-Index: Acp0XrIrldxdLx25T8C2i/UZnj6ZVQAAC8IQ References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Moore, Jonathan (CIM)" To: "Sam Quigley" , "Eran Hammer-Lahav" X-OriginalArrivalTime: 03 Dec 2009 21:26:33.0647 (UTC) FILETIME=[497303F0:01CA745F] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:26:57 -0000 Don't you need a timestamp with a nonce to bound how long you have to remember a used nonce on the server side? i.e. if I have a policy that I only accept requests whose timestamp is less than 5 minutes old, then I never have to remember any particular nonce for longer than 5 minutes. This lets me bound the server resources that are necessary for "remembering" all the nonces, from a capacity planning point of view. Jon ........ Jon Moore Comcast Interactive Media -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Sam Quigley Sent: Thursday, December 03, 2009 4:22 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Timestamp and sync On Dec 2, 2009, at 10:52 PM, Eran Hammer-Lahav wrote: > The two main options are: >=20 > 1. Create a new simple mechanism for clock sync (via error message or API call). > 2. Have the server point the client to a trusted time service (which the server can run if desired), using a protocol we pick such as NTP (RFC 1305). Isn't there a third option, actually? Namely: drop the requirement for timestamps altogether. As long as the requirement for nonces remains, the protocol will maintain its protection against replay attacks. Is there anything else that timestamps are necessary for? -sq _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Dec 3 13:27:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883F428C1C7 for ; Thu, 3 Dec 2009 13:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdZfSz-dIQZ5 for ; Thu, 3 Dec 2009 13:27:12 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CA6D828C1CC for ; Thu, 3 Dec 2009 13:27:12 -0800 (PST) Received: (qmail 18902 invoked from network); 3 Dec 2009 21:27:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 21:27:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 14:27:01 -0700 From: Eran Hammer-Lahav To: Sam Quigley Date: Thu, 3 Dec 2009 14:27:15 -0700 Thread-Topic: [OAUTH-WG] Timestamp and sync Thread-Index: Acp0XqrgCm7onsg0RYCcnTSnWoxpzwAAH/wg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529345A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:27:13 -0000 Technically no, but without a timestamp component, the server will have to = save every nonce ever used to prevent replay. Making nonce structure consis= tent (by specifying a timestamp component) helps interoperability by removi= ng the need for servers to make up their own nonce structure. EHL > -----Original Message----- > From: Sam Quigley [mailto:quigley@emerose.com] > Sent: Thursday, December 03, 2009 1:22 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Timestamp and sync >=20 > On Dec 2, 2009, at 10:52 PM, Eran Hammer-Lahav wrote: >=20 > > The two main options are: > > > > 1. Create a new simple mechanism for clock sync (via error message or A= PI > call). > > 2. Have the server point the client to a trusted time service (which th= e > server can run if desired), using a protocol we pick such as NTP (RFC 130= 5). >=20 > Isn't there a third option, actually? Namely: drop the requirement for > timestamps altogether. >=20 > As long as the requirement for nonces remains, the protocol will maintain= its > protection against replay attacks. Is there anything else that timestamp= s are > necessary for? >=20 > -sq From email@pbryan.net Thu Dec 3 13:32:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9ABC28C1E3 for ; Thu, 3 Dec 2009 13:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhKbLBb26iVH for ; Thu, 3 Dec 2009 13:32:49 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 254FB28C1DD for ; Thu, 3 Dec 2009 13:32:48 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 4AD836154 for ; Thu, 3 Dec 2009 21:32:40 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Dec 2009 13:32:25 -0800 Message-ID: <1259875945.6142.535.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:32:50 -0000 On Wed, 2009-12-02 at 23:52 -0700, Eran Hammer-Lahav wrote: > I am going to base the new HMAC method closely after the current > HMAC-SHA1 method (SHA1 will be negotiable and might be replaced as the > base protocol to something more current, but this is off topic). This > means we will need to deal with timestamps to prevent replay attacks. > > Tim Polk made a comment today on the 1.0 RFC draft that the server > should be able to simply tell the client to use a trusted time service > for clock synchronization. Since timestamp management has been a > problematic issue for many, I feel we need to address it in the new > spec to ensure it will not cause interop issues. > > The two main options are: > > 1. Create a new simple mechanism for clock sync (via error message or > API call). +1. At least the client can compare what the server has to what it has to determine the issue, and could even potentially skew its time reporting to the server based on the calculated difference. > 2. Have the server point the client to a trusted time service (which > the server can run if desired), using a protocol we pick such as NTP > (RFC 1305). -1. If we presume the world runs on UTC, then isn't what NTP server to use irrelevant? It's hard to fathom an OAuth server saying to a client, "hey, use this non-UTC time source!" I think the protocol still needs to cope with some drift in timestamps/nonces, so I don't even think which stratum server to use would even be pertinent. > Comments? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From email@pbryan.net Thu Dec 3 13:35:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A82783A68E2 for ; Thu, 3 Dec 2009 13:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUg38aJH8Qt6 for ; Thu, 3 Dec 2009 13:35:35 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id E42213A6887 for ; Thu, 3 Dec 2009 13:35:35 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 525DC6154 for ; Thu, 3 Dec 2009 21:35:27 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Dec 2009 13:35:13 -0800 Message-ID: <1259876113.6142.537.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:35:36 -0000 On Thu, 2009-12-03 at 13:21 -0800, Sam Quigley wrote: > On Dec 2, 2009, at 10:52 PM, Eran Hammer-Lahav wrote: > > > The two main options are: > > > > 1. Create a new simple mechanism for clock sync (via error message > or API call). > > 2. Have the server point the client to a trusted time service (which > the server can run if desired), using a protocol we pick such as NTP > (RFC 1305). > > Isn't there a third option, actually? Namely: drop the requirement > for timestamps altogether. I don't think this is a good option, as given the assumptions that timestamps are monotonically increasing, you only have to retain a limited set of nonces. If you drop timestamp, then you'd conceivably have to retain all nonces used for the lifetime of the key/token. > As long as the requirement for nonces remains, the protocol will > maintain its protection against replay attacks. Is there anything > else that timestamps are necessary for? > > -sq > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Dec 3 13:40:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A1BE28C1CF for ; Thu, 3 Dec 2009 13:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT3L61heCGCX for ; Thu, 3 Dec 2009 13:40:18 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1789B3A68D0 for ; Thu, 3 Dec 2009 13:40:18 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2911640337; Thu, 3 Dec 2009 14:40:09 -0700 (MST) Message-ID: <4B183037.9050201@stpeter.im> Date: Thu, 03 Dec 2009 14:40:07 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stephen Farrell References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1637EB.5080502@cs.tcd.ie> In-Reply-To: <4B1637EB.5080502@cs.tcd.ie> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090300040102040605060305" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:40:19 -0000 This is a cryptographically signed message in MIME format. --------------ms090300040102040605060305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/2/09 2:48 AM, Stephen Farrell wrote: > I think we'll need an analysis of where we end up wanting TLS > for the protocols we produce. I wouldn't expect any big > surprises, but right now I don't think we can be sure since > things seems to be in flux to some extent. > > Then, I'd be for saying that TLS MUST be used for those operations. > However, I can well believe that there may be some niches where > using TLS isn't easy, so I could live with something like: it MUST > be possible to use TLS, and that deployments SHOULD use it, with > guidance as to the type of scenario where we think TLS really > has to be turned on, and maybe text about why sometimes people > can't do that. > > So I don't think we can finish this discussion at this stage. I think we can: 1. Software MUST implement TLS 2. Services should deploy TLS Traditionally, RFCs enforce conformance requirements only on software implementations, not on service deployments. And here there seems to be enough variation in deployment land that "should deploy" is as far as we can go. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms090300040102040605060305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzIxNDAwN1owIwYJKoZIhvcNAQkEMRYEFP2ZGeJsOqfGXdprI8sd 0QO2KJ3NMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEASyN8HmCQXX2bF3x3wUET+5/V6F3OUvYQKqQSvQ/b ImPSelw6Va78jkUdqnIAnNj0cj1V8xICv3AjwlgoE7vUoWO6wjjH5TUMviJoe5zvxgzXyAEs 7GLeHnRoVhM3dvSj9w9EPqcD4UfN8S3vhBGiLEhbysgps84xVRuGhCYTrJWafnOW9C3vZ6fv dP5y16Gry+tcRR8U+R/8qvkFuSJJHq7eZo/R1eU/V68zNXbMNOTv5d8EXD5rHUKqGz3j2In8 osLSVKIPDI4rEITVi/iYChtMynTDe8unYWrQTInNbQq3kejl9Ir3Xgt9khCbEEyZyF8jTePK J9vEe5P7lO6PbAAAAAAAAA== --------------ms090300040102040605060305-- From stpeter@stpeter.im Thu Dec 3 13:43:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CD628C1B8 for ; Thu, 3 Dec 2009 13:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBxWXVXu3m06 for ; Thu, 3 Dec 2009 13:43:33 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2A2C328C18F for ; Thu, 3 Dec 2009 13:43:33 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EC0E440337; Thu, 3 Dec 2009 14:43:23 -0700 (MST) Message-ID: <4B1830FA.7000402@stpeter.im> Date: Thu, 03 Dec 2009 14:43:22 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Zeltsan, Zachary (Zachary)" References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5710F82C0E73B04FA559560098BF95B124EEB6B910@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B124EEB6B910@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000308040609070506050404" Cc: Dick Hardt , "oauth@ietf.org" Subject: [OAUTH-WG] multi-level delegation (was: Re: why are we signing?; OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 21:43:34 -0000 This is a cryptographically signed message in MIME format. --------------ms000308040609070506050404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/2/09 9:15 AM, Zeltsan, Zachary (Zachary) wrote: > On Tue, Dec 1, 2009 at 1:23 PM, Mike Malone > wrote: > >> On Tue, Dec 1, 2009 at 8:52 AM, John Panzer >> wrote: >>> On Mon, Nov 30, 2009 at 2:32 PM, Mike Malone >> wrote: >>>> On Mon, Nov 30, 2009 at 11:17 AM, Dick Hardt >>>> wrote: >>>>> On 2009-11-13, at 7:21 AM, Eran Hammer-Lahav wrote: >>>>>> I for one, see great value in offering some form of >> crypto-based >>>>>> security for cases where TLS is not suitable. >>>>> Are these use cases enumerated somewhere? >>>> I'm not completely opposed to the TLS route, but since you >>>> asked... off the top of my head, here are a couple drawbacks to >>>> using TLS instead of signing: - Bigger burden on developers who >>>> need to debug this stuff (i.e., you can't sniff your own >>>> traffic to debug requests & responses). - Properly setting up >>>> TLS can be complicated and expensive. For developers who don't >>>> have a lot of ops skills the barrier >> may be too >>>> high. - You can no longer pass around signed URLs as another >>>> level of delegation (a use case that I use regularly for making >>>> XHR & POST requests from the browser). This could be a >>>> non-issue if >> some other >>>> mechanism for fourth-party delegation existed. >>>> >>> Can you elaborate on the above? For OAuth, signatures (bound to >>> a particular Consumer Secret that can't be leaked to >> subcontractors) is >>> a barrier to multi-level delegation. >> Right, but you can do poor-man's delegation by signing a URL and >> passing it off to a third (er, fourth) party to use. I've seen this >> most often with web apps, where the app (the OAuth Consumer) wants >> to make a request to the Provider directly from the browser (e.g., >> POSTing a large file). They can't sign the URL in javascript >> without compromising the Consumer Secret, so the the URL is signed >> server side and passed to the browser for use. > > There is another way to do a multi-level delegation without revealing > a client's secret. The method described in the draft > http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-00 along > with a use case for re-delegating authorization. In my opinion, the > multi-level delegation should be on a new charter. (This makes this > message relevant to the thread with the subject "OAuth 2.0 / > Charter") Without getting into the whole issue of re-chartering (yet), I do think it would be helpful to have more discussion about the draft you mention (because we know that multi-level delegation, formerly known as "four-legged auth", is something that people are interested in). Feel free to start a separate thread about that, or reply to this message. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms000308040609070506050404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzIxNDMyMlowIwYJKoZIhvcNAQkEMRYEFKUMqThCe+YzoK9TQUfV S4qjIYpHMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAj0iOqsBJaIJgrQyfrb58/kyqrcJtfbnuV1abm8VM HRAeh5I/W9aUpYtu2SNtX7Bs0N2WJoIw+0igxPKrMpZU4FcnwnOQExUnLIlExAqpjOw7+ABE kGK+z7TLWuyBar446tJc+WS+pNdtbsWWhShuVSD2ZSu/3mZR0pCYvFnJYsx3RoNueaZwdqCK cCFXWAvkxAStX79Ke7Z5YIsYBv+M7O3eANMDEN3H5L7Jnyf+Ja1xBoSqwwsM/Z9LwgCg6m1E kkSQJA5F9ZItBl3/BzoNHN9IBi3kwRUj47mLjCpGZ6NrV1UAZxvxZqlKUKqZGcL9FGb4z1Vf F6xUw2kkPrQ5MgAAAAAAAA== --------------ms000308040609070506050404-- From quigley@emerose.com Thu Dec 3 14:06:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090BF3A6A60 for ; Thu, 3 Dec 2009 14:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPmtDbAwpQ14 for ; Thu, 3 Dec 2009 14:06:27 -0800 (PST) Received: from mail-pz0-f187.google.com (mail-pz0-f187.google.com [209.85.222.187]) by core3.amsl.com (Postfix) with ESMTP id 022E73A6976 for ; Thu, 3 Dec 2009 14:06:26 -0800 (PST) Received: by pzk17 with SMTP id 17so1825998pzk.6 for ; Thu, 03 Dec 2009 14:06:16 -0800 (PST) Received: by 10.114.165.15 with SMTP id n15mr2956468wae.83.1259877975988; Thu, 03 Dec 2009 14:06:15 -0800 (PST) Received: from ?10.0.1.2? (75-101-96-3.dsl.static.sonic.net [75.101.96.3]) by mx.google.com with ESMTPS id 20sm1997625pzk.9.2009.12.03.14.06.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 14:06:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Sam Quigley In-Reply-To: Date: Thu, 3 Dec 2009 14:06:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: "Moore, Jonathan (CIM)" X-Mailer: Apple Mail (2.1077) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:06:28 -0000 Fair enough; I'd forgotten about the nonce-scoping trick. What about = going the other way, and dropping nonces entirely =97 and replacing the = timestamp with a monotonically-increasing counter. (Which, in most = cases, could just be the client's timestamp.) The monotonicity would guarantee replay protection, and servers would = only need to track a few bytes per consumer=85 In case it's not obvious, what I'm worried about is that OAuth 1.0 went = too far down a slippery slope: we required nonces to prevent replay = attacks; then we added timestamps to scope nonces; now we're considering = reimplementing NTP to sync timestamps, and so on. It doesn't seem like = defeating replays ought to be such a hard problem, and I'm grasping for = alternatives=85 -sq On Dec 3, 2009, at 1:26 PM, Moore, Jonathan (CIM) wrote: > Don't you need a timestamp with a nonce to bound how long you have to > remember a used nonce on the server side? i.e. if I have a policy that = I > only accept requests whose timestamp is less than 5 minutes old, then = I > never have to remember any particular nonce for longer than 5 minutes. > This lets me bound the server resources that are necessary for > "remembering" all the nonces, from a capacity planning point of view. >=20 > Jon > ........ > Jon Moore > Comcast Interactive Media >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Sam Quigley > Sent: Thursday, December 03, 2009 4:22 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Timestamp and sync >=20 > On Dec 2, 2009, at 10:52 PM, Eran Hammer-Lahav wrote: >=20 >> The two main options are: >>=20 >> 1. Create a new simple mechanism for clock sync (via error message or > API call). >> 2. Have the server point the client to a trusted time service (which > the server can run if desired), using a protocol we pick such as NTP > (RFC 1305). >=20 > Isn't there a third option, actually? Namely: drop the requirement = for > timestamps altogether. >=20 > As long as the requirement for nonces remains, the protocol will > maintain its protection against replay attacks. Is there anything = else > that timestamps are necessary for? >=20 > -sq > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sergent@google.com Thu Dec 3 14:08:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7AD3A682E for ; Thu, 3 Dec 2009 14:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPaf+Z8mSdlv for ; Thu, 3 Dec 2009 14:08:39 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id DC7A43A67D9 for ; Thu, 3 Dec 2009 14:08:38 -0800 (PST) Received: from spaceape9.eur.corp.google.com (spaceape9.eur.corp.google.com [172.28.16.143]) by smtp-out.google.com with ESMTP id nB3M8R9s008350 for ; Thu, 3 Dec 2009 14:08:29 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259878109; bh=v/CY/y14RxgbHMXJbSYTbVRa0NE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=kmHqp7mBUZauXu1XQuahu64DoeHaDrbgGaC24uVUqyKKYwtG/7AVgiztvOVksryXn qaT/bS5jD9MFWAuRHoMzA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=WPYvMPayooyULv5UitTQgsoyyqu65U2h5zaUiyBvh03oTXMciHm2oNwJ6Fz5cRewL gIoY/chxZItp9QNEzdVvA== Received: from qw-out-2122.google.com (qwb9.prod.google.com [10.241.193.73]) by spaceape9.eur.corp.google.com with ESMTP id nB3M8OZI021131 for ; Thu, 3 Dec 2009 14:08:25 -0800 Received: by qw-out-2122.google.com with SMTP id 9so333722qwb.17 for ; Thu, 03 Dec 2009 14:08:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.93.41 with SMTP id t41mr320253qcm.81.1259878104470; Thu, 03 Dec 2009 14:08:24 -0800 (PST) In-Reply-To: <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> From: Jonathan Sergent Date: Thu, 3 Dec 2009 14:08:04 -0800 Message-ID: To: Sam Quigley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Moore, Jonathan \(CIM\)" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:08:40 -0000 Monotonically increasing counter is unnecessarily hard to do in a distributed consumer. On Thu, Dec 3, 2009 at 2:06 PM, Sam Quigley wrote: > Fair enough; I'd forgotten about the nonce-scoping trick. =A0What about g= oing the other way, and dropping nonces entirely =97 and replacing the time= stamp with a monotonically-increasing counter. =A0(Which, in most cases, co= uld just be the client's timestamp.) > > The monotonicity would guarantee replay protection, and servers would onl= y need to track a few bytes per consumer=85 > > In case it's not obvious, what I'm worried about is that OAuth 1.0 went t= oo far down a slippery slope: we required nonces to prevent replay attacks;= then we added timestamps to scope nonces; now we're considering reimplemen= ting NTP to sync timestamps, and so on. =A0It doesn't seem like defeating r= eplays ought to be such a hard problem, and I'm grasping for alternatives= =85 > > -sq > > > On Dec 3, 2009, at 1:26 PM, Moore, Jonathan (CIM) wrote: > >> Don't you need a timestamp with a nonce to bound how long you have to >> remember a used nonce on the server side? i.e. if I have a policy that I >> only accept requests whose timestamp is less than 5 minutes old, then I >> never have to remember any particular nonce for longer than 5 minutes. >> This lets me bound the server resources that are necessary for >> "remembering" all the nonces, from a capacity planning point of view. >> >> Jon >> ........ >> Jon Moore >> Comcast Interactive Media >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Sam Quigley >> Sent: Thursday, December 03, 2009 4:22 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Timestamp and sync >> >> On Dec 2, 2009, at 10:52 PM, Eran Hammer-Lahav wrote: >> >>> The two main options are: >>> >>> 1. Create a new simple mechanism for clock sync (via error message or >> API call). >>> 2. Have the server point the client to a trusted time service (which >> the server can run if desired), using a protocol we pick such as NTP >> (RFC 1305). >> >> Isn't there a third option, actually? =A0Namely: drop the requirement fo= r >> timestamps altogether. >> >> As long as the requirement for nonces remains, the protocol will >> maintain its protection against replay attacks. =A0Is there anything els= e >> that timestamps are necessary for? >> >> -sq >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From stephen.farrell@cs.tcd.ie Thu Dec 3 14:21:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B79A28C1CC for ; Thu, 3 Dec 2009 14:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.064 X-Spam-Level: X-Spam-Status: No, score=-1.064 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASoaWHNqdj4y for ; Thu, 3 Dec 2009 14:21:30 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 3C65228C1BD for ; Thu, 3 Dec 2009 14:21:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id EEA523600BB; Thu, 3 Dec 2009 22:21:19 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyLt8sWkRq1d; Thu, 3 Dec 2009 22:21:15 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id A810E3600BA; Thu, 3 Dec 2009 22:21:15 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 9AD137C326; Thu, 3 Dec 2009 22:21:15 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDlsHsU401D3; Thu, 3 Dec 2009 22:21:11 +0000 (GMT) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail01.newbay.com (Postfix) with ESMTP id 402217C322; Thu, 3 Dec 2009 22:21:11 +0000 (GMT) References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1637EB.5080502@cs.tcd.ie> <4B183037.9050201@stpeter.im> Message-Id: <828931C9-9038-4B97-AF79-7C5FA3E9CD17@cs.tcd.ie> From: Stephen Farrell To: Peter Saint-Andre In-Reply-To: <4B183037.9050201@stpeter.im> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Thu, 3 Dec 2009 22:21:07 +0000 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:21:31 -0000 On 3 Dec 2009, at 21:40, Peter Saint-Andre wrote: > > > On 12/2/09 2:48 AM, Stephen Farrell wrote: >> I think we'll need an analysis of where we end up wanting TLS >> for the protocols we produce. I wouldn't expect any big >> surprises, but right now I don't think we can be sure since >> things seems to be in flux to some extent. >> >> Then, I'd be for saying that TLS MUST be used for those operations. >> However, I can well believe that there may be some niches where >> using TLS isn't easy, so I could live with something like: it MUST >> be possible to use TLS, and that deployments SHOULD use it, with >> guidance as to the type of scenario where we think TLS really >> has to be turned on, and maybe text about why sometimes people >> can't do that. >> >> So I don't think we can finish this discussion at this stage. > > I think we can: > > 1. Software MUST implement TLS > 2. Services should deploy TLS Tend to agree. What I meant we couldn't yet do was say for exactly which operations we think TLS should be turned on, and what it means to not use TLS in those cases, S. > > Traditionally, RFCs enforce conformance requirements only on software > implementations, not on service deployments. And here there seems to > be > enough variation in deployment land that "should deploy" is as far > as we > can go. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > From email@pbryan.net Thu Dec 3 14:21:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FAEA28C1B8 for ; Thu, 3 Dec 2009 14:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1ivmw5fI9CT for ; Thu, 3 Dec 2009 14:21:44 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 9DBC73A6947 for ; Thu, 3 Dec 2009 14:21:44 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 1A11C6154 for ; Thu, 3 Dec 2009 22:21:36 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Dec 2009 14:21:21 -0800 Message-ID: <1259878881.6142.545.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:21:45 -0000 On Thu, 2009-12-03 at 14:06 -0800, Sam Quigley wrote: > Fair enough; I'd forgotten about the nonce-scoping trick. What about > going the other way, and dropping nonces entirely — and replacing the > timestamp with a monotonically-increasing counter. (Which, in most > cases, could just be the client's timestamp.) I've encountered cases where there may be multiple client instances (sharing the same consumer key)—multiple servers in a cluster for instance—and in fact needed to relax the monotonically increasing timestamp (allow for an acceptable amount of skew to accommodate multiple instances). There's also the issue of request order when near-concurrent requests are transmitted from the consumer. The Interweb allows flexible routing of requests, and one request sent just before another from the consumer could reach the server after the second. Another issue will be timestamp granularity—if the value must increase for each request, then you limit the frequency of requests to the granularity of your timestamp. Timestamp+nonce provides ways to handle these types of issues. One without the other makes these problems more difficult to handle. > The monotonicity would guarantee replay protection, and servers would > only need to track a few bytes per consumer… > > In case it's not obvious, what I'm worried about is that OAuth 1.0 > went too far down a slippery slope: we required nonces to prevent > replay attacks; then we added timestamps to scope nonces; now we're > considering reimplementing NTP to sync timestamps, and so on. It > doesn't seem like defeating replays ought to be such a hard problem, > and I'm grasping for alternatives… > > -sq > > > On Dec 3, 2009, at 1:26 PM, Moore, Jonathan (CIM) wrote: > > > Don't you need a timestamp with a nonce to bound how long you have > to > > remember a used nonce on the server side? i.e. if I have a policy > that I > > only accept requests whose timestamp is less than 5 minutes old, > then I > > never have to remember any particular nonce for longer than 5 > minutes. > > This lets me bound the server resources that are necessary for > > "remembering" all the nonces, from a capacity planning point of > view. > > > > Jon > > ........ > > Jon Moore > > Comcast Interactive Media > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > Of Sam Quigley > > Sent: Thursday, December 03, 2009 4:22 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Timestamp and sync > > > > On Dec 2, 2009, at 10:52 PM, Eran Hammer-Lahav wrote: > > > >> The two main options are: > >> > >> 1. Create a new simple mechanism for clock sync (via error message > or > > API call). > >> 2. Have the server point the client to a trusted time service > (which > > the server can run if desired), using a protocol we pick such as NTP > > (RFC 1305). > > > > Isn't there a third option, actually? Namely: drop the requirement > for > > timestamps altogether. > > > > As long as the requirement for nonces remains, the protocol will > > maintain its protection against replay attacks. Is there anything > else > > that timestamps are necessary for? > > > > -sq > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Dec 3 14:31:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98B828C1BD for ; Thu, 3 Dec 2009 14:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tLrFogpcirc for ; Thu, 3 Dec 2009 14:31:55 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D7F0728C1CC for ; Thu, 3 Dec 2009 14:31:55 -0800 (PST) Received: (qmail 17398 invoked from network); 3 Dec 2009 22:31:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 22:31:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 3 Dec 2009 15:31:34 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav , "Peter Saint-Andre (stpeter@stpeter.im)" , "Lisa Dusseault (lisa.dusseault@gmail.com)" Date: Thu, 3 Dec 2009 15:31:49 -0700 Thread-Topic: OAuth 2.0 / Charter Thread-Index: AcpwydwemcwGclDiS3iUrmJW9KSv5ADmZkKg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852934A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:31:56 -0000 After plenty of healthy discussion with the chair, AD, and working group me= mbers, I think the best way to move forward is to focus on the next working= group milestone: * Submit a document as a working group item providing the functionality of = the 2-legged HTTP authentication mechanism Which the charter provides us with complete freedom: The Working Group will also define a generally applicable HTTP authentication mechanism (i.e., browser-based "2-leg" scenario). Once this is complete we can consider its impact on the OAuth delegation co= mponent, and whether we want to replace the existing authentication with th= is new method. At that point, based on WG consensus, we might want to consi= der changes to the charter. In addition, we have enough interest on this list to discuss alternative de= legation flows as suggested by WRAP which will be submitted for WG consider= ation shortly. Discussing the new suggested flows is critical for any discu= ssion on future charter changes (if we don't agree on which flows to includ= e, we can't change the charter). I plan to submit a new individual submission I-D for the milestone above fo= r WG consideration shortly. Based on WG feedback we can decide to promote i= t to a WG draft. I will leave it up to the chair to decide how he wishes to continue based o= n my suggestions. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Saturday, November 28, 2009 11:59 PM > To: Peter Saint-Andre (stpeter@stpeter.im); Lisa Dusseault > (lisa.dusseault@gmail.com) > Cc: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] OAuth 2.0 / Charter >=20 > With the cleanup of the 1.0 specification [1] and the publication of an > informational RFC (pending IESG approval), I no longer see value in a > standard closely based on the 1.0 specification, which was the original > intention of this WG. This is also reflected by the recent interest in th= e WRAP > proposal [2]. >=20 > Instead, I think we should develop two specifications that while closely = in line > with the original plan, represent a significant shift. In other words, I = am > proposing we develop OAuth 2.0, not 1.1. >=20 > The new proposal is to develop two specifications: >=20 > 1. Token Authorization Method >=20 > An RFC 2617 Authorization header called 'Token' for authenticating reques= ts > with token-based credentials. Tokens (with optional shared-secret) are > usually used in place of other credentials (usernames, etc.) and represen= t > some combination of scope and authorization. The token method will includ= e > an extensible signature-based option based on the HMAC-SHA1 method, > and a bearer token (with optional secret) option based on the PLAINTEXT > method. The RSA option will be dropped. >=20 > 2. OAuth 2.0 >=20 > A specification based on the browser-redirection flow described in OAuth = 1.0 > as well as new methods defined in WRAP (I-D submission pending). OAuth > will be redefined to cover the authorization component only, and will no > longer be bound to a single authentication method. This will make OAuth > immediately useful for other protocols than HTTP (while HTTP will be used= to > obtain tokens, tokens will be useful in other protocols, not just with th= e HTTP > and Token method). >=20 > --- >=20 > While the current charter allows much of this work, it contradicts its sp= irit and > the understanding reached when we created the working group. >=20 > I would like to ask: >=20 > - Is this approach favorable by the group? > - Do we need to adjust the language in the charter to support? >=20 > EHL >=20 > [1] http://tools.ietf.org/html/draft-hammer-oauth > [2] http://bit.ly/oauth-wrap >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Thu Dec 3 14:32:05 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2CB28C1D6 for ; Thu, 3 Dec 2009 14:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqW744Q2iqNR for ; Thu, 3 Dec 2009 14:32:04 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6166128C1C1 for ; Thu, 3 Dec 2009 14:32:04 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 24C3140337; Thu, 3 Dec 2009 15:31:53 -0700 (MST) Message-ID: <4B183C57.4090100@stpeter.im> Date: Thu, 03 Dec 2009 15:31:51 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Idan Gazit References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> In-Reply-To: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040504010402030803080009" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:32:05 -0000 This is a cryptographically signed message in MIME format. --------------ms040504010402030803080009 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/1/09 5:21 PM, Idan Gazit wrote: > Hey folks, > > I redrew/updated an old diagram > (http://documentation.fring.com/images/1/11/Oauth_diagram.png) outlining > the OAuth authentication flow. The old one didn't reflect the changes in > 1.0a. > > The updated diagrams are here: > > http://s3.pixane.com/Oauth_diagram.png > http://s3.pixane.com/Oauth_diagram.pdf Your diagrams are very helpful. Now we just need to convert them to ASCII art for inclusion in an Internet-Draft. ;-) > Please feel free to use them, I hereby place them in the public domain. That's cool, too! Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms040504010402030803080009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzIyMzE1MVowIwYJKoZIhvcNAQkEMRYEFBhVoLwQKmQiNiJoHgPs CzbLGQtQMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAf6VRsd2uYpH/ZeVLmbCrgFmqqxVvDZvZ1ci7P4Ci 0adQDQ+jMsjEH4Ve0vht3wzEKJWabU5o6SNivaTuWJ+y2EJ8iPNcDd8agZJNTRiSEtAOBY8B fUET9XaW3Jfjf8E4zXO+qY0KqPgZ9X36ABYKuixtW4k/FYKP3crot6Ve1tR3n+VdOajiSmxv hhuXDc+ZEnM5BZPwOYYdavnoO6WIEOI7ljd3+OlNVTbjf/z4BLQpYfz5CGGHh2OYneijYhtE WCZpuHbtQxUsbuy9+9rjClQtvc6xeNfxtV5rJuU/N9rgZ1LDAiStyR5jZMvgpTt4XotE5PAC AZ2lhuhWi4q3xwAAAAAAAA== --------------ms040504010402030803080009-- From stpeter@stpeter.im Thu Dec 3 14:40:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6D628C199 for ; Thu, 3 Dec 2009 14:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbtOMwjB+ChK for ; Thu, 3 Dec 2009 14:40:48 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CBFAA3A696C for ; Thu, 3 Dec 2009 14:40:48 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 164D540337; Thu, 3 Dec 2009 15:40:38 -0700 (MST) Message-ID: <4B183E65.2000207@stpeter.im> Date: Thu, 03 Dec 2009 15:40:37 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852934A3@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080407050304070904060309" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:40:50 -0000 This is a cryptographically signed message in MIME format. --------------ms080407050304070904060309 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Eran, your suggestions are most welcome, and consistent with my sense of: 1. discussions on this list 2. the shifting landscape of OAuth technologies (not that landscape shifts are necessarily a bad thing, because in this case they indicate greater and IMHO more serious interest) 3. my conversations with people in the IETF and OAuth communities (and I might reach out directly to more WG participants to gain more input) Once we have individual I-Ds for authentication (the token draft you're working on) and alternative delegation flows (from the WRAP work, and perhaps from other WG participants as well), I agree that we can have a more fruitful discussion about next steps. I expect that to happen in the next two weeks. Peter On 12/3/09 3:31 PM, Eran Hammer-Lahav wrote: > After plenty of healthy discussion with the chair, AD, and working > group members, I think the best way to move forward is to focus on > the next working group milestone: > > * Submit a document as a working group item providing the > functionality of the 2-legged HTTP authentication mechanism > > Which the charter provides us with complete freedom: > > The Working Group will also define a generally applicable HTTP > authentication mechanism (i.e., browser-based "2-leg" scenario). > > Once this is complete we can consider its impact on the OAuth > delegation component, and whether we want to replace the existing > authentication with this new method. At that point, based on WG > consensus, we might want to consider changes to the charter. > > In addition, we have enough interest on this list to discuss > alternative delegation flows as suggested by WRAP which will be > submitted for WG consideration shortly. Discussing the new suggested > flows is critical for any discussion on future charter changes (if we > don't agree on which flows to include, we can't change the charter). > > I plan to submit a new individual submission I-D for the milestone > above for WG consideration shortly. Based on WG feedback we can > decide to promote it to a WG draft. > > I will leave it up to the chair to decide how he wishes to continue > based on my suggestions. > > EHL > >> -----Original Message----- From: oauth-bounces@ietf.org >> [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav >> Sent: Saturday, November 28, 2009 11:59 PM To: Peter Saint-Andre >> (stpeter@stpeter.im); Lisa Dusseault (lisa.dusseault@gmail.com) Cc: >> OAuth WG (oauth@ietf.org) Subject: [OAUTH-WG] OAuth 2.0 / Charter >> >> With the cleanup of the 1.0 specification [1] and the publication >> of an informational RFC (pending IESG approval), I no longer see >> value in a standard closely based on the 1.0 specification, which >> was the original intention of this WG. This is also reflected by >> the recent interest in the WRAP proposal [2]. >> >> Instead, I think we should develop two specifications that while >> closely in line with the original plan, represent a significant >> shift. In other words, I am proposing we develop OAuth 2.0, not >> 1.1. >> >> The new proposal is to develop two specifications: >> >> 1. Token Authorization Method >> >> An RFC 2617 Authorization header called 'Token' for authenticating >> requests with token-based credentials. Tokens (with optional >> shared-secret) are usually used in place of other credentials >> (usernames, etc.) and represent some combination of scope and >> authorization. The token method will include an extensible >> signature-based option based on the HMAC-SHA1 method, and a bearer >> token (with optional secret) option based on the PLAINTEXT method. >> The RSA option will be dropped. >> >> 2. OAuth 2.0 >> >> A specification based on the browser-redirection flow described in >> OAuth 1.0 as well as new methods defined in WRAP (I-D submission >> pending). OAuth will be redefined to cover the authorization >> component only, and will no longer be bound to a single >> authentication method. This will make OAuth immediately useful for >> other protocols than HTTP (while HTTP will be used to obtain >> tokens, tokens will be useful in other protocols, not just with the >> HTTP and Token method). >> >> --- >> >> While the current charter allows much of this work, it contradicts >> its spirit and the understanding reached when we created the >> working group. >> >> I would like to ask: >> >> - Is this approach favorable by the group? - Do we need to adjust >> the language in the charter to support? >> >> EHL >> >> [1] http://tools.ietf.org/html/draft-hammer-oauth [2] >> http://bit.ly/oauth-wrap >> >> _______________________________________________ OAuth mailing list >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --------------ms080407050304070904060309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzIyNDAzN1owIwYJKoZIhvcNAQkEMRYEFGqWwmnvxDCUI8b4plyd yrwqEH1TMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAjAku+QxQRFMfiDPEsDrYr06Pu2UiVpx2kD4GC130 7c9W9WIqWEcOIcIk5HR/+EdK3lEG4xf1eloLbkjP8GH66VjCytMyJZfsgcS5nvk6mHt2mAJ+ W+j9k0I06JUUx7JmeU42lolyTnb+9X4REhuB0y4aD4gyYeivOeZgQf6GL2PmgSk3g/TmyYMJ 4J8PHwppuAIWirc7PvhlVKx23m+2/aoYelTkqaYauMiLoY1EUp4KbpneM51nUK+d5gtve1ZT kcpBFVrUxoNNnN9fdPGCgh1jdY1GyH8zezktI0KZ3cZhKRbsaCleYlb53szsNaUr9XoOADip qYPDc9RCKBlIkwAAAAAAAA== --------------ms080407050304070904060309-- From stpeter@stpeter.im Thu Dec 3 14:48:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517BA3A6986 for ; Thu, 3 Dec 2009 14:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH4LYW0FmxpN for ; Thu, 3 Dec 2009 14:48:21 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 53C443A694A for ; Thu, 3 Dec 2009 14:48:21 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6FB4E40337; Thu, 3 Dec 2009 15:48:12 -0700 (MST) Message-ID: <4B18402B.9030000@stpeter.im> Date: Thu, 03 Dec 2009 15:48:11 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dick Hardt , OAuth WG References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A9DD209-E811-4591-A26E-287B337082E9@microsoft.com> In-Reply-To: <5A9DD209-E811-4591-A26E-287B337082E9@microsoft.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020403090601050505020404" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:48:22 -0000 This is a cryptographically signed message in MIME format. --------------ms020403090601050505020404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/30/09 12:57 PM, Dick Hardt wrote: > On 2009-11-30, at 9:25 AM, Eran Hammer-Lahav wrote: > >> 3. I will leave it up to the security experts to figure out if a PK >> option in the *authentication* spec is worth having, compared to >> TLS/SSL. OAuth did not require TLS because it was designed to be >> friendly to small sites looking to deploy an API without having to >> deal with certificates. The performance overhead wasn't really the >> main issue, it was practicality. For example, I would like to be >> able to write a Wordpress plugin that exposes an address book API >> using OAuth, without being required to enable SSL on my blog. > > Are there implementations of Wordpress plugins using OAuth? ie., was > there a real market need for this, or just a perceived need? > > If you don't have SSL on your blog management endpoint, then your > blog credentials are being transported in the clear. I don't have SSL > on my Wordpress blogs, and I'm ok with the risk given the tradeoffs. > It seems like many other people are as well currently. Not I: https://stpeter.im/ ^ > While I agree it is desirable to improve security, is there real > demand for it? The IESG and Security Directorate might demand it. :) > In choosing where to put efforts, would it be "better" to drive down > the barriers to deploying SSL? I'm always +1 to that. But at this point I think the barriers are more social than technical. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms020403090601050505020404 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzIyNDgxMVowIwYJKoZIhvcNAQkEMRYEFD3uK8Xo0aA9w8HfdnIM I+kyMeK5MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAP9URytWZOXc+j3bvmwWcaxOS6L9fxKnmlLDySLE3 sTKeI5UX4rZ1Fz8d1CS4WKQFBiKmRI6s9Gy4sJkGt+u/v0O1PrsfF2qmk25YkvefAQOOV3nV lwvo3w0oQ3jACxjBZo+kbtUNuNs3Gp0i603Sq7+TiMXxWbdvfoqktzU11VDp5dr9eKEGTfdi 0ZRJVFbYemhHI5//GbKhp2ORU+Uwkpk3xR+nEPxWgbdho3/pVR6xfEoVKHDUACjzhfbuK0tB fRaQV4bOoxIBE+Kbfdr08DkrtWjSH9AdS0dnj0ZADqXSG3SMJoHIwHtCBvar7joByOkXG1+7 CteIKQExWxQCjQAAAAAAAA== --------------ms020403090601050505020404-- From stpeter@stpeter.im Thu Dec 3 14:50:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1F63A6977 for ; Thu, 3 Dec 2009 14:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URuiLlTs0OIW for ; Thu, 3 Dec 2009 14:50:55 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 717C03A6809 for ; Thu, 3 Dec 2009 14:50:51 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 68C7740337; Thu, 3 Dec 2009 15:50:42 -0700 (MST) Message-ID: <4B1840C0.3090806@stpeter.im> Date: Thu, 03 Dec 2009 15:50:40 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343785209A24@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259536078.19069.6.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E72343785209A5A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209B82@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5A9DD209-E811-4591-A26E-287B337082E9@microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343785209BC8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785209BC8@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010907050202060009070302" Cc: Dick Hardt , "Moore, Jonathan \(CIM\)" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] keeping support for RSA (Was: RE: OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 22:50:55 -0000 This is a cryptographically signed message in MIME format. --------------ms010907050202060009070302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 11/30/09 1:40 PM, Eran Hammer-Lahav wrote: > The bottom line is that the new proposal separate the two, allowing > people who plan to use SSL across the board to focus on the other > stuff. If OAuth 1.0 requires SSL, it will accomplish nothing but a > fork in the community and two competing solutions. Instead, my > proposal makes it modular and allows everyone to play along. Yes, that seems reasonable, with the caveat that I think we say software MUST implement whereas services should deploy. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms010907050202060009070302 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzIyNTA0MFowIwYJKoZIhvcNAQkEMRYEFG/X1K6eeM9emduiAjoO O8/g8bJ9MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAUJENQ/DTlcyhmyjJmEI0POHZiQ4Kg5SsbJHPb1cF lwF7XHa6z/HgnTmhodoCkj5Ludi7xtYo8zestiojW+VX5Amku6ifynBDCCiLqR9+dLQ2lmZ+ whGrrsHSbR2c/PFzzlH7c6XkJCWK2Ih3qFkk09A2DULfJgUCbC7aslQj1RN0eOsjzPk5LZt9 0YlCCfhm4GXrm30x38PyLcJMaIe6HWGsmJirhR6LvHKw2BcehE6NNkwl9UnRftvAZLsWigGb Kh/RaJecjEt0HNn4yA4efN/OxvNu1t5GwdSeojS7GTYrt7Twzbk7/zeoTdYXRxyNcgxnAvtQ wz/8bxr/5Dl0pAAAAAAAAA== --------------ms010907050202060009070302-- From stpeter@stpeter.im Thu Dec 3 15:02:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960A828C0F8 for ; Thu, 3 Dec 2009 15:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgeC6sYhq2GQ for ; Thu, 3 Dec 2009 15:02:23 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7C87328C0EE for ; Thu, 3 Dec 2009 15:02:23 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8BA6240337; Thu, 3 Dec 2009 16:02:14 -0700 (MST) Message-ID: <4B184375.5070407@stpeter.im> Date: Thu, 03 Dec 2009 16:02:13 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Stephen Farrell References: <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1637EB.5080502@cs.tcd.ie> <4B183037.9050201@stpeter.im> <828931C9-9038-4B97-AF79-7C5FA3E9CD17@cs.tcd.ie> In-Reply-To: <828931C9-9038-4B97-AF79-7C5FA3E9CD17@cs.tcd.ie> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050505090806010506090601" Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] why are we signing? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 23:02:24 -0000 This is a cryptographically signed message in MIME format. --------------ms050505090806010506090601 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/3/09 3:21 PM, Stephen Farrell wrote: > > > On 3 Dec 2009, at 21:40, Peter Saint-Andre wrote: > >> >> >> On 12/2/09 2:48 AM, Stephen Farrell wrote: >>> I think we'll need an analysis of where we end up wanting TLS >>> for the protocols we produce. I wouldn't expect any big >>> surprises, but right now I don't think we can be sure since >>> things seems to be in flux to some extent. >>> >>> Then, I'd be for saying that TLS MUST be used for those operations. >>> However, I can well believe that there may be some niches where >>> using TLS isn't easy, so I could live with something like: it MUST >>> be possible to use TLS, and that deployments SHOULD use it, with >>> guidance as to the type of scenario where we think TLS really >>> has to be turned on, and maybe text about why sometimes people >>> can't do that. >>> >>> So I don't think we can finish this discussion at this stage. >> >> I think we can: >> >> 1. Software MUST implement TLS >> 2. Services should deploy TLS > > Tend to agree. What I meant we couldn't yet do was say for exactly which > operations we think TLS should be turned on, and what it means to not > use TLS in those cases, Agreed. I think we'll have a clearer picture of that in the next few weeks, once the token auth and alternative delegation flow I-Ds are submitted. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms050505090806010506090601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwMzIzMDIxM1owIwYJKoZIhvcNAQkEMRYEFO8CpQuuCU+QP1CdgMQE 2DcPDXVJMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAiSLqVfGF9XyBNUphzGdmm4aqNOwWMrbUpZxfVWKK 0p7Zauhc6v3PT0XnQGN5XICzJXe6P4ZG/T1xDZ9wIgLU5Z6VEkuDXrPtPehzplBNGysEfKXN bxvAmHafNMumrisIEeeSTvkJyZBH/WfCDb/9Mw8FTmGZrZrwljTLN3hhpq67pbZH+tt803Lp T5RSZ7Cr0+gGmF16rm+h+5xHXpQqaEMNSLg1suiRArFfAKHt9dwCh9aIMPzrKeiTs4LKU62N dCkZHShSUaQe0NSwk3xgPvEb043/opqa/xuMD/H4/BIxYG+DG3jPutboMxvhIRyJUZGUGG4Q HbUuBpgfXmXVCQAAAAAAAA== --------------ms050505090806010506090601-- From eran@hueniverse.com Thu Dec 3 15:47:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6F628C17C for ; Thu, 3 Dec 2009 15:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhNlOvQX9qp9 for ; Thu, 3 Dec 2009 15:47:58 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 305B028C0EF for ; Thu, 3 Dec 2009 15:47:57 -0800 (PST) Received: (qmail 25961 invoked from network); 3 Dec 2009 23:47:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 23:47:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 3 Dec 2009 16:47:48 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Thu, 3 Dec 2009 16:48:03 -0700 Thread-Topic: "Upgrade" to HTTPS option Thread-Index: Acp0cw3qo66Y5nsdTWSB3OXMh1rPUw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 23:47:58 -0000 How do people feel about the idea of allowing the server to say it is willi= ng to accept a plaintext request (with or without a secret) but only over H= TTPS? This is a bit odd because is conflates the http and https schemes to discus= s the same resource regardless of the scheme, but it is how most sites depl= oy their endpoints. For example: A request for http://example.com/resource/1 will yield the following respon= se: HTTP/1.1 401 Unauthorized WWW-Authenticate: Token realm=3D"http://example.com/", class=3D"oauth", m= ethods=3D"HMAC Plain-S" Which means OAuth tokens are accepted using the HMAC method, or the Plain m= ethod over HTTPS. If the client wishes to use Plain, it must send an authen= ticated response to https://example.com/resource/1. Comments? EHL PS. You'll notice I am throwing a lot of new ideas to the list for feedback= as I am working on my authentication draft. Feel free to bounce your own i= deas (thanks James!). From email@pbryan.net Thu Dec 3 15:51:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2453A6836 for ; Thu, 3 Dec 2009 15:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVs2zigUcMMr for ; Thu, 3 Dec 2009 15:51:57 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 12D3128C17C for ; Thu, 3 Dec 2009 15:51:57 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 80B2AEA021 for ; Thu, 3 Dec 2009 23:51:48 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Dec 2009 15:51:33 -0800 Message-ID: <1259884293.6142.549.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 23:51:57 -0000 On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > How do people feel about the idea of allowing the server to say it is > willing to accept a plaintext request (with or without a secret) but > only over HTTPS? > > This is a bit odd because is conflates the http and https schemes to > discuss the same resource regardless of the scheme, but it is how most > sites deploy their endpoints. I think it's wrong for exactly the reason you stated above. The presence of "-S" means the resource is also exposed at the same hostname, but implicitly via HTTPS on port 443, with the same URI. This is too much of a stretch for me. > > For example: > > A request for http://example.com/resource/1 will yield the following > response: > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Token realm="http://example.com/", class="oauth", > methods="HMAC Plain-S" > > Which means OAuth tokens are accepted using the HMAC method, or the > Plain method over HTTPS. If the client wishes to use Plain, it must > send an authenticated response to https://example.com/resource/1. > > Comments? > > EHL > PS. You'll notice I am throwing a lot of new ideas to the list for > feedback as I am working on my authentication draft. Feel free to > bounce your own ideas (thanks James!). > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Dec 3 15:58:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D753A684C for ; Thu, 3 Dec 2009 15:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pIeWUoaLw8G for ; Thu, 3 Dec 2009 15:58:28 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AE71E3A6886 for ; Thu, 3 Dec 2009 15:58:28 -0800 (PST) Received: (qmail 16640 invoked from network); 3 Dec 2009 23:58:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Dec 2009 23:58:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 3 Dec 2009 16:57:15 -0700 From: Eran Hammer-Lahav To: "Paul C. Bryan" , "OAuth WG (oauth@ietf.org)" Date: Thu, 3 Dec 2009 16:57:29 -0700 Thread-Topic: [OAUTH-WG] "Upgrade" to HTTPS option Thread-Index: Acp0c5ZX8MK4OsSjTEObfoX69QtPcgAADd7g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> In-Reply-To: <1259884293.6142.549.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 23:58:29 -0000 What if the HTTPS URI was explicitly provided, not implied by inserting an = 's' into the URI? Not sure what's the best way of providing it, but I'm sur= e we can find a way... EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul C. Bryan > Sent: Thursday, December 03, 2009 3:52 PM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >=20 > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > How do people feel about the idea of allowing the server to say it is > > willing to accept a plaintext request (with or without a secret) but > > only over HTTPS? > > > > This is a bit odd because is conflates the http and https schemes to > > discuss the same resource regardless of the scheme, but it is how most > > sites deploy their endpoints. >=20 > I think it's wrong for exactly the reason you stated above. The presence = of "- > S" means the resource is also exposed at the same hostname, but implicitl= y > via HTTPS on port 443, with the same URI. This is too much of a stretch f= or > me. >=20 > > > > For example: > > > > A request for http://example.com/resource/1 will yield the following > > response: > > > > HTTP/1.1 401 Unauthorized > > WWW-Authenticate: Token realm=3D"http://example.com/", class=3D"oauth= ", > > methods=3D"HMAC Plain-S" > > > > Which means OAuth tokens are accepted using the HMAC method, or the > > Plain method over HTTPS. If the client wishes to use Plain, it must > > send an authenticated response to https://example.com/resource/1. > > > > Comments? > > > > EHL > > PS. You'll notice I am throwing a lot of new ideas to the list for > > feedback as I am working on my authentication draft. Feel free to > > bounce your own ideas (thanks James!). > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From email@pbryan.net Thu Dec 3 16:00:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00F23A691B for ; Thu, 3 Dec 2009 16:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aseFp0RXOxZj for ; Thu, 3 Dec 2009 16:00:32 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 1EE9728C0E4 for ; Thu, 3 Dec 2009 16:00:32 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 83D40EA021 for ; Fri, 4 Dec 2009 00:00:23 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Dec 2009 16:00:09 -0800 Message-ID: <1259884809.6142.551.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:00:33 -0000 On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > What if the HTTPS URI was explicitly provided, not implied by > inserting an 's' into the URI? Not sure what's the best way of > providing it, but I'm sure we can find a way... That's definitely much less of a stretch. :) Perhaps somehow using XRD? Paul > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > Of Paul C. Bryan > > Sent: Thursday, December 03, 2009 3:52 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > How do people feel about the idea of allowing the server to say it > is > > > willing to accept a plaintext request (with or without a secret) > but > > > only over HTTPS? > > > > > > This is a bit odd because is conflates the http and https schemes > to > > > discuss the same resource regardless of the scheme, but it is how > most > > > sites deploy their endpoints. > > > > I think it's wrong for exactly the reason you stated above. The > presence of "- > > S" means the resource is also exposed at the same hostname, but > implicitly > > via HTTPS on port 443, with the same URI. This is too much of a > stretch for > > me. > > > > > > > > For example: > > > > > > A request for http://example.com/resource/1 will yield the > following > > > response: > > > > > > HTTP/1.1 401 Unauthorized > > > WWW-Authenticate: Token realm="http://example.com/", > class="oauth", > > > methods="HMAC Plain-S" > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > the > > > Plain method over HTTPS. If the client wishes to use Plain, it > must > > > send an authenticated response to https://example.com/resource/1. > > > > > > Comments? > > > > > > EHL > > > PS. You'll notice I am throwing a lot of new ideas to the list for > > > feedback as I am working on my authentication draft. Feel free to > > > bounce your own ideas (thanks James!). > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Thu Dec 3 16:06:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891BA3A6836 for ; Thu, 3 Dec 2009 16:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+lkau+UsNW2 for ; Thu, 3 Dec 2009 16:06:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 88D293A681B for ; Thu, 3 Dec 2009 16:06:33 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id nB406Mni003983 for ; Fri, 4 Dec 2009 00:06:22 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259885182; bh=tQUnTk08J3bcY75PfXN/oW6DDwI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=hIFzOX4WDKlF5I4Mo771IqII3ppnnomZLJKTglJm6C9r2LW6QLUt2bTOHGDVf+iV7 av+jRBOm1uY5slmypSCmQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=u4cnLWg6Xj33hjpRia6FWJfwMAU2yNrULD4RZd2bTBN4iHYFARwd3He58ZOzmNsTs FIrxR5DyD95qWa6Q418eg== Received: from pzk32 (pzk32.prod.google.com [10.243.19.160]) by wpaz29.hot.corp.google.com with ESMTP id nB405VcA004259 for ; Thu, 3 Dec 2009 16:06:20 -0800 Received: by pzk32 with SMTP id 32so1802080pzk.21 for ; Thu, 03 Dec 2009 16:06:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.201.3 with SMTP id y3mr148405rvf.288.1259885177328; Thu, 03 Dec 2009 16:06:17 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 3 Dec 2009 16:06:17 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:06:35 -0000 On Thu, Dec 3, 2009 at 3:48 PM, Eran Hammer-Lahav wrote: > How do people feel about the idea of allowing the server to say it is willing to accept a plaintext request (with or without a secret) but only over HTTPS? > > This is a bit odd because is conflates the http and https schemes to discuss the same resource regardless of the scheme, but it is how most sites deploy their endpoints. I'm not wild about this, I don't think it will be necessary in practice. Clients are going to know which URL to access. I'm nervous about trying to do too much with discovery. Cheers, Brian From eran@hueniverse.com Thu Dec 3 16:08:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B71D28C0F3 for ; Thu, 3 Dec 2009 16:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQtwLgW9ZaQG for ; Thu, 3 Dec 2009 16:08:45 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C24E03A68FF for ; Thu, 3 Dec 2009 16:08:45 -0800 (PST) Received: (qmail 14486 invoked from network); 4 Dec 2009 00:08:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 00:08:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 17:08:24 -0700 From: Eran Hammer-Lahav To: "Paul C. Bryan" , "OAuth WG (oauth@ietf.org)" Date: Thu, 3 Dec 2009 17:08:39 -0700 Thread-Topic: [OAUTH-WG] "Upgrade" to HTTPS option Thread-Index: Acp0dMmsbtWEqpdmSC2i1s+araqaMAAAB+iA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884809.6142.551.camel@localhost> In-Reply-To: <1259884809.6142.551.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:08:46 -0000 I am strongly against using XRD for this level of discovery. Requiring mult= iple round trips is one of the reasons Digest failed adoption. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul C. Bryan > Sent: Thursday, December 03, 2009 4:00 PM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >=20 > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: >=20 > > What if the HTTPS URI was explicitly provided, not implied by > > inserting an 's' into the URI? Not sure what's the best way of > > providing it, but I'm sure we can find a way... >=20 > That's definitely much less of a stretch. :) Perhaps somehow using XRD? >=20 > Paul >=20 > > > > EHL > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > Behalf > > > Of Paul C. Bryan > > > Sent: Thursday, December 03, 2009 3:52 PM > > > To: OAuth WG (oauth@ietf.org) > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > How do people feel about the idea of allowing the server to say it > > is > > > > willing to accept a plaintext request (with or without a secret) > > but > > > > only over HTTPS? > > > > > > > > This is a bit odd because is conflates the http and https schemes > > to > > > > discuss the same resource regardless of the scheme, but it is how > > most > > > > sites deploy their endpoints. > > > > > > I think it's wrong for exactly the reason you stated above. The > > presence of "- > > > S" means the resource is also exposed at the same hostname, but > > implicitly > > > via HTTPS on port 443, with the same URI. This is too much of a > > stretch for > > > me. > > > > > > > > > > > For example: > > > > > > > > A request for http://example.com/resource/1 will yield the > > following > > > > response: > > > > > > > > HTTP/1.1 401 Unauthorized > > > > WWW-Authenticate: Token realm=3D"http://example.com/", > > class=3D"oauth", > > > > methods=3D"HMAC Plain-S" > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > the > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > must > > > > send an authenticated response to https://example.com/resource/1. > > > > > > > > Comments? > > > > > > > > EHL > > > > PS. You'll notice I am throwing a lot of new ideas to the list for > > > > feedback as I am working on my authentication draft. Feel free to > > > > bounce your own ideas (thanks James!). > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Thu Dec 3 16:17:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F2A3A677C for ; Thu, 3 Dec 2009 16:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.954 X-Spam-Level: X-Spam-Status: No, score=-105.954 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKJ2OD9ua2dk for ; Thu, 3 Dec 2009 16:17:01 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 7F7E13A6886 for ; Thu, 3 Dec 2009 16:16:54 -0800 (PST) Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id nB40GhdG016423 for ; Fri, 4 Dec 2009 00:16:43 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259885804; bh=x92+ObuoFEcZf1Afmm4x5A4wvzM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZIdvO/EAz7iMB10o6LmaZHto3pRwLxWs8M2eGt+W2YZzCeb6ZoGMqdgRoJAdNwMFM Btusz8HErrNbM4RMw6MgQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=t6Eh10bvbwb+qcEqJCwcbCrRIMsgZbJMUiqstqsdxvkEK2giJE3IMYe5qdMMsXcFT uRSdOoJ0Vlzb64e4z+wDw== Received: from pwj19 (pwj19.prod.google.com [10.241.219.83]) by spaceape8.eur.corp.google.com with ESMTP id nB40GeMc026520 for ; Thu, 3 Dec 2009 16:16:41 -0800 Received: by pwj19 with SMTP id 19so1717599pwj.14 for ; Thu, 03 Dec 2009 16:16:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.84.40 with SMTP id m40mr2969935wal.192.1259885800096; Thu, 03 Dec 2009 16:16:40 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884809.6142.551.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 3 Dec 2009 16:16:20 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64ccb9c92825e0479dc051a X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:17:10 -0000 --0016e64ccb9c92825e0479dc051a Content-Type: text/plain; charset=ISO-8859-1 Why doesn't the server just use this? http://www.faqs.org/rfcs/rfc2817.html -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav wrote: > I am strongly against using XRD for this level of discovery. Requiring > multiple round trips is one of the reasons Digest failed adoption. > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Paul C. Bryan > > Sent: Thursday, December 03, 2009 4:00 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > > > > > What if the HTTPS URI was explicitly provided, not implied by > > > inserting an 's' into the URI? Not sure what's the best way of > > > providing it, but I'm sure we can find a way... > > > > That's definitely much less of a stretch. :) Perhaps somehow using XRD? > > > > Paul > > > > > > > > EHL > > > > > > > -----Original Message----- > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf > > > > Of Paul C. Bryan > > > > Sent: Thursday, December 03, 2009 3:52 PM > > > > To: OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > > How do people feel about the idea of allowing the server to say it > > > is > > > > > willing to accept a plaintext request (with or without a secret) > > > but > > > > > only over HTTPS? > > > > > > > > > > This is a bit odd because is conflates the http and https schemes > > > to > > > > > discuss the same resource regardless of the scheme, but it is how > > > most > > > > > sites deploy their endpoints. > > > > > > > > I think it's wrong for exactly the reason you stated above. The > > > presence of "- > > > > S" means the resource is also exposed at the same hostname, but > > > implicitly > > > > via HTTPS on port 443, with the same URI. This is too much of a > > > stretch for > > > > me. > > > > > > > > > > > > > > For example: > > > > > > > > > > A request for http://example.com/resource/1 will yield the > > > following > > > > > response: > > > > > > > > > > HTTP/1.1 401 Unauthorized > > > > > WWW-Authenticate: Token realm="http://example.com/", > > > class="oauth", > > > > > methods="HMAC Plain-S" > > > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > > the > > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > > must > > > > > send an authenticated response to https://example.com/resource/1. > > > > > > > > > > Comments? > > > > > > > > > > EHL > > > > > PS. You'll notice I am throwing a lot of new ideas to the list for > > > > > feedback as I am working on my authentication draft. Feel free to > > > > > bounce your own ideas (thanks James!). > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64ccb9c92825e0479dc051a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Why doesn't the server just use this?


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Thu, Dec 3, 2009 at 4:08 PM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:
I am strongly against using XRD for this level of discovery. Requiring mult= iple round trips is one of the reasons Digest failed adoption.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Paul C. Bryan
> Sent: Thursday, December 03, 2= 009 4:00 PM
> To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option
>
> On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote:
>
> > What if the HTTPS URI was explicitly provided, not implied by
> > inserting an 's' into the URI? Not sure what's the be= st way of
> > providing it, but I'm sure we can find a way...
>
> That's definitely much less of a stretch. :) Perhaps somehow using= XRD?
>
> Paul
>
> >
> > EHL
> >
> > > -----Original Message-----
> > > From: oauth-bounce= s@ietf.org [mailto:oauth-boun= ces@ietf.org] On
> > Behalf
> > > Of Paul C. Bryan
> > > Sent: Thursday, December 03, 2009 3:52 PM
> > > To: OAuth WG (oauth@ietf.o= rg)
> > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option<= br> > > >
> > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote:<= br> > > > > How do people feel about the idea of allowing the serve= r to say it
> > is
> > > > willing to accept a plaintext request (with or without = a secret)
> > but
> > > > only over HTTPS?
> > > >
> > > > This is a bit odd because is conflates the http and htt= ps schemes
> > to
> > > > discuss the same resource regardless of the scheme, but= it is how
> > most
> > > > sites deploy their endpoints.
> > >
> > > I think it's wrong for exactly the reason you stated abo= ve. The
> > presence of "-
> > > S" means the resource is also exposed at the same hostn= ame, but
> > implicitly
> > > via HTTPS on port 443, with the same URI. This is too much o= f a
> > stretch for
> > > me.
> > >
> > > >
> > > > For example:
> > > >
> > > > A request for http://example.com/resource/1 will yield the
> > following
> > > > response:
> > > >
> > > > =A0 HTTP/1.1 401 Unauthorized
> > > > =A0 WWW-Authenticate: Token realm=3D"http://example.com/",
> > class=3D"oauth",
> > > > methods=3D"HMAC Plain-S"
> > > >
> > > > Which means OAuth tokens are accepted using the HMAC me= thod, or
> > the
> > > > Plain method over HTTPS. If the client wishes to use Pl= ain, it
> > must
> > > > send an authenticated response to https://example.com/resource/1.=
> > > >
> > > > Comments?
> > > >
> > > > EHL
> > > > PS. You'll notice I am throwing a lot of new ideas = to the list for
> > > > feedback as I am working on my authentication draft. Fe= el free to
> > > > bounce your own ideas (thanks James!).
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e64ccb9c92825e0479dc051a-- From eran@hueniverse.com Thu Dec 3 16:17:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE7A93A682A for ; Thu, 3 Dec 2009 16:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ecRJPVqIZ22 for ; Thu, 3 Dec 2009 16:17:19 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 009C33A6803 for ; Thu, 3 Dec 2009 16:17:16 -0800 (PST) Received: (qmail 21907 invoked from network); 4 Dec 2009 00:17:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 00:17:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 17:16:57 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Thu, 3 Dec 2009 17:17:11 -0700 Thread-Topic: [OAUTH-WG] "Upgrade" to HTTPS option Thread-Index: Acp0dmeHQ/dueGMJRl+WiLxOUguXeAAAGXGA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852934E9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:17:21 -0000 At one point the OAuth Discovery draft provided a way to say "I support PLA= INTEXT over HTTPS or HMAC-SHA1 over HTTP", but it also provided the OAuth e= ndpoint for each of these. This was limited to the authorization flow and n= ot part of accessing protected resources. I was toying with the idea of mak= ing this available right from the WWW-Authenticate header field but it does= feel odd. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Thursday, December 03, 2009 4:06 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >=20 > On Thu, Dec 3, 2009 at 3:48 PM, Eran Hammer-Lahav > wrote: > > How do people feel about the idea of allowing the server to say it is w= illing > to accept a plaintext request (with or without a secret) but only over HT= TPS? > > > > This is a bit odd because is conflates the http and https schemes to di= scuss > the same resource regardless of the scheme, but it is how most sites depl= oy > their endpoints. >=20 > I'm not wild about this, I don't think it will be necessary in practice. = Clients > are going to know which URL to access. >=20 > I'm nervous about trying to do too much with discovery. >=20 > Cheers, > Brian From eran@hueniverse.com Thu Dec 3 16:18:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03B243A6452 for ; Thu, 3 Dec 2009 16:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqwnm7USBCJ0 for ; Thu, 3 Dec 2009 16:18:47 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8556A3A67D4 for ; Thu, 3 Dec 2009 16:18:46 -0800 (PST) Received: (qmail 24328 invoked from network); 4 Dec 2009 00:18:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 00:18:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 3 Dec 2009 17:17:59 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Thu, 3 Dec 2009 17:18:13 -0700 Thread-Topic: [OAUTH-WG] "Upgrade" to HTTPS option Thread-Index: Acp0dxH0nvciZeX3QZSMkI3r/e2AQAAABy5Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884809.6142.551.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723437852934EAP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:18:52 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723437852934EAP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's an upgrade of the entire channel. What I am talking about is simply = to say, "you want plain text? Sure! But go over there (HTTPS)". EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, December 03, 2009 4:16 PM To: Eran Hammer-Lahav Cc: Paul C. Bryan; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option Why doesn't the server just use this? http://www.faqs.org/rfcs/rfc2817.html -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav > wrote: I am strongly against using XRD for this level of discovery. Requiring mult= iple round trips is one of the reasons Digest failed adoption. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Paul C. Bryan > Sent: Thursday, December 03, 2009 4:00 PM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > > > What if the HTTPS URI was explicitly provided, not implied by > > inserting an 's' into the URI? Not sure what's the best way of > > providing it, but I'm sure we can find a way... > > That's definitely much less of a stretch. :) Perhaps somehow using XRD? > > Paul > > > > > EHL > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:o= auth-bounces@ietf.org] On > > Behalf > > > Of Paul C. Bryan > > > Sent: Thursday, December 03, 2009 3:52 PM > > > To: OAuth WG (oauth@ietf.org) > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > How do people feel about the idea of allowing the server to say it > > is > > > > willing to accept a plaintext request (with or without a secret) > > but > > > > only over HTTPS? > > > > > > > > This is a bit odd because is conflates the http and https schemes > > to > > > > discuss the same resource regardless of the scheme, but it is how > > most > > > > sites deploy their endpoints. > > > > > > I think it's wrong for exactly the reason you stated above. The > > presence of "- > > > S" means the resource is also exposed at the same hostname, but > > implicitly > > > via HTTPS on port 443, with the same URI. This is too much of a > > stretch for > > > me. > > > > > > > > > > > For example: > > > > > > > > A request for http://example.com/resource/1 will yield the > > following > > > > response: > > > > > > > > HTTP/1.1 401 Unauthorized > > > > WWW-Authenticate: Token realm=3D"http://example.com/", > > class=3D"oauth", > > > > methods=3D"HMAC Plain-S" > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > the > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > must > > > > send an authenticated response to https://example.com/resource/1. > > > > > > > > Comments? > > > > > > > > EHL > > > > PS. You'll notice I am throwing a lot of new ideas to the list for > > > > feedback as I am working on my authentication draft. Feel free to > > > > bounce your own ideas (thanks James!). > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723437852934EAP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That̵= 7;s an upgrade of the entire channel. What I am talking about is simply to = say, “you want plain text? Sure! But go over there (HTTPS)”.

 

=

EHL

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From= : John Panzer [mailto:jpanzer@google.com]
Sent: Thursday, Dec= ember 03, 2009 4:16 PM
To: Eran Hammer-Lahav
Cc: Paul C= . Bryan; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] "= Upgrade" to HTTPS option

 

Why doesn't the server j= ust use this?

 

=
<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>
--
Jo= hn Panzer / Google
jpanzer@google.= com / abstractioneer.org / @j= panzer


On Thu, Dec 3, 2= 009 at 4:08 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

I a= m strongly against using XRD for this level of discovery. Requiring multipl= e round trips is one of the reasons Digest failed adoption.

<= div>


EHL

> -----Original Message-----
= > From: oauth-bounces@ietf.org= [mailto:oauth-bounces@ietf.o= rg] On Behalf
> Of Paul C. Bryan

> Sent: Thursday, December 03, 2009 4:00 PM
> T= o: OAuth WG (oauth@ietf.org)
> = Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option
>
>= On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote:
>
>= ; > What if the HTTPS URI was explicitly provided, not implied by
>= ; > inserting an 's' into the URI? Not sure what's the best way of
&g= t; > providing it, but I'm sure we can find a way...
>
> Tha= t's definitely much less of a stretch. :) Perhaps somehow using XRD?
>= ;
> Paul
>
> >
> > EHL
> >
> &= gt; > -----Original Message-----
> > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> > Be= half
> > > Of Paul C. Bryan
> > > Sent: Thursday, D= ecember 03, 2009 3:52 PM
> > > To: OAuth WG (oauth@ietf.org)
> > > Subject: Re: [OAUTH-W= G] "Upgrade" to HTTPS option
> > >
> > > = On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote:
> > &g= t; > How do people feel about the idea of allowing the server to say it<= br>> > is
> > > > willing to accept a plaintext reques= t (with or without a secret)
> > but
> > > > only o= ver HTTPS?
> > > >
> > > > This is a bit odd = because is conflates the http and https schemes
> > to
> >= ; > > discuss the same resource regardless of the scheme, but it is h= ow
> > most
> > > > sites deploy their endpoints.> > >
> > > I think it's wrong for exactly the reaso= n you stated above. The
> > presence of "-
> > > = S" means the resource is also exposed at the same hostname, but
>= ; > implicitly
> > > via HTTPS on port 443, with the same UR= I. This is too much of a
> > stretch for
> > > me.
= > > >
> > > >
> > > > For example:> > > >
> > > > A request for http://example.com/resource/1 will yield the
> > following
> > > > response:> > > >
> > > >   HTTP/1.1 401 Unauthoriz= ed
> > > >   WWW-Authenticate: Token realm=3D"http://example.com/"= ,
> > class=3D"oauth",
> > > > methods=3D= "HMAC Plain-S"
> > > >
> > > > Whic= h means OAuth tokens are accepted using the HMAC method, or
> > th= e
> > > > Plain method over HTTPS. If the client wishes to u= se Plain, it
> > must
> > > > send an authenticated= response to h= ttps://example.com/resource/1.
> > > >
> > >= > Comments?
> > > >
> > > > EHL
> &= gt; > > PS. You'll notice I am throwing a lot of new ideas to the lis= t for
> > > > feedback as I am working on my authentication = draft. Feel free to
> > > > bounce your own ideas (thanks Ja= mes!).
> > > > _____________________________________________= __
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https:/= /www.ietf.org/mailman/listinfo/oauth
> > >
> > >= ;
> > > _______________________________________________
>= > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/lis= tinfo/oauth
>
>
> ___________________________________= ____________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oaut= h
_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723437852934EAP3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Thu Dec 3 16:23:16 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E72D3A6800 for ; Thu, 3 Dec 2009 16:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqXxwJkvmoYJ for ; Thu, 3 Dec 2009 16:23:15 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id B72F33A67F8 for ; Thu, 3 Dec 2009 16:23:14 -0800 (PST) Received: by yxe30 with SMTP id 30so1915276yxe.29 for ; Thu, 03 Dec 2009 16:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yJUUWKHbu+D6gNhdP1en8B2zRZhjnjo++yC5VKOjcTE=; b=s5cP/IcV+x+1BbxQ7mCfA2xzeKcPURWSj7xJmfN2v9gH65E9Fhv7tPgmiS9aB2wQeE lqnlRhwI0x+4g5NlwpcByc3GL1/fPDjadvCQJ15g78rsH+2KmsmOYM3Y3hmWzs1mQ9u8 dMUQY/0riXlt5Jdk1XXTbM+o5SnoIh+vDKnu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QFhEx2f5J2vmNJvQdsZ8ko4SreoVIgipUSfqHTo4DrrRxBNCllMStsrjXUym9kE96U tH1Tgon0dKM2FtU4fVWpKRcqD+T6+ft3yBCKnXEBbgCuh1tdcBGLBFCVq9nYHuKluxIk SNcPXE/dP41qL7+Qabo8BgQKrXGQIDDK+urPc= MIME-Version: 1.0 Received: by 10.101.62.11 with SMTP id p11mr3116736ank.21.1259886181776; Thu, 03 Dec 2009 16:23:01 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884809.6142.551.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 3 Dec 2009 16:23:01 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636eee42d527f460479dc1cd9 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:23:16 -0000 --001636eee42d527f460479dc1cd9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I tend to agree with John. I think in most cases, upgrading the channel is the right option if HTTPS i= s available. It might be that some endpoints want to support HMAC via HTTP. Why not simply indicate HMAC as the only available option at the HTTP endpoint? On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav wrot= e: > That=92s an upgrade of the entire channel. What I am talking about is sim= ply > to say, =93you want plain text? Sure! But go over there (HTTPS)=94. > > > > EHL > > > > *From:* John Panzer [mailto:jpanzer@google.com] > *Sent:* Thursday, December 03, 2009 4:16 PM > *To:* Eran Hammer-Lahav > *Cc:* Paul C. Bryan; OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > Why doesn't the server just use this? > > > > http://www.faqs.org/rfcs/rfc2817.html > > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav > wrote: > > I am strongly against using XRD for this level of discovery. Requiring > multiple round trips is one of the reasons Digest failed adoption. > > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Paul C. Bryan > > > Sent: Thursday, December 03, 2009 4:00 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > > > > > What if the HTTPS URI was explicitly provided, not implied by > > > inserting an 's' into the URI? Not sure what's the best way of > > > providing it, but I'm sure we can find a way... > > > > That's definitely much less of a stretch. :) Perhaps somehow using XRD? > > > > Paul > > > > > > > > EHL > > > > > > > -----Original Message----- > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf > > > > Of Paul C. Bryan > > > > Sent: Thursday, December 03, 2009 3:52 PM > > > > To: OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > > How do people feel about the idea of allowing the server to say i= t > > > is > > > > > willing to accept a plaintext request (with or without a secret) > > > but > > > > > only over HTTPS? > > > > > > > > > > This is a bit odd because is conflates the http and https schemes > > > to > > > > > discuss the same resource regardless of the scheme, but it is how > > > most > > > > > sites deploy their endpoints. > > > > > > > > I think it's wrong for exactly the reason you stated above. The > > > presence of "- > > > > S" means the resource is also exposed at the same hostname, but > > > implicitly > > > > via HTTPS on port 443, with the same URI. This is too much of a > > > stretch for > > > > me. > > > > > > > > > > > > > > For example: > > > > > > > > > > A request for http://example.com/resource/1 will yield the > > > following > > > > > response: > > > > > > > > > > HTTP/1.1 401 Unauthorized > > > > > WWW-Authenticate: Token realm=3D"http://example.com/", > > > class=3D"oauth", > > > > > methods=3D"HMAC Plain-S" > > > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > > the > > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > > must > > > > > send an authenticated response to https://example.com/resource/1. > > > > > > > > > > Comments? > > > > > > > > > > EHL > > > > > PS. You'll notice I am throwing a lot of new ideas to the list fo= r > > > > > feedback as I am working on my authentication draft. Feel free to > > > > > bounce your own ideas (thanks James!). > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Breno de Medeiros --001636eee42d527f460479dc1cd9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I tend to agree with John.

I think in most ca= ses, upgrading the channel is the right option if HTTPS is available.
=

It might be that some endpoints want to support HMAC vi= a HTTP. Why not simply indicate HMAC as the only available option at the HT= TP endpoint?

On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-= Lahav <eran@hue= niverse.com> wrote:

That=92s an upgrade of t= he entire channel. What I am talking about is simply to say, =93you want pl= ain text? Sure! But go over there (HTTPS)=94.

=A0

EHL

=A0

=A0

Why doesn't the server just use t= his?

=A0


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer

On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lah= av <eran@hueniv= erse.com> wrote:

I am strongly against usi= ng XRD for this level of discovery. Requiring multiple round trips is one o= f the reasons Digest failed adoption.


EHL

> -----Original Message-----<= br>> From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Paul C. Bryan

> Sent: = Thursday, December 03, 2009 4:00 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re:= [OAUTH-WG] "Upgrade" to HTTPS option
>
> On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote:>
> > What if the HTTPS URI was explicitly provided, not impli= ed by
> > inserting an 's' into the URI? Not sure what'= ;s the best way of
> > providing it, but I'm sure we can find a way...
>
&g= t; That's definitely much less of a stretch. :) Perhaps somehow using X= RD?
>
> Paul
>
> >
> > EHL
> >=
> > > -----Original Message-----
> > > From: oauth-bounces@ietf.org= [mailto:oa= uth-bounces@ietf.org] On
> > Behalf
> > > Of Paul C. Bryan
> > > Sent:= Thursday, December 03, 2009 3:52 PM
> > > To: OAuth WG (oauth@ietf.org)
> &= gt; > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option
> > >
> > > On Thu, 2009-12-03 at 16:48 -0700, Eran Ha= mmer-Lahav wrote:
> > > > How do people feel about the idea = of allowing the server to say it
> > is
> > > > wil= ling to accept a plaintext request (with or without a secret)
> > but
> > > > only over HTTPS?
> > > >= ;
> > > > This is a bit odd because is conflates the http an= d https schemes
> > to
> > > > discuss the same res= ource regardless of the scheme, but it is how
> > most
> > > > sites deploy their endpoints.
>= > >
> > > I think it's wrong for exactly the reason = you stated above. The
> > presence of "-
> > > S&= quot; means the resource is also exposed at the same hostname, but
> > implicitly
> > > via HTTPS on port 443, with the same= URI. This is too much of a
> > stretch for
> > > me.<= br>> > >
> > > >
> > > > For example= :
> > > >
> > > > A request for http://example.com/resource/1= will yield the
> > following
> > > > response:
> > > >
> > > > =A0 HTTP/1.1 401 Unauthorized> > > > =A0 WWW-Authenticate: Token realm=3D"http://example.com/",
>= ; > class=3D"oauth",
> > > > methods=3D"HMAC Plain-S"
> > > &g= t;
> > > > Which means OAuth tokens are accepted using the H= MAC method, or
> > the
> > > > Plain method over HT= TPS. If the client wishes to use Plain, it
> > must
> > > > send an authenticated response to https://example.c= om/resource/1.
> > > >
> > > > Comments?<= br> > > > >
> > > > EHL
> > > > PS. Y= ou'll notice I am throwing a lot of new ideas to the list for
> &= gt; > > feedback as I am working on my authentication draft. Feel fre= e to
> > > > bounce your own ideas (thanks James!).
> > >= ; > _______________________________________________
> > > &g= t; OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> = > >
> > >
> > > _____________________________= __________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://= www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Breno de Medeiros
--001636eee42d527f460479dc1cd9-- From quigley@emerose.com Thu Dec 3 16:25:06 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF5D3A677C for ; Thu, 3 Dec 2009 16:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP1Ic-0+WprZ for ; Thu, 3 Dec 2009 16:25:04 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 79F913A67F8 for ; Thu, 3 Dec 2009 16:25:04 -0800 (PST) Received: by ywh15 with SMTP id 15so1957765ywh.5 for ; Thu, 03 Dec 2009 16:24:51 -0800 (PST) Received: by 10.101.183.23 with SMTP id k23mr3112259anp.195.1259886291547; Thu, 03 Dec 2009 16:24:51 -0800 (PST) Received: from ?10.0.1.2? (75-101-96-3.dsl.static.sonic.net [75.101.96.3]) by mx.google.com with ESMTPS id 23sm1306924yxe.54.2009.12.03.16.24.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 16:24:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Sam Quigley In-Reply-To: <1259878881.6142.545.camel@localhost> Date: Thu, 3 Dec 2009 16:24:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <107A93BA-5E6F-411B-9F06-3E85D4ECF938@emerose.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> <1259878881.6142.545.camel@localhost> To: "Paul C. Bryan" X-Mailer: Apple Mail (2.1077) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:25:06 -0000 On Dec 3, 2009, at 2:21 PM, Paul C. Bryan wrote: > On Thu, 2009-12-03 at 14:06 -0800, Sam Quigley wrote: >> Fair enough; I'd forgotten about the nonce-scoping trick. What about >> going the other way, and dropping nonces entirely =97 and replacing = the >> timestamp with a monotonically-increasing counter. (Which, in most >> cases, could just be the client's timestamp.) >=20 > I've encountered cases where there may be multiple client instances > (sharing the same consumer key)=97multiple servers in a cluster for > instance=97and in fact needed to relax the monotonically increasing > timestamp (allow for an acceptable amount of skew to accommodate > multiple instances). >=20 > There's also the issue of request order when near-concurrent requests > are transmitted from the consumer. The Interweb allows flexible = routing > of requests, and one request sent just before another from the = consumer > could reach the server after the second. >=20 > Another issue will be timestamp granularity=97if the value must = increase > for each request, then you limit the frequency of requests to the > granularity of your timestamp. >=20 > Timestamp+nonce provides ways to handle these types of issues. One > without the other makes these problems more difficult to handle. All good points. =20 There might, though, still be room to relax the timestamp requirement, = and make it merely a monotonically increasing counter=85 Given a = request, the server would check first that the counter is greater than = or equal to all other counters received from this consumer; and, second, = the server would check that the nonce is unique among requests issued = with the same counter value=10. Unless there's still something I'm = missing, this would: * protect against replays=20 * no require clock sync * not require infinite nonce storage on the server * scale up for massively distributed consumers (which could just use = their current timestamp) * scale down for embedded and other "dumb" devices which don't = necessarily have well-synchronized clocks There would still be the problem of packet reordering, though =97 I = expect that this would have to be solved, as you suggest, by allowing a = bit of skew in the counter. And servers would have to be prepared to = handle degenerate consumers which never increment their timestamps =97 = though it seems reasonable to simply reject requests in this case. Even if all that does work, though, I wonder if it might not be better = to simply make protection from replay attacks out-of-scope for OAuth. = =46rom various conversations, it sounds like most (all?) major OAuth = installations don't actually check nonces anyway, as the server-side = synchronization requirements are too onerous. If an application *does* = require protection against replays, it's generally pretty easy to add = something at the application layer that would solve the problem=85 and = whatever we can do to simplify the spec will certainly be appreciated. -sq= From jpanzer@google.com Thu Dec 3 16:26:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ACB03A67F8 for ; Thu, 3 Dec 2009 16:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.955 X-Spam-Level: X-Spam-Status: No, score=-105.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4SsUSaEvT2S for ; Thu, 3 Dec 2009 16:26:09 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 946B73A6816 for ; Thu, 3 Dec 2009 16:26:07 -0800 (PST) Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id nB40PvTQ025572 for ; Fri, 4 Dec 2009 00:25:57 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259886358; bh=VafqNsXCLnf3JaykRD8otFFdoWA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=kGYxu0I1O39q5L3XuBXH74vlemY/pjm4nn0C+kVx80Ur9qxTjTQUxB3TpA0KorBt6 0KYLNzcVGY9TjOW80d6fA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=nDLxnfuEoo41DdPgr8eCMZZOE7KMwBNzQMqqWinvGtBzvHSVxrJ1o+CcypPack/ia z4ydmU1+0U/YbB8R4PPBA== Received: from pzk3 (pzk3.prod.google.com [10.243.19.131]) by zps75.corp.google.com with ESMTP id nB40O03r011248 for ; Thu, 3 Dec 2009 16:25:54 -0800 Received: by pzk3 with SMTP id 3so1797906pzk.20 for ; Thu, 03 Dec 2009 16:25:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.249.24 with SMTP id w24mr3063064wah.146.1259886354123; Thu, 03 Dec 2009 16:25:54 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884809.6142.551.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 3 Dec 2009 16:25:34 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64cda8c984dd90479dc2601 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:26:10 -0000 --0016e64cda8c984dd90479dc2601 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I suppose the difference is that you need to discover this before sending the plaintext secret in the Authorization: header, otherwise it's kind of useless. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav wrot= e: > That=92s an upgrade of the entire channel. What I am talking about is sim= ply > to say, =93you want plain text? Sure! But go over there (HTTPS)=94. > > > > EHL > > > > *From:* John Panzer [mailto:jpanzer@google.com] > *Sent:* Thursday, December 03, 2009 4:16 PM > *To:* Eran Hammer-Lahav > *Cc:* Paul C. Bryan; OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > Why doesn't the server just use this? > > > > http://www.faqs.org/rfcs/rfc2817.html > > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav > wrote: > > I am strongly against using XRD for this level of discovery. Requiring > multiple round trips is one of the reasons Digest failed adoption. > > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Paul C. Bryan > > > Sent: Thursday, December 03, 2009 4:00 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > > > > > What if the HTTPS URI was explicitly provided, not implied by > > > inserting an 's' into the URI? Not sure what's the best way of > > > providing it, but I'm sure we can find a way... > > > > That's definitely much less of a stretch. :) Perhaps somehow using XRD? > > > > Paul > > > > > > > > EHL > > > > > > > -----Original Message----- > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf > > > > Of Paul C. Bryan > > > > Sent: Thursday, December 03, 2009 3:52 PM > > > > To: OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > > How do people feel about the idea of allowing the server to say i= t > > > is > > > > > willing to accept a plaintext request (with or without a secret) > > > but > > > > > only over HTTPS? > > > > > > > > > > This is a bit odd because is conflates the http and https schemes > > > to > > > > > discuss the same resource regardless of the scheme, but it is how > > > most > > > > > sites deploy their endpoints. > > > > > > > > I think it's wrong for exactly the reason you stated above. The > > > presence of "- > > > > S" means the resource is also exposed at the same hostname, but > > > implicitly > > > > via HTTPS on port 443, with the same URI. This is too much of a > > > stretch for > > > > me. > > > > > > > > > > > > > > For example: > > > > > > > > > > A request for http://example.com/resource/1 will yield the > > > following > > > > > response: > > > > > > > > > > HTTP/1.1 401 Unauthorized > > > > > WWW-Authenticate: Token realm=3D"http://example.com/", > > > class=3D"oauth", > > > > > methods=3D"HMAC Plain-S" > > > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > > the > > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > > must > > > > > send an authenticated response to https://example.com/resource/1. > > > > > > > > > > Comments? > > > > > > > > > > EHL > > > > > PS. You'll notice I am throwing a lot of new ideas to the list fo= r > > > > > feedback as I am working on my authentication draft. Feel free to > > > > > bounce your own ideas (thanks James!). > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --0016e64cda8c984dd90479dc2601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I suppose the difference is that you need to discover this before send= ing the plaintext secret in the Authorization: header, otherwise it's k= ind of useless.
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Thu, Dec 3, 2009 at 4:18 PM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:

That=92s an upgrade of t= he entire channel. What I am talking about is simply to say, =93you want pl= ain text? Sure! But go over there (HTTPS)=94.

=A0

EHL

=A0

=A0

Why doesn't the server just use t= his?

=A0


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer

On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lah= av <eran@hueniv= erse.com> wrote:

I am strongly against usi= ng XRD for this level of discovery. Requiring multiple round trips is one o= f the reasons Digest failed adoption.


EHL

> -----Original Message-----<= br>> From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Paul C. Bryan

> Sent: = Thursday, December 03, 2009 4:00 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re:= [OAUTH-WG] "Upgrade" to HTTPS option
>
> On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote:>
> > What if the HTTPS URI was explicitly provided, not impli= ed by
> > inserting an 's' into the URI? Not sure what'= ;s the best way of
> > providing it, but I'm sure we can find a way...
>
&g= t; That's definitely much less of a stretch. :) Perhaps somehow using X= RD?
>
> Paul
>
> >
> > EHL
> >=
> > > -----Original Message-----
> > > From: oauth-bounces@ietf.org= [mailto:oa= uth-bounces@ietf.org] On
> > Behalf
> > > Of Paul C. Bryan
> > > Sent:= Thursday, December 03, 2009 3:52 PM
> > > To: OAuth WG (oauth@ietf.org)
> &= gt; > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option
> > >
> > > On Thu, 2009-12-03 at 16:48 -0700, Eran Ha= mmer-Lahav wrote:
> > > > How do people feel about the idea = of allowing the server to say it
> > is
> > > > wil= ling to accept a plaintext request (with or without a secret)
> > but
> > > > only over HTTPS?
> > > >= ;
> > > > This is a bit odd because is conflates the http an= d https schemes
> > to
> > > > discuss the same res= ource regardless of the scheme, but it is how
> > most
> > > > sites deploy their endpoints.
>= > >
> > > I think it's wrong for exactly the reason = you stated above. The
> > presence of "-
> > > S&= quot; means the resource is also exposed at the same hostname, but
> > implicitly
> > > via HTTPS on port 443, with the same= URI. This is too much of a
> > stretch for
> > > me.<= br>> > >
> > > >
> > > > For example= :
> > > >
> > > > A request for http://example.com/resource/1= will yield the
> > following
> > > > response:
> > > >
> > > > =A0 HTTP/1.1 401 Unauthorized> > > > =A0 WWW-Authenticate: Token realm=3D"http://example.com/",
>= ; > class=3D"oauth",
> > > > methods=3D"HMAC Plain-S"
> > > &g= t;
> > > > Which means OAuth tokens are accepted using the H= MAC method, or
> > the
> > > > Plain method over HT= TPS. If the client wishes to use Plain, it
> > must
> > > > send an authenticated response to https://example.c= om/resource/1.
> > > >
> > > > Comments?<= br> > > > >
> > > > EHL
> > > > PS. Y= ou'll notice I am throwing a lot of new ideas to the list for
> &= gt; > > feedback as I am working on my authentication draft. Feel fre= e to
> > > > bounce your own ideas (thanks James!).
> > >= ; > _______________________________________________
> > > &g= t; OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> = > >
> > >
> > > _____________________________= __________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://= www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

=A0


--0016e64cda8c984dd90479dc2601-- From jpanzer@google.com Thu Dec 3 16:30:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17EBF3A682C for ; Thu, 3 Dec 2009 16:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.956 X-Spam-Level: X-Spam-Status: No, score=-105.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EaTaXuSE-cX for ; Thu, 3 Dec 2009 16:30:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 684D93A6804 for ; Thu, 3 Dec 2009 16:30:22 -0800 (PST) Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id nB40UDd7027337 for ; Fri, 4 Dec 2009 00:30:13 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259886613; bh=7v5PGpjTgr1CWiSnHtPGxN8YzcI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Dhtc3WQtt9YLw1b7Hex7YZxcjpCtdp1FMWLoGANxCHv6dg4eVHfDH/cxgSevx0TQO UMW2oV10lmLfrHKH6DTGg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=AcpFC/P8JHHGyXiiSddFEtqezrAAqNc7prx4CZrIGywEH8A7jcf6trrSKutCKe/RC 071bwuVU/vQmaEW0HHUbQ== Received: from pwi2 (pwi2.prod.google.com [10.241.219.2]) by spaceape14.eur.corp.google.com with ESMTP id nB40TvG6031802 for ; Thu, 3 Dec 2009 16:30:10 -0800 Received: by pwi2 with SMTP id 2so1694241pwi.16 for ; Thu, 03 Dec 2009 16:30:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.27.14 with SMTP id e14mr3123002waj.116.1259886609135; Thu, 03 Dec 2009 16:30:09 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884809.6142.551.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 3 Dec 2009 16:29:49 -0800 Message-ID: To: Breno Content-Type: multipart/alternative; boundary=00163646b6cacb79fe0479dc3561 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:30:26 -0000 --00163646b6cacb79fe0479dc3561 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At one point I implemented a system to do a 301 redirect over to an equivalent https: endpoint if an Authorization:-less request came in for a protected resource on an http: URI. The client would then redirect, switch to SSL, and there would be a regular RFC 2617 Unauthenticated response followed by a password challenge at the client, followed by a successful transfer of the base64-encoded password over https. The loophole here is if the client ever gets it into its head to pass the secret unprovoked over the unprotected http channel (we never issued an RFC 2617 challenge over the unprotected channel). But if clients are that broken there's little one can do to stop them, really. BTW, the above actually worked with most decent feed readers that supported HTTP Basic. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:23 PM, Breno wrote: > I tend to agree with John. > > I think in most cases, upgrading the channel is the right option if HTTPS > is available. > > It might be that some endpoints want to support HMAC via HTTP. Why not > simply indicate HMAC as the only available option at the HTTP endpoint? > > > On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav wr= ote: > >> That=92s an upgrade of the entire channel. What I am talking about is si= mply >> to say, =93you want plain text? Sure! But go over there (HTTPS)=94. >> >> >> >> EHL >> >> >> >> *From:* John Panzer [mailto:jpanzer@google.com] >> *Sent:* Thursday, December 03, 2009 4:16 PM >> *To:* Eran Hammer-Lahav >> *Cc:* Paul C. Bryan; OAuth WG (oauth@ietf.org) >> >> *Subject:* Re: [OAUTH-WG] "Upgrade" to HTTPS option >> >> >> >> Why doesn't the server just use this? >> >> >> >> http://www.faqs.org/rfcs/rfc2817.html >> >> >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer >> >> >> On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav >> wrote: >> >> I am strongly against using XRD for this level of discovery. Requiring >> multiple round trips is one of the reasons Digest failed adoption. >> >> >> EHL >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Paul C. Bryan >> >> > Sent: Thursday, December 03, 2009 4:00 PM >> > To: OAuth WG (oauth@ietf.org) >> > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >> > >> > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: >> > >> > > What if the HTTPS URI was explicitly provided, not implied by >> > > inserting an 's' into the URI? Not sure what's the best way of >> > > providing it, but I'm sure we can find a way... >> > >> > That's definitely much less of a stretch. :) Perhaps somehow using XRD= ? >> > >> > Paul >> > >> > > >> > > EHL >> > > >> > > > -----Original Message----- >> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> > > Behalf >> > > > Of Paul C. Bryan >> > > > Sent: Thursday, December 03, 2009 3:52 PM >> > > > To: OAuth WG (oauth@ietf.org) >> > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >> > > > >> > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: >> > > > > How do people feel about the idea of allowing the server to say = it >> > > is >> > > > > willing to accept a plaintext request (with or without a secret) >> > > but >> > > > > only over HTTPS? >> > > > > >> > > > > This is a bit odd because is conflates the http and https scheme= s >> > > to >> > > > > discuss the same resource regardless of the scheme, but it is ho= w >> > > most >> > > > > sites deploy their endpoints. >> > > > >> > > > I think it's wrong for exactly the reason you stated above. The >> > > presence of "- >> > > > S" means the resource is also exposed at the same hostname, but >> > > implicitly >> > > > via HTTPS on port 443, with the same URI. This is too much of a >> > > stretch for >> > > > me. >> > > > >> > > > > >> > > > > For example: >> > > > > >> > > > > A request for http://example.com/resource/1 will yield the >> > > following >> > > > > response: >> > > > > >> > > > > HTTP/1.1 401 Unauthorized >> > > > > WWW-Authenticate: Token realm=3D"http://example.com/", >> > > class=3D"oauth", >> > > > > methods=3D"HMAC Plain-S" >> > > > > >> > > > > Which means OAuth tokens are accepted using the HMAC method, or >> > > the >> > > > > Plain method over HTTPS. If the client wishes to use Plain, it >> > > must >> > > > > send an authenticated response to https://example.com/resource/1= . >> > > > > >> > > > > Comments? >> > > > > >> > > > > EHL >> > > > > PS. You'll notice I am throwing a lot of new ideas to the list f= or >> > > > > feedback as I am working on my authentication draft. Feel free t= o >> > > > > bounce your own ideas (thanks James!). >> > > > > _______________________________________________ >> > > > > OAuth mailing list >> > > > > OAuth@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/oauth >> > > > >> > > > >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > OAuth@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Breno de Medeiros > > --00163646b6cacb79fe0479dc3561 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable At one point I implemented a system to do a 301 redirect over to an equival= ent https: endpoint if an Authorization:-less request came in for a protect= ed resource on an http: URI. =A0The client would then redirect, switch to S= SL, and there would be a regular RFC 2617 Unauthenticated response followed= by a password challenge at the client, followed by a successful transfer o= f the base64-encoded password over https.

The loophole here is if the client ever gets it into its hea= d to pass the secret unprovoked over the unprotected http channel (we never= issued an RFC 2617 challenge over the unprotected channel). =A0But if clie= nts are that broken there's little one can do to stop them, really.

BTW, the above actually worked with most decent feed re= aders that supported HTTP Basic.

--
John Pan= zer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer=



On Thu, Dec 3, 2009 at 4:23 PM, Breno <breno.dem= edeiros@gmail.com> wrote:
I tend to agree with John.

I think in most ca= ses, upgrading the channel is the right option if HTTPS is available.
=

It might be that some endpoints want to support HMAC vi= a HTTP. Why not simply indicate HMAC as the only available option at the HT= TP endpoint?


On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-= Lahav <eran@hueniverse.com> wrote:

That=92s an upgrade of t= he entire channel. What I am talking about is simply to say, =93you want pl= ain text? Sure! But go over there (HTTPS)=94.

=A0

EHL

=A0

=A0

Why doesn't the server just use this?

=A0


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer

On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lah= av <eran@hueniv= erse.com> wrote:

I am strongly against usi= ng XRD for this level of discovery. Requiring multiple round trips is one o= f the reasons Digest failed adoption.


EHL

> -----Original Message-----<= br>> From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Paul C. Bryan

> Sent: = Thursday, December 03, 2009 4:00 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re:= [OAUTH-WG] "Upgrade" to HTTPS option
>
> On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote:>
> > What if the HTTPS URI was explicitly provided, not impli= ed by
> > inserting an 's' into the URI? Not sure what'= ;s the best way of
> > providing it, but I'm sure we can find a way...
>
&g= t; That's definitely much less of a stretch. :) Perhaps somehow using X= RD?
>
> Paul
>
> >
> > EHL
> >=
> > > -----Original Message-----
> > > From: oauth-bounces@ietf.org= [mailto:oa= uth-bounces@ietf.org] On
> > Behalf
> > > Of Paul C. Bryan
> > > Sent:= Thursday, December 03, 2009 3:52 PM
> > > To: OAuth WG (oauth@ietf.org)
> &= gt; > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option
> > >
> > > On Thu, 2009-12-03 at 16:48 -0700, Eran Ha= mmer-Lahav wrote:
> > > > How do people feel about the idea = of allowing the server to say it
> > is
> > > > wil= ling to accept a plaintext request (with or without a secret)
> > but
> > > > only over HTTPS?
> > > >= ;
> > > > This is a bit odd because is conflates the http an= d https schemes
> > to
> > > > discuss the same res= ource regardless of the scheme, but it is how
> > most
> > > > sites deploy their endpoints.
>= > >
> > > I think it's wrong for exactly the reason = you stated above. The
> > presence of "-
> > > S&= quot; means the resource is also exposed at the same hostname, but
> > implicitly
> > > via HTTPS on port 443, with the same= URI. This is too much of a
> > stretch for
> > > me.<= br>> > >
> > > >
> > > > For example= :
> > > >
> > > > A request for http://example.com/resource/1= will yield the
> > following
> > > > response:
> > > >
> > > > =A0 HTTP/1.1 401 Unauthorized> > > > =A0 WWW-Authenticate: Token realm=3D"http://example.com/",
>= ; > class=3D"oauth",
> > > > methods=3D"HMAC Plain-S"
> > > &g= t;
> > > > Which means OAuth tokens are accepted using the H= MAC method, or
> > the
> > > > Plain method over HT= TPS. If the client wishes to use Plain, it
> > must
> > > > send an authenticated response to https://example.c= om/resource/1.
> > > >
> > > > Comments?<= br> > > > >
> > > > EHL
> > > > PS. Y= ou'll notice I am throwing a lot of new ideas to the list for
> &= gt; > > feedback as I am working on my authentication draft. Feel fre= e to
> > > > bounce your own ideas (thanks James!).
> > >= ; > _______________________________________________
> > > &g= t; OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> = > >
> > >
> > > _____________________________= __________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://= www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Breno d= e Medeiros


--00163646b6cacb79fe0479dc3561-- From eran@hueniverse.com Thu Dec 3 16:41:43 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1013A6868 for ; Thu, 3 Dec 2009 16:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAcwv+d+z218 for ; Thu, 3 Dec 2009 16:41:36 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3CB203A67B7 for ; Thu, 3 Dec 2009 16:41:36 -0800 (PST) Received: (qmail 14753 invoked from network); 4 Dec 2009 00:41:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 00:41:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 17:41:27 -0700 From: Eran Hammer-Lahav To: John Panzer , Breno Date: Thu, 3 Dec 2009 17:41:41 -0700 Thread-Topic: [OAUTH-WG] "Upgrade" to HTTPS option Thread-Index: Acp0ePQTSVbEGWpCTzuElqkFdK1iLAAAYmkw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852934F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884809.6142.551.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723437852934F8P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 00:41:43 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723437852934F8P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it is safe to conclude this idea does not have legs (2, 3, or other= wise). EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, December 03, 2009 4:30 PM To: Breno Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option At one point I implemented a system to do a 301 redirect over to an equival= ent https: endpoint if an Authorization:-less request came in for a protect= ed resource on an http: URI. The client would then redirect, switch to SSL= , and there would be a regular RFC 2617 Unauthenticated response followed b= y a password challenge at the client, followed by a successful transfer of = the base64-encoded password over https. The loophole here is if the client ever gets it into its head to pass the s= ecret unprovoked over the unprotected http channel (we never issued an RFC = 2617 challenge over the unprotected channel). But if clients are that brok= en there's little one can do to stop them, really. BTW, the above actually worked with most decent feed readers that supported= HTTP Basic. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:23 PM, Breno > wrote: I tend to agree with John. I think in most cases, upgrading the channel is the right option if HTTPS i= s available. It might be that some endpoints want to support HMAC via HTTP. Why not simp= ly indicate HMAC as the only available option at the HTTP endpoint? On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav > wrote: That's an upgrade of the entire channel. What I am talking about is simply = to say, "you want plain text? Sure! But go over there (HTTPS)". EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, December 03, 2009 4:16 PM To: Eran Hammer-Lahav Cc: Paul C. Bryan; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option Why doesn't the server just use this? http://www.faqs.org/rfcs/rfc2817.html -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav > wrote: I am strongly against using XRD for this level of discovery. Requiring mult= iple round trips is one of the reasons Digest failed adoption. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Paul C. Bryan > Sent: Thursday, December 03, 2009 4:00 PM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > > > What if the HTTPS URI was explicitly provided, not implied by > > inserting an 's' into the URI? Not sure what's the best way of > > providing it, but I'm sure we can find a way... > > That's definitely much less of a stretch. :) Perhaps somehow using XRD? > > Paul > > > > > EHL > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:o= auth-bounces@ietf.org] On > > Behalf > > > Of Paul C. Bryan > > > Sent: Thursday, December 03, 2009 3:52 PM > > > To: OAuth WG (oauth@ietf.org) > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > How do people feel about the idea of allowing the server to say it > > is > > > > willing to accept a plaintext request (with or without a secret) > > but > > > > only over HTTPS? > > > > > > > > This is a bit odd because is conflates the http and https schemes > > to > > > > discuss the same resource regardless of the scheme, but it is how > > most > > > > sites deploy their endpoints. > > > > > > I think it's wrong for exactly the reason you stated above. The > > presence of "- > > > S" means the resource is also exposed at the same hostname, but > > implicitly > > > via HTTPS on port 443, with the same URI. This is too much of a > > stretch for > > > me. > > > > > > > > > > > For example: > > > > > > > > A request for http://example.com/resource/1 will yield the > > following > > > > response: > > > > > > > > HTTP/1.1 401 Unauthorized > > > > WWW-Authenticate: Token realm=3D"http://example.com/", > > class=3D"oauth", > > > > methods=3D"HMAC Plain-S" > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > the > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > must > > > > send an authenticated response to https://example.com/resource/1. > > > > > > > > Comments? > > > > > > > > EHL > > > > PS. You'll notice I am throwing a lot of new ideas to the list for > > > > feedback as I am working on my authentication draft. Feel free to > > > > bounce your own ideas (thanks James!). > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723437852934F8P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think i= t is safe to conclude this idea does not have legs (2, 3, or otherwise).

 

=

EHL

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From= : John Panzer [mailto:jpanzer@google.com]
Sent: Thursday, Dec= ember 03, 2009 4:30 PM
To: Breno
Cc: Eran Hammer-Lahav;= OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] "Upgrade&= quot; to HTTPS option

 

At one point I implemented a sys= tem to do a 301 redirect over to an equivalent https: endpoint if an Author= ization:-less request came in for a protected resource on an http: URI. &nb= sp;The client would then redirect, switch to SSL, and there would be a regu= lar RFC 2617 Unauthenticated response followed by a password challenge at t= he client, followed by a successful transfer of the base64-encoded password= over https.

 

<= /div>

The loophole here is if the client ever gets= it into its head to pass the secret unprovoked over the unprotected http c= hannel (we never issued an RFC 2617 challenge over the unprotected channel)= .  But if clients are that broken there's little one can do to stop th= em, really.

 =

BTW, the above actually worked with mos= t decent feed readers that supported HTTP Basic.

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>
--
Jo= hn Panzer / Google
jpanzer@google.= com / abstractioneer.org / @j= panzer


On Thu, Dec 3, 2= 009 at 4:23 PM, Breno <bre= no.demedeiros@gmail.com> wrote:

I tend to agree with John.

 

I think in most case= s, upgrading the channel is the right option if HTTPS is available.

 

It might be that some endpoints want to support HMAC via H= TTP. Why not simply indicate HMAC as the only available option at the HTTP = endpoint?

 

On Thu, Dec 3, 20= 09 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

That’s an up= grade of the entire channel. What I am talking about is simply to say, R= 20;you want plain text? Sure! But go over there (HTTPS)”.=

 

EHL<= /span>

=  

From: John Pan= zer [mailto:jpanzer= @google.com]
Sent: Thursday, December 03, 2009 4:16 PM
To: Eran Hammer-Lahav
Cc: Paul C. Bryan; OAuth WG (oauth@ietf.org)


Subject: Re: [OAUTH-WG= ] "Upgrade" to HTTPS option

 

Why doesn't the server just u= se this?

 

<= a href=3D"http://www.faqs.org/rfcs/rfc2817.html" target=3D"_blank">http://w= ww.faqs.org/rfcs/rfc2817.html


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer

<= div>

On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav <eran@hueniverse.com> = wrote:

I am strongly against using XRD for this level = of discovery. Requiring multiple round trips is one of the reasons Digest f= ailed adoption.


EHL

> -----Original= Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
&= gt; Of Paul C. Bryan

> Sent: Thursd= ay, December 03, 2009 4:00 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUT= H-WG] "Upgrade" to HTTPS option
>
> On Thu, 2009-12-0= 3 at 16:57 -0700, Eran Hammer-Lahav wrote:
>
> > What if the= HTTPS URI was explicitly provided, not implied by
> > inserting a= n 's' into the URI? Not sure what's the best way of
> > providing = it, but I'm sure we can find a way...
>
> That's definitely muc= h less of a stretch. :) Perhaps somehow using XRD?
>
> Paul
= >
> >
> > EHL
> >
> > > -----Orig= inal Message-----
> > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = On
> > Behalf
> > > Of Paul C. Bryan
> > >= Sent: Thursday, December 03, 2009 3:52 PM
> > > To: OAuth WG (= oauth@ietf.org)
= > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option<= br>> > >
> > > On Thu, 2009-12-03 at 16:48 -0700, Eran= Hammer-Lahav wrote:
> > > > How do people feel about the id= ea of allowing the server to say it
> > is
> > > > = willing to accept a plaintext request (with or without a secret)
> &g= t; but
> > > > only over HTTPS?
> > > >
&g= t; > > > This is a bit odd because is conflates the http and https= schemes
> > to
> > > > discuss the same resource r= egardless of the scheme, but it is how
> > most
> > > = > sites deploy their endpoints.
> > >
> > > I th= ink it's wrong for exactly the reason you stated above. The
> > pr= esence of "-
> > > S" means the resource is also expo= sed at the same hostname, but
> > implicitly
> > > via= HTTPS on port 443, with the same URI. This is too much of a
> > s= tretch for
> > > me.
> > >
> > > >> > > > For example:
> > > >
> > >= > A request for http://example.com/resource/1 will yield the
> > followin= g
> > > > response:
> > > >
> > >= >   HTTP/1.1 401 Unauthorized
> > > >   WWW-Au= thenticate: Token realm=3D"http://example.com/",
> > class=3D"oauth"= ;,
> > > > methods=3D"HMAC Plain-S"
> > &= gt; >
> > > > Which means OAuth tokens are accepted using= the HMAC method, or
> > the
> > > > Plain method o= ver HTTPS. If the client wishes to use Plain, it
> > must
> = > > > send an authenticated response to https://example.com/resource/1.
&= gt; > > >
> > > > Comments?
> > > ><= br>> > > > EHL
> > > > PS. You'll notice I am th= rowing a lot of new ideas to the list for
> > > > feedback a= s I am working on my authentication draft. Feel free to
> > > &= gt; bounce your own ideas (thanks James!).
> > > > _________= ______________________________________
> > > > OAuth mailing= list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman= /listinfo/oauth
> > >
> > >
> > > _= ______________________________________________
> > > OAuth mail= ing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listin= fo/oauth
>
>
> ______________________________________= _________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailma= n/listinfo/oauth
_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 


_____= __________________________________________
OAuth mailing list
OAuth@ietf.org
https://= www.ietf.org/mailman/listinfo/oauth



--
Breno de Medeiros

=

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723437852934F8P3PW5EX1MB01E_-- From beaton@google.com Thu Dec 3 17:08:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0FB3A689A for ; Thu, 3 Dec 2009 17:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms++JPbIa8DK for ; Thu, 3 Dec 2009 17:08:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 88E3D3A6884 for ; Thu, 3 Dec 2009 17:08:01 -0800 (PST) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id nB417oui032748 for ; Fri, 4 Dec 2009 01:07:51 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259888871; bh=3/NTXzPcw7cfeGS3Hl26fETl7NA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=SV5gD5bFscDyCh1/0UMt1a14x8f4PbeiVxtRvC4gFY4H1h4nnZm3tmDeE5rsfrSLI sp0PjlX5K8Lx1S8jpHgsQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=vzbjQjvA4tGDGcZLpBxgP/DBP6zsSeVTNMQcv9AQsFrPqyxeHyJlGbfUoAs+kv9IW mGieo/ox06ymEmddV6Kzg== Received: from pwj17 (pwj17.prod.google.com [10.241.219.81]) by zps18.corp.google.com with ESMTP id nB417gvA005306 for ; Thu, 3 Dec 2009 17:07:48 -0800 Received: by pwj17 with SMTP id 17so1854781pwj.5 for ; Thu, 03 Dec 2009 17:07:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.45.17 with SMTP id x17mr152345rvj.62.1259888868005; Thu, 03 Dec 2009 17:07:48 -0800 (PST) In-Reply-To: <107A93BA-5E6F-411B-9F06-3E85D4ECF938@emerose.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> <1259878881.6142.545.camel@localhost> <107A93BA-5E6F-411B-9F06-3E85D4ECF938@emerose.com> Date: Thu, 3 Dec 2009 17:07:47 -0800 Message-ID: From: Brian Eaton To: Sam Quigley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 01:08:03 -0000 On Thu, Dec 3, 2009 at 4:24 PM, Sam Quigley wrote: > There might, though, still be room to relax the timestamp requirement, an= d make it merely a monotonically increasing counter=85 Monotonically increasing counters in distributed systems are a classic hard problem in computer science. Let's not write a spec that requires them, please. (Even if you allow for skew in the counter, you end up needing to do frequent writes to a central server that maintains the counters. The performance sucks, and the central server turns into a reliability problem.) I can see a few ways forward here. 1) Challenge-response This requires an extra round trip to establish the base line challenge. 2) Synchronized clocks This skips a round trip, but is known to fail in some corner cases. 3) Don't do replay protection. This is reasonable only if something like the scalable OAuth extension (or WRAP) is used to periodically refresh credentials. Otherwise you end up sending credentials that never expire at all, with associated security risks. The nice thing about the proposed scheme of synchronized clocks + an error response when they are not synchronized is that it is fast in the average case, and degenerates to challenge-response in the worst case. This solution has been proven to work already for OAuth 1.0. Cheers, Brian From jonathan_moore@comcast.com Thu Dec 3 17:17:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D623A6933 for ; Thu, 3 Dec 2009 17:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7IkOCESxPTA for ; Thu, 3 Dec 2009 17:16:58 -0800 (PST) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id A05283A6403 for ; Thu, 3 Dec 2009 17:16:58 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.73974988; Thu, 03 Dec 2009 20:16:20 -0500 Received: from PACORPEXCMB03.cable.comcast.com ([24.40.15.85]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Dec 2009 20:16:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Dec 2009 20:16:20 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] "Upgrade" to HTTPS option Thread-Index: Acp0ePQTSVbEGWpCTzuElqkFdK1iLAAAYmkwAADvRwY= References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259884293.6142.549.camel@localhost><90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259884809.6142.551.camel@localhost><90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: "Moore, Jonathan (CIM)" To: "Eran Hammer-Lahav" , "John Panzer" , "Breno" X-OriginalArrivalTime: 04 Dec 2009 01:16:21.0707 (UTC) FILETIME=[63C601B0:01CA747F] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 01:17:00 -0000 What about sending your 401 but adding a Link header[1] pointing to the = HTTPS resource, with a link extension specifying the acceptable methods? Like: HTTP/1.1 401 Unauthorized WWW-Authenticate: Token realm=3D"http://example.com/", class=3D"oauth", methods=3D"HMAC" Link: ; rel=3D"alternate"; oauth-method=3D"Plain" Jon [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-03 ........ Jon Moore Comcast Interactive Media -----Original Message----- From: oauth-bounces@ietf.org on behalf of Eran Hammer-Lahav Sent: Thu 12/3/2009 7:41 PM To: John Panzer; Breno Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option =20 I think it is safe to conclude this idea does not have legs (2, 3, or = otherwise). EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, December 03, 2009 4:30 PM To: Breno Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option At one point I implemented a system to do a 301 redirect over to an = equivalent https: endpoint if an Authorization:-less request came in for = a protected resource on an http: URI. The client would then redirect, = switch to SSL, and there would be a regular RFC 2617 Unauthenticated = response followed by a password challenge at the client, followed by a = successful transfer of the base64-encoded password over https. The loophole here is if the client ever gets it into its head to pass = the secret unprovoked over the unprotected http channel (we never issued = an RFC 2617 challenge over the unprotected channel). But if clients are = that broken there's little one can do to stop them, really. BTW, the above actually worked with most decent feed readers that = supported HTTP Basic. -- John Panzer / Google jpanzer@google.com / = abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:23 PM, Breno = > wrote: I tend to agree with John. I think in most cases, upgrading the channel is the right option if = HTTPS is available. It might be that some endpoints want to support HMAC via HTTP. Why not = simply indicate HMAC as the only available option at the HTTP endpoint? On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav = > wrote: That's an upgrade of the entire channel. What I am talking about is = simply to say, "you want plain text? Sure! But go over there (HTTPS)". EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, December 03, 2009 4:16 PM To: Eran Hammer-Lahav Cc: Paul C. Bryan; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option Why doesn't the server just use this? http://www.faqs.org/rfcs/rfc2817.html -- John Panzer / Google jpanzer@google.com / = abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav = > wrote: I am strongly against using XRD for this level of discovery. Requiring = multiple round trips is one of the reasons Digest failed adoption. EHL > -----Original Message----- > From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul C. Bryan > Sent: Thursday, December 03, 2009 4:00 PM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > > > What if the HTTPS URI was explicitly provided, not implied by > > inserting an 's' into the URI? Not sure what's the best way of > > providing it, but I'm sure we can find a way... > > That's definitely much less of a stretch. :) Perhaps somehow using = XRD? > > Paul > > > > > EHL > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On > > Behalf > > > Of Paul C. Bryan > > > Sent: Thursday, December 03, 2009 3:52 PM > > > To: OAuth WG (oauth@ietf.org) > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > How do people feel about the idea of allowing the server to say = it > > is > > > > willing to accept a plaintext request (with or without a secret) > > but > > > > only over HTTPS? > > > > > > > > This is a bit odd because is conflates the http and https = schemes > > to > > > > discuss the same resource regardless of the scheme, but it is = how > > most > > > > sites deploy their endpoints. > > > > > > I think it's wrong for exactly the reason you stated above. The > > presence of "- > > > S" means the resource is also exposed at the same hostname, but > > implicitly > > > via HTTPS on port 443, with the same URI. This is too much of a > > stretch for > > > me. > > > > > > > > > > > For example: > > > > > > > > A request for http://example.com/resource/1 will yield the > > following > > > > response: > > > > > > > > HTTP/1.1 401 Unauthorized > > > > WWW-Authenticate: Token realm=3D"http://example.com/", > > class=3D"oauth", > > > > methods=3D"HMAC Plain-S" > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > the > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > must > > > > send an authenticated response to = https://example.com/resource/1. > > > > > > > > Comments? > > > > > > > > EHL > > > > PS. You'll notice I am throwing a lot of new ideas to the list = for > > > > feedback as I am working on my authentication draft. Feel free = to > > > > bounce your own ideas (thanks James!). > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros From quigley@emerose.com Thu Dec 3 17:22:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDDD73A6920 for ; Thu, 3 Dec 2009 17:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ygcv-9Ve7tKH for ; Thu, 3 Dec 2009 17:22:12 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id E19D93A6403 for ; Thu, 3 Dec 2009 17:22:08 -0800 (PST) Received: by pwi5 with SMTP id 5so976405pwi.29 for ; Thu, 03 Dec 2009 17:21:58 -0800 (PST) Received: by 10.114.6.25 with SMTP id 25mr3234774waf.25.1259889717863; Thu, 03 Dec 2009 17:21:57 -0800 (PST) Received: from ?10.0.1.2? (75-101-96-3.dsl.static.sonic.net [75.101.96.3]) by mx.google.com with ESMTPS id 20sm2105836pzk.13.2009.12.03.17.21.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 03 Dec 2009 17:21:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=windows-1252 From: Sam Quigley In-Reply-To: Date: Thu, 3 Dec 2009 17:21:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> <1259878881.6142.545.camel@localhost> <107A93BA-5E6F-411B-9F06-3E85D4ECF938@emerose.com> To: Brian Eaton X-Mailer: Apple Mail (2.1077) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 01:22:12 -0000 On Dec 3, 2009, at 5:07 PM, Brian Eaton wrote: > On Thu, Dec 3, 2009 at 4:24 PM, Sam Quigley = wrote: >> There might, though, still be room to relax the timestamp = requirement, and make it merely a monotonically increasing counter=85 >=20 > Monotonically increasing counters in distributed systems are a classic > hard problem in computer science. Let's not write a spec that > requires them, please. (Even if you allow for skew in the counter, > you end up needing to do frequent writes to a central server that > maintains the counters. The performance sucks, and the central server > turns into a reliability problem.) Maybe I'm misunderstanding you =97 but timestamps *are* monotonically = increasing counters, and the spec already requires those. = "Monotonically increasing" isn't the same as "strictly increasing"=85 -sq= From eran@hueniverse.com Thu Dec 3 17:24:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE0B3A6403 for ; Thu, 3 Dec 2009 17:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hth9IJOYXGX5 for ; Thu, 3 Dec 2009 17:24:47 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 39A323A693E for ; Thu, 3 Dec 2009 17:24:47 -0800 (PST) Received: (qmail 23519 invoked from network); 4 Dec 2009 01:24:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 01:24:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 18:24:34 -0700 From: Eran Hammer-Lahav To: "Moore, Jonathan (CIM)" , John Panzer , Breno Date: Thu, 3 Dec 2009 18:24:49 -0700 Thread-Topic: [OAUTH-WG] "Upgrade" to HTTPS option Thread-Index: Acp0ePQTSVbEGWpCTzuElqkFdK1iLAAAYmkwAADvRwYAAI+i4A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293504@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259884293.6142.549.camel@localhost><90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET><1259884809.6142.551.camel@localhost><90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 01:24:48 -0000 Yeah... We can revisit this later. I am playing around with using links for some au= thorization discovery but not sure if it makes sense yet. BTW, link draft is at -06 with a -07 coming out shortly. EHL > -----Original Message----- > From: Moore, Jonathan (CIM) [mailto:Jonathan_Moore@Comcast.com] > Sent: Thursday, December 03, 2009 5:16 PM > To: Eran Hammer-Lahav; John Panzer; Breno > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] "Upgrade" to HTTPS option >=20 > What about sending your 401 but adding a Link header[1] pointing to the > HTTPS resource, with a link extension specifying the acceptable methods? >=20 > Like: >=20 > HTTP/1.1 401 Unauthorized > WWW-Authenticate: Token realm=3D"http://example.com/", class=3D"oauth", > methods=3D"HMAC" > Link: ; rel=3D"alternate"; oauth-method=3D"Plain" >=20 > Jon >=20 > [1] http://tools.ietf.org/html/draft-nottingham-http-link-header-03 > ........ > Jon Moore > Comcast Interactive Media >=20 >=20 >=20 > -----Original Message----- > From: oauth-bounces@ietf.org on behalf of Eran Hammer-Lahav > Sent: Thu 12/3/2009 7:41 PM > To: John Panzer; Breno > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >=20 > I think it is safe to conclude this idea does not have legs (2, 3, or oth= erwise). >=20 > EHL >=20 > From: John Panzer [mailto:jpanzer@google.com] > Sent: Thursday, December 03, 2009 4:30 PM > To: Breno > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >=20 > At one point I implemented a system to do a 301 redirect over to an > equivalent https: endpoint if an Authorization:-less request came in for = a > protected resource on an http: URI. The client would then redirect, swit= ch to > SSL, and there would be a regular RFC 2617 Unauthenticated response > followed by a password challenge at the client, followed by a successful > transfer of the base64-encoded password over https. >=20 > The loophole here is if the client ever gets it into its head to pass the= secret > unprovoked over the unprotected http channel (we never issued an RFC > 2617 challenge over the unprotected channel). But if clients are that br= oken > there's little one can do to stop them, really. >=20 > BTW, the above actually worked with most decent feed readers that > supported HTTP Basic. >=20 > -- > John Panzer / Google > jpanzer@google.com / > abstractioneer.org / @jpanzer >=20 >=20 > On Thu, Dec 3, 2009 at 4:23 PM, Breno > > > wrote: > I tend to agree with John. >=20 > I think in most cases, upgrading the channel is the right option if HTTPS= is > available. >=20 > It might be that some endpoints want to support HMAC via HTTP. Why not > simply indicate HMAC as the only available option at the HTTP endpoint? >=20 > On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav > > wrote: > That's an upgrade of the entire channel. What I am talking about is simpl= y to > say, "you want plain text? Sure! But go over there (HTTPS)". >=20 > EHL >=20 > From: John Panzer > [mailto:jpanzer@google.com] > Sent: Thursday, December 03, 2009 4:16 PM > To: Eran Hammer-Lahav > Cc: Paul C. Bryan; OAuth WG (oauth@ietf.org) >=20 > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >=20 > Why doesn't the server just use this? >=20 > http://www.faqs.org/rfcs/rfc2817.html >=20 > -- > John Panzer / Google > jpanzer@google.com / > abstractioneer.org / @jpanzer >=20 > On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav > > wrote: > I am strongly against using XRD for this level of discovery. Requiring mu= ltiple > round trips is one of the reasons Digest failed adoption. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org > > [mailto:oauth-bounces@ietf.org] On > > Behalf Of Paul C. Bryan > > Sent: Thursday, December 03, 2009 4:00 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > > > > > What if the HTTPS URI was explicitly provided, not implied by > > > inserting an 's' into the URI? Not sure what's the best way of > > > providing it, but I'm sure we can find a way... > > > > That's definitely much less of a stretch. :) Perhaps somehow using XRD? > > > > Paul > > > > > > > > EHL > > > > > > > -----Original Message----- > > > > From: oauth-bounces@ietf.org > > > > [mailto:oauth-bounces@ietf.org] On > > > Behalf > > > > Of Paul C. Bryan > > > > Sent: Thursday, December 03, 2009 3:52 PM > > > > To: OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > > How do people feel about the idea of allowing the server to say > > > > > it > > > is > > > > > willing to accept a plaintext request (with or without a secret) > > > but > > > > > only over HTTPS? > > > > > > > > > > This is a bit odd because is conflates the http and https > > > > > schemes > > > to > > > > > discuss the same resource regardless of the scheme, but it is > > > > > how > > > most > > > > > sites deploy their endpoints. > > > > > > > > I think it's wrong for exactly the reason you stated above. The > > > presence of "- > > > > S" means the resource is also exposed at the same hostname, but > > > implicitly > > > > via HTTPS on port 443, with the same URI. This is too much of a > > > stretch for > > > > me. > > > > > > > > > > > > > > For example: > > > > > > > > > > A request for http://example.com/resource/1 will yield the > > > following > > > > > response: > > > > > > > > > > HTTP/1.1 401 Unauthorized > > > > > WWW-Authenticate: Token realm=3D"http://example.com/", > > > class=3D"oauth", > > > > > methods=3D"HMAC Plain-S" > > > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > > the > > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > > must > > > > > send an authenticated response to https://example.com/resource/1. > > > > > > > > > > Comments? > > > > > > > > > > EHL > > > > > PS. You'll notice I am throwing a lot of new ideas to the list > > > > > for feedback as I am working on my authentication draft. Feel > > > > > free to bounce your own ideas (thanks James!). > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > -- > Breno de Medeiros From eran@hueniverse.com Thu Dec 3 17:25:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFEE13A6997 for ; Thu, 3 Dec 2009 17:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY4A2uRy30KR for ; Thu, 3 Dec 2009 17:25:40 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 2889F3A6991 for ; Thu, 3 Dec 2009 17:25:40 -0800 (PST) Received: (qmail 6357 invoked from network); 4 Dec 2009 01:25:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 01:25:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 18:25:26 -0700 From: Eran Hammer-Lahav To: Brian Eaton , Sam Quigley Date: Thu, 3 Dec 2009 18:25:41 -0700 Thread-Topic: [OAUTH-WG] Timestamp and sync Thread-Index: Acp0fjg1zG3SqU/jQ/2z1l5tdiKJ4AAAmSIA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293505@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> <1259878881.6142.545.camel@localhost> <107A93BA-5E6F-411B-9F06-3E85D4ECF938@emerose.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 01:25:41 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Thursday, December 03, 2009 5:08 PM > To: Sam Quigley > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Timestamp and sync >=20 > On Thu, Dec 3, 2009 at 4:24 PM, Sam Quigley > wrote: > > There might, though, still be room to relax the timestamp requirement, > > and make it merely a monotonically increasing counter... >=20 > Monotonically increasing counters in distributed systems are a classic ha= rd > problem in computer science. Let's not write a spec that requires them, > please. (Even if you allow for skew in the counter, you end up needing t= o do > frequent writes to a central server that maintains the counters. The > performance sucks, and the central server turns into a reliability proble= m.) >=20 > I can see a few ways forward here. >=20 > 1) Challenge-response > This requires an extra round trip to establish the base line challeng= e. Do that, and you might as well let the server issue the nonce, and end up w= ith Digest. EHL From beaton@google.com Thu Dec 3 17:34:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7822F3A694E for ; Thu, 3 Dec 2009 17:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT1q-C6eBzI5 for ; Thu, 3 Dec 2009 17:34:56 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 7F8F13A6403 for ; Thu, 3 Dec 2009 17:34:52 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id nB41YgTJ017514 for ; Thu, 3 Dec 2009 17:34:43 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259890483; bh=uVGqcmOUShRp+JQzF/KlDAgeL3Q=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=GhTyeYew7tK0cKlalPkfKkm03IvC7TTkMieiau1ssgk1SUp0AMGXbwv1A0+6yqUhE WTUD+/bA1z4brzojTjX7A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=QBUAgaEKMgHX7D2qGgAGBBp+ctrnMpbcF0mFt3tjlS4HfNR9N0oF8AQjRDb0ADEin uzdXm6xln3JB/oAjTbmhQ== Received: from pwi3 (pwi3.prod.google.com [10.241.219.3]) by wpaz21.hot.corp.google.com with ESMTP id nB41YHki023973 for ; Thu, 3 Dec 2009 17:34:40 -0800 Received: by pwi3 with SMTP id 3so1664861pwi.21 for ; Thu, 03 Dec 2009 17:34:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.45.17 with SMTP id x17mr153650rvj.62.1259890113033; Thu, 03 Dec 2009 17:28:33 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9FA23DE7-320E-4154-AF41-E0AD5B7F10DF@emerose.com> <1259878881.6142.545.camel@localhost> <107A93BA-5E6F-411B-9F06-3E85D4ECF938@emerose.com> Date: Thu, 3 Dec 2009 17:28:32 -0800 Message-ID: From: Brian Eaton To: Sam Quigley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 01:34:57 -0000 On Thu, Dec 3, 2009 at 5:21 PM, Sam Quigley wrote: > Maybe I'm misunderstanding you =97 but timestamps *are* monotonically inc= reasing counters, and the spec already requires those. Timestamps are not monotonically increasing counters. For example: http://www.ece.udel.edu/~mills/leap.html But aside from backwards leap seconds, which are rare, you need to consider the case of multiple computers sending requests at once. Their clocks are not perfectly synchronized, and it is highly likely that one computer will send a timestamp that is less than the timestamp sent from another computer. Cheers, Brian From eran@hueniverse.com Thu Dec 3 19:12:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29E9A3A6968 for ; Thu, 3 Dec 2009 19:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCaGZ5pbgTQs for ; Thu, 3 Dec 2009 19:12:49 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 576873A6926 for ; Thu, 3 Dec 2009 19:12:49 -0800 (PST) Received: (qmail 26512 invoked from network); 4 Dec 2009 03:12:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 03:12:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 3 Dec 2009 20:12:38 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Thu, 3 Dec 2009 20:12:51 -0700 Thread-Topic: RFC2616 vs draft-ietf-httpbis-p7-auth Thread-Index: Acp0j6nq5xsAlNL9RFySpIeL1jUXxw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529351F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AnZh AzpE BNkC BdMt B+u4 DYfT Dhxh DuWq D4HF FBK5 Ffsu F/N3 H2bG PKwo PPJC PTaC; 2; aQBlAHQAZgAtAGgAdAB0AHAALQB3AGcAQAB3ADMALgBvAHIAZwA7AG8AYQB1AHQAaABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {90368BCF-9EFD-4D95-8D96-24BD3CFC9E9D}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Fri, 04 Dec 2009 03:12:51 GMT; UgBGAEMAMgA2ADEANgAgAHYAcwAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBoAHQAdABwAGIAaQBzAC0AcAA3AC0AYQB1AHQAaAA= x-cr-puzzleid: {90368BCF-9EFD-4D95-8D96-24BD3CFC9E9D} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "HTTP Working Group \(ietf-http-wg@w3.org\)" Subject: [OAUTH-WG] RFC2616 vs draft-ietf-httpbis-p7-auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 03:12:50 -0000 The OAuth working group is working to define a new HTTP authentication sche= me. This requires referencing either RFC 2617 or draft-ietf-httpbis-p7-auth= . The goal is to move the spec into last call in 3-6 months. Which ABNF and reference should the new work use? EHL From rbarnes@bbn.com Thu Dec 3 21:01:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C613A6909 for ; Thu, 3 Dec 2009 21:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZu3FXNNNl1q for ; Thu, 3 Dec 2009 21:01:39 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id EA1C73A685D for ; Thu, 3 Dec 2009 21:01:38 -0800 (PST) Received: from [128.89.253.148] (helo=64-129-15-92.static.twtelecom.net) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NGQIL-0002D5-AH; Fri, 04 Dec 2009 00:01:29 -0500 Message-Id: <3BDC5F3D-328B-4BBD-91EF-ED26946A385D@bbn.com> From: Richard Barnes To: George Fletcher In-Reply-To: <4B17C5FD.8030609@aol.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 3 Dec 2009 19:01:26 -1000 References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> <4B17C5FD.8030609@aol.com> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 05:01:39 -0000 +1 Seems like a tool, not a protocol feature. --Richard On Dec 3, 2009, at 4:06 AM, George Fletcher wrote: > +1 > > It's pretty easy to set up a http://example.com/debugOauth resource > that takes the request and validates the signature, returning as > much debug information as possible. > > Thanks, > George > > Ethan Jewett wrote: >> Unless this would somehow help clients to automatically deal with >> error conditions, I don't think it belongs in the base spec. We can >> certainly make some suggestion as to how to accomplish this for API >> designers, but it seems like something that should be left to the >> implementation. >> >> Ethan >> >> On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav > > wrote: >> >>> One of the most common requests I get is to add a debug mode to >>> the protocol, allowing the client to request the server to provide >>> the full signature base string when the signature check fails. >>> Since this part does not affect security (since the base string is >>> obvious from the request), it is a matter of preference whether we >>> should specify such an interface. >>> >>> Comments? >>> >>> EHL >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Dec 3 21:27:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E623A6946 for ; Thu, 3 Dec 2009 21:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TodN85jVY3J for ; Thu, 3 Dec 2009 21:27:44 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D2FAC3A68F2 for ; Thu, 3 Dec 2009 21:27:43 -0800 (PST) Received: (qmail 15711 invoked from network); 4 Dec 2009 05:26:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 05:26:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 3 Dec 2009 22:25:21 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Thu, 3 Dec 2009 22:25:35 -0700 Thread-Topic: Timestamp & Nonce, together or apart Thread-Index: Acp0ojS571sTyJnqSeycruSZ6BYjow== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293535@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: hZc= A2AT BbMR Bgy2 Cmm9 CvlR C4Do Ezb5 E3vZ FFUv G8+Y HE/W HrKf Iaf1 I90k J9gb; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {88AE6CB6-6AA4-48EB-98E8-FD316FD82082}; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA=; Fri, 04 Dec 2009 05:25:35 GMT; VABpAG0AZQBzAHQAYQBtAHAAIAAmACAATgBvAG4AYwBlACwAIAB0AG8AZwBlAHQAaABlAHIAIABvAHIAIABhAHAAYQByAHQA x-cr-puzzleid: {88AE6CB6-6AA4-48EB-98E8-FD316FD82082} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Timestamp & Nonce, together or apart X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 05:27:45 -0000 Here is an semi-bikeshedding question: timestamp=3D"137131200", nonce=3D"dj83hs9s" OR nonce=3D"137131200:dj83hs9s" The only reason to put them together is because they are really two parts o= f the same thing, and are not used separately. The only reason to keep them= separate is to make parsing a tiny bit easier. Comments? EHL From email@pbryan.net Thu Dec 3 21:44:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE7C3A69A4 for ; Thu, 3 Dec 2009 21:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejMsBUY8vw4z for ; Thu, 3 Dec 2009 21:44:15 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 03BE83A6969 for ; Thu, 3 Dec 2009 21:44:15 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id CE5D1EA021 for ; Fri, 4 Dec 2009 05:44:05 +0000 (UTC) From: "Paul C. Bryan" To: "OAuth WG (oauth@ietf.org)" In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293535@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293535@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Dec 2009 21:43:43 -0800 Message-ID: <1259905423.6142.554.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Timestamp & Nonce, together or apart X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 05:44:15 -0000 I'd like my bikeshed painted in two distinct and separate colors: timestamp and nonce. On Thu, 2009-12-03 at 22:25 -0700, Eran Hammer-Lahav wrote: > Here is an semi-bikeshedding question: > > timestamp="137131200", nonce="dj83hs9s" > OR > nonce="137131200:dj83hs9s" > > The only reason to put them together is because they are really two parts of the same thing, and are not used separately. The only reason to keep them separate is to make parsing a tiny bit easier. > > Comments? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Thu Dec 3 22:45:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAD428C0F3 for ; Thu, 3 Dec 2009 22:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.657 X-Spam-Level: X-Spam-Status: No, score=-105.657 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhUTLGV-9f5L for ; Thu, 3 Dec 2009 22:45:13 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id E3A103A67B5 for ; Thu, 3 Dec 2009 22:45:10 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id nB46j0Dr029353 for ; Fri, 4 Dec 2009 06:45:00 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259909101; bh=68TTTqu4Z5vTmNC0odMDH/za618=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Ma4IKOlPgc9g3ONMKhcb60mLH+34zLuj0/sJhQcCQM0A3wWJEfypq2qjDq8ixHK6z LQKgVZN2fpkjdNdONGOzA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=N1H4WRppqgyqJ37HJk4J/iuCeodxZSdKUsTJyQelcYObxQ4SmYNZK2zkKdO4eA6tm LEdZqN2YxPWJ5kbxwa6QA== Received: from pwj17 (pwj17.prod.google.com [10.241.219.81]) by wpaz24.hot.corp.google.com with ESMTP id nB46ivUc001565 for ; Thu, 3 Dec 2009 22:44:57 -0800 Received: by pwj17 with SMTP id 17so2014581pwj.25 for ; Thu, 03 Dec 2009 22:44:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.114.11 with SMTP id r11mr2722728wam.195.1259909097175; Thu, 03 Dec 2009 22:44:57 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852934F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852934DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884293.6142.549.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934DF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1259884809.6142.551.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E723437852934E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934EA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852934F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 3 Dec 2009 22:44:37 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64ee34c2fbc870479e172df X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 06:45:19 -0000 --0016e64ee34c2fbc870479e172df Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yeah, I'm not recommending it :). The other reason not to, if you need one= , is that redirects interact particularly badly with libraries, caches,a nd proxies when you venture beyond GET requests. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 4:41 PM, Eran Hammer-Lahav wrot= e: > I think it is safe to conclude this idea does not have legs (2, 3, or > otherwise). > > > > EHL > > > > *From:* John Panzer [mailto:jpanzer@google.com] > *Sent:* Thursday, December 03, 2009 4:30 PM > *To:* Breno > *Cc:* Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > At one point I implemented a system to do a 301 redirect over to an > equivalent https: endpoint if an Authorization:-less request came in for = a > protected resource on an http: URI. The client would then redirect, swit= ch > to SSL, and there would be a regular RFC 2617 Unauthenticated response > followed by a password challenge at the client, followed by a successful > transfer of the base64-encoded password over https. > > > > The loophole here is if the client ever gets it into its head to pass the > secret unprovoked over the unprotected http channel (we never issued an R= FC > 2617 challenge over the unprotected channel). But if clients are that > broken there's little one can do to stop them, really. > > > > BTW, the above actually worked with most decent feed readers that support= ed > HTTP Basic. > > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > On Thu, Dec 3, 2009 at 4:23 PM, Breno wrote: > > I tend to agree with John. > > > > I think in most cases, upgrading the channel is the right option if HTTPS > is available. > > > > It might be that some endpoints want to support HMAC via HTTP. Why not > simply indicate HMAC as the only available option at the HTTP endpoint? > > > > On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav > wrote: > > That=92s an upgrade of the entire channel. What I am talking about is sim= ply > to say, =93you want plain text? Sure! But go over there (HTTPS)=94. > > > > EHL > > > > *From:* John Panzer [mailto:jpanzer@google.com] > *Sent:* Thursday, December 03, 2009 4:16 PM > *To:* Eran Hammer-Lahav > *Cc:* Paul C. Bryan; OAuth WG (oauth@ietf.org) > > > *Subject:* Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > Why doesn't the server just use this? > > > > http://www.faqs.org/rfcs/rfc2817.html > > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav > wrote: > > I am strongly against using XRD for this level of discovery. Requiring > multiple round trips is one of the reasons Digest failed adoption. > > > EHL > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Paul C. Bryan > > > Sent: Thursday, December 03, 2009 4:00 PM > > To: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote: > > > > > What if the HTTPS URI was explicitly provided, not implied by > > > inserting an 's' into the URI? Not sure what's the best way of > > > providing it, but I'm sure we can find a way... > > > > That's definitely much less of a stretch. :) Perhaps somehow using XRD? > > > > Paul > > > > > > > > EHL > > > > > > > -----Original Message----- > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf > > > > Of Paul C. Bryan > > > > Sent: Thursday, December 03, 2009 3:52 PM > > > > To: OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option > > > > > > > > On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: > > > > > How do people feel about the idea of allowing the server to say i= t > > > is > > > > > willing to accept a plaintext request (with or without a secret) > > > but > > > > > only over HTTPS? > > > > > > > > > > This is a bit odd because is conflates the http and https schemes > > > to > > > > > discuss the same resource regardless of the scheme, but it is how > > > most > > > > > sites deploy their endpoints. > > > > > > > > I think it's wrong for exactly the reason you stated above. The > > > presence of "- > > > > S" means the resource is also exposed at the same hostname, but > > > implicitly > > > > via HTTPS on port 443, with the same URI. This is too much of a > > > stretch for > > > > me. > > > > > > > > > > > > > > For example: > > > > > > > > > > A request for http://example.com/resource/1 will yield the > > > following > > > > > response: > > > > > > > > > > HTTP/1.1 401 Unauthorized > > > > > WWW-Authenticate: Token realm=3D"http://example.com/", > > > class=3D"oauth", > > > > > methods=3D"HMAC Plain-S" > > > > > > > > > > Which means OAuth tokens are accepted using the HMAC method, or > > > the > > > > > Plain method over HTTPS. If the client wishes to use Plain, it > > > must > > > > > send an authenticated response to https://example.com/resource/1. > > > > > > > > > > Comments? > > > > > > > > > > EHL > > > > > PS. You'll notice I am throwing a lot of new ideas to the list fo= r > > > > > feedback as I am working on my authentication draft. Feel free to > > > > > bounce your own ideas (thanks James!). > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Breno de Medeiros > > > --0016e64ee34c2fbc870479e172df Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yeah, I'm not recommending it :). =A0The other reason not to, if you ne= ed one, is that redirects interact particularly badly with libraries, cache= s,a nd proxies when you venture beyond GET requests.
-- John Panzer / Google
jpanzer@googl= e.com / abstractioneer.org / = @jpanzer



On Thu, Dec 3, 2009 at 4:41 PM, Eran Ham= mer-Lahav <eran= @hueniverse.com> wrote:

I think it is safe to co= nclude this idea does not have legs (2, 3, or otherwise).

=A0

EHL

=A0=

Fr= om: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, December 03, 2009 4:30 PM
To: Breno
= Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)


Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option

=A0

At one point I implemented a system t= o do a 301 redirect over to an equivalent https: endpoint if an Authorizati= on:-less request came in for a protected resource on an http: URI. =A0The c= lient would then redirect, switch to SSL, and there would be a regular RFC = 2617 Unauthenticated response followed by a password challenge at the clien= t, followed by a successful transfer of the base64-encoded password over ht= tps.

=A0

The lo= ophole here is if the client ever gets it into its head to pass the secret = unprovoked over the unprotected http channel (we never issued an RFC 2617 c= hallenge over the unprotected channel). =A0But if clients are that broken t= here's little one can do to stop them, really.

=A0

= BTW, the above actually worked with most decent feed readers that supported= HTTP Basic.


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer

On Thu, Dec 3, 2009 at 4:23 PM, Breno <breno.demedeiros= @gmail.com> wrote:

I tend to agree wi= th John.

=A0

= I think in most cases, upgrading the channel is the right option if HTTPS i= s available.

=A0

It might be that some endpoints want to support HMAC via HTTP. Why not simp= ly indicate HMAC as the only available option at the HTTP endpoint?

=A0

On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

<= div>

That=92s an upgrade of the entire channel. What I am talking about is s= imply to say, =93you want plain text? Sure! But go over there (HTTPS)=94.

=A0

EHL

=A0

=A0

Why doesn't the server just use this?

=A0


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer

On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

<= p class=3D"MsoNormal">I am strongly against using XRD for this level of dis= covery. Requiring multiple round trips is one of the reasons Digest failed = adoption.


EHL

> -----Original Message-----<= br>> From: o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Paul C. Bryan

> Sent: = Thursday, December 03, 2009 4:00 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: Re:= [OAUTH-WG] "Upgrade" to HTTPS option
>
> On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote:>
> > What if the HTTPS URI was explicitly provided, not impli= ed by
> > inserting an 's' into the URI? Not sure what'= ;s the best way of
> > providing it, but I'm sure we can find a way...
>
&g= t; That's definitely much less of a stretch. :) Perhaps somehow using X= RD?
>
> Paul
>
> >
> > EHL
> >=
> > > -----Original Message-----
> > > From: oauth-bounces@ietf.org= [mailto:oa= uth-bounces@ietf.org] On
> > Behalf
> > > Of Paul C. Bryan
> > > Sent:= Thursday, December 03, 2009 3:52 PM
> > > To: OAuth WG (oauth@ietf.org)
> &= gt; > Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option
> > >
> > > On Thu, 2009-12-03 at 16:48 -0700, Eran Ha= mmer-Lahav wrote:
> > > > How do people feel about the idea = of allowing the server to say it
> > is
> > > > wil= ling to accept a plaintext request (with or without a secret)
> > but
> > > > only over HTTPS?
> > > >= ;
> > > > This is a bit odd because is conflates the http an= d https schemes
> > to
> > > > discuss the same res= ource regardless of the scheme, but it is how
> > most
> > > > sites deploy their endpoints.
>= > >
> > > I think it's wrong for exactly the reason = you stated above. The
> > presence of "-
> > > S&= quot; means the resource is also exposed at the same hostname, but
> > implicitly
> > > via HTTPS on port 443, with the same= URI. This is too much of a
> > stretch for
> > > me.<= br>> > >
> > > >
> > > > For example= :
> > > >
> > > > A request for http://example.com/resource/1= will yield the
> > following
> > > > response:
> > > >
> > > > =A0 HTTP/1.1 401 Unauthorized> > > > =A0 WWW-Authenticate: Token realm=3D"http://example.com/",
>= ; > class=3D"oauth",
> > > > methods=3D"HMAC Plain-S"
> > > &g= t;
> > > > Which means OAuth tokens are accepted using the H= MAC method, or
> > the
> > > > Plain method over HT= TPS. If the client wishes to use Plain, it
> > must
> > > > send an authenticated response to https://example.c= om/resource/1.
> > > >
> > > > Comments?<= br> > > > >
> > > > EHL
> > > > PS. Y= ou'll notice I am throwing a lot of new ideas to the list for
> &= gt; > > feedback as I am working on my authentication draft. Feel fre= e to
> > > > bounce your own ideas (thanks James!).
> > >= ; > _______________________________________________
> > > &g= t; OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> = > >
> > >
> > > _____________________________= __________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://= www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
>= ; OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth

=A0


________= _______________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Breno de Medeiros

=A0


--0016e64ee34c2fbc870479e172df-- From email@pbryan.net Thu Dec 3 23:06:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC2D3A69B9 for ; Thu, 3 Dec 2009 23:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuogYDZB+ad5 for ; Thu, 3 Dec 2009 23:06:36 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id C37813A67A6 for ; Thu, 3 Dec 2009 23:06:35 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 43A4A6154; Fri, 4 Dec 2009 07:06:26 +0000 (UTC) From: "Paul C. Bryan" To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529351F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529351F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 Dec 2009 23:06:07 -0800 Message-ID: <1259910367.6142.556.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" , "HTTP Working Group \(ietf-http-wg@w3.org\)" Subject: Re: [OAUTH-WG] RFC2616 vs draft-ietf-httpbis-p7-auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 07:06:36 -0000 On Thu, 2009-12-03 at 20:12 -0700, Eran Hammer-Lahav wrote: > The OAuth working group is working to define a new HTTP authentication > scheme. This requires referencing either RFC 2617 or > draft-ietf-httpbis-p7-auth. The goal is to move the spec into last > call in 3-6 months. > > Which ABNF and reference should the new work use? I lean toward draft-ietf-httpbis-p7-auth, for AFAIK, OAuth will only use the response status codes and headers, and nothing related to basic or digest authentication in particular. Paul > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Thu Dec 3 23:15:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E893D3A69BD for ; Thu, 3 Dec 2009 23:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.944 X-Spam-Level: X-Spam-Status: No, score=-105.944 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBePqqXuxUIq for ; Thu, 3 Dec 2009 23:15:39 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 81CB53A68D8 for ; Thu, 3 Dec 2009 23:15:39 -0800 (PST) Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id nB47FUhI022118 for ; Thu, 3 Dec 2009 23:15:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259910931; bh=sLIhLJIpo8FOf7FUZcj2U4Brbpo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=XnCKbUOZSWZ+oGmDI/Q5/f78lY8XzeRsIy4ScSlfc6dvEK+oZHNiJXl4agYwa2cEn WQXeOzcjUxpJp5CK8uy/A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=TMRLwRFTwvKwA57W+ET9x6oUyy37X5EZJWjaaE07mtwbx48fpFhuNHnA0wCQSU0Lf pr1KUN3WAUXNj1OuzCTOg== Received: from pzk41 (pzk41.prod.google.com [10.243.19.169]) by zps77.corp.google.com with ESMTP id nB47FD5x005411 for ; Thu, 3 Dec 2009 23:15:28 -0800 Received: by pzk41 with SMTP id 41so3988786pzk.0 for ; Thu, 03 Dec 2009 23:15:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.165.15 with SMTP id n15mr3725377wae.83.1259910928104; Thu, 03 Dec 2009 23:15:28 -0800 (PST) In-Reply-To: <3BDC5F3D-328B-4BBD-91EF-ED26946A385D@bbn.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> <4B17C5FD.8030609@aol.com> <3BDC5F3D-328B-4BBD-91EF-ED26946A385D@bbn.com> From: John Panzer Date: Thu, 3 Dec 2009 23:15:08 -0800 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=0016367f92a7517ec60479e1dfdb X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 07:15:41 -0000 --0016367f92a7517ec60479e1dfdb Content-Type: text/plain; charset=ISO-8859-1 Well, except that most people will be interacting with this stuff through libraries. Which won't necessarily be granting direct access to whatever extra flags specific services might add like debug headers or query parameters. It might be nice to define some simple, standard way to pass extra metadata with each request that libraries could be aware of for purposes of pass-through. For protected resources there's already a URL under the control of the client, but not necessarily for other endpoints acquired via discovery etc. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 9:01 PM, Richard Barnes wrote: > +1 > > Seems like a tool, not a protocol feature. > > --Richard > > > > > On Dec 3, 2009, at 4:06 AM, George Fletcher wrote: > > +1 >> >> It's pretty easy to set up a http://example.com/debugOauth resource that >> takes the request and validates the signature, returning as much debug >> information as possible. >> >> Thanks, >> George >> >> Ethan Jewett wrote: >> >>> Unless this would somehow help clients to automatically deal with >>> error conditions, I don't think it belongs in the base spec. We can >>> certainly make some suggestion as to how to accomplish this for API >>> designers, but it seems like something that should be left to the >>> implementation. >>> >>> Ethan >>> >>> On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav >>> wrote: >>> >>> One of the most common requests I get is to add a debug mode to the >>>> protocol, allowing the client to request the server to provide the full >>>> signature base string when the signature check fails. Since this part does >>>> not affect security (since the base string is obvious from the request), it >>>> is a matter of preference whether we should specify such an interface. >>>> >>>> Comments? >>>> >>>> EHL >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016367f92a7517ec60479e1dfdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, except that most people will be interacting with this stuff through l= ibraries. =A0Which won't necessarily be granting direct access to whate= ver extra flags specific services might add like debug headers or query par= ameters. =A0

It might be nice to define some simple, standard way to pass= extra metadata with each request that libraries could be aware of for purp= oses of pass-through. =A0For protected resources there's already a URL = under the control of the client, but not necessarily for other endpoints ac= quired via discovery etc.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Thu, Dec 3, 2009 at 9:01 PM, Richard = Barnes <rbarnes@bbn= .com> wrote:
+1

Seems like a tool, not a protocol feature.

--Richard




On Dec 3, 2009, at 4:06 AM, George Fletcher wrote:

+1

It's pretty easy to set up a http://example.com/debugOauth resource that takes the= request and validates the signature, returning as much debug information a= s possible.

Thanks,
George

Ethan Jewett wrote:
Unless this would somehow help clients to automatically deal with
error conditions, I don't think it belongs in the base spec. We can
certainly make some suggestion as to how to accomplish this for API
designers, but it seems like something that should be left to the
implementation.

Ethan

On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

One of the most common requests I get is to add a debug mode to the protoco= l, allowing the client to request the server to provide the full signature = base string when the signature check fails. Since this part does not affect= security (since the base string is obvious from the request), it is a matt= er of preference whether we should specify such an interface.

Comments?

EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016367f92a7517ec60479e1dfdb-- From eran@hueniverse.com Thu Dec 3 23:34:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55FD3A67B5 for ; Thu, 3 Dec 2009 23:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rNzJXEHiMlc for ; Thu, 3 Dec 2009 23:34:38 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id F41B83A635F for ; Thu, 3 Dec 2009 23:34:37 -0800 (PST) Received: (qmail 783 invoked from network); 4 Dec 2009 07:34:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 07:34:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 4 Dec 2009 00:34:25 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Fri, 4 Dec 2009 00:34:39 -0700 Thread-Topic: Challenge/Response complexity Thread-Index: Acp0tDyjoLdZfJVmTd2fgyFPkWWIRw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529353C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Challenge/Response complexity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 07:34:38 -0000 The authentication framework defined in 2616 and 2617 allows for very compl= icated combinations of challenges and responses. For example, servers can p= rovide multiple challenges in separate headers and in a single header, and = clients can respond with a multiple credentials in one request. Do we want to limit this? We are allowed to profile the framework. For exam= ple: * Allow only a single Authorization header when used with the Token scheme. * Forbid more than one challenge per WWW-Authenticate header. The main motivation for these limits comes from the error reporting require= ment. If the server is to provide error information to possible multiple Au= thorization headers, it needs to be able to identify which error is for whi= ch attempt. Also, if a single header can pose multiple challenges, it gets = harder to inline error information with the new challenge (which will requi= re defining a new error header). This is all easy to spec out, but much more work to implement. How do peopl= e feel about adding these restrictions vs. maintaining the full flexibility= of the current framework? EHL From eran@hueniverse.com Thu Dec 3 23:36:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B6D3A67B5 for ; Thu, 3 Dec 2009 23:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT59gskFMYwe for ; Thu, 3 Dec 2009 23:36:21 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7A9F93A65A5 for ; Thu, 3 Dec 2009 23:36:21 -0800 (PST) Received: (qmail 1006 invoked from network); 4 Dec 2009 07:36:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 07:36:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 4 Dec 2009 00:36:12 -0700 From: Eran Hammer-Lahav To: John Panzer , Richard Barnes Date: Fri, 4 Dec 2009 00:36:28 -0700 Thread-Topic: [OAUTH-WG] Debug mode Thread-Index: Acp0sZQK4YyV/KQbQQewCX0+CrZs/gAAtkJg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529353D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> <4B17C5FD.8030609@aol.com> <3BDC5F3D-328B-4BBD-91EF-ED26946A385D@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234378529353DP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 07:36:27 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234378529353DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This would be authentication specific, so debug is pretty much limited to r= eturning the signature base string... EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ohn Panzer Sent: Thursday, December 03, 2009 11:15 PM To: Richard Barnes Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Debug mode Well, except that most people will be interacting with this stuff through l= ibraries. Which won't necessarily be granting direct access to whatever ex= tra flags specific services might add like debug headers or query parameter= s. It might be nice to define some simple, standard way to pass extra metadata= with each request that libraries could be aware of for purposes of pass-th= rough. For protected resources there's already a URL under the control of = the client, but not necessarily for other endpoints acquired via discovery = etc. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 9:01 PM, Richard Barnes > wrote: +1 Seems like a tool, not a protocol feature. --Richard On Dec 3, 2009, at 4:06 AM, George Fletcher wrote: +1 It's pretty easy to set up a http://example.com/debugOauth resource that ta= kes the request and validates the signature, returning as much debug inform= ation as possible. Thanks, George Ethan Jewett wrote: Unless this would somehow help clients to automatically deal with error conditions, I don't think it belongs in the base spec. We can certainly make some suggestion as to how to accomplish this for API designers, but it seems like something that should be left to the implementation. Ethan On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav > wrote: One of the most common requests I get is to add a debug mode to the protoco= l, allowing the client to request the server to provide the full signature = base string when the signature check fails. Since this part does not affect= security (since the base string is obvious from the request), it is a matt= er of preference whether we should specify such an interface. Comments? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E7234378529353DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This woul= d be authentication specific, so debug is pretty much limited to returning = the signature base string…

=  

EHL

 

From: oauth-bounces@ietf.org [mailto:oaut= h-bounces@ietf.org] On Behalf Of John Panzer
Sent: Thursda= y, December 03, 2009 11:15 PM
To: Richard Barnes
Cc: OA= uth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Debug mode

 

Well, except that most people will be interacting with this = stuff through libraries.  Which won't necessarily be granting direct a= ccess to whatever extra flags specific services might add like debug header= s or query parameters.  

=  

It might be nice to define = some simple, standard way to pass extra metadata with each request that lib= raries could be aware of for purposes of pass-through.  For protected = resources there's already a URL under the control of the client, but not ne= cessarily for other endpoints acquired via discovery etc.


--
John Panzer / Google
jpanze= r@google.com / abstractioneer.org= / @jpanzer


On Thu,= Dec 3, 2009 at 9:01 PM, Richard Barnes <rbarnes@bbn.com> wrote:

+1
Seems like a tool, not a protocol feature.

--Richard





On Dec 3, 2009, at 4:06 AM, Geo= rge Fletcher wrote:

+1

It's prett= y easy to set up a http://example.com/debugOauth resource that takes the request and v= alidates the signature, returning as much debug information as possible.
Thanks,
George

Ethan Jewett wrote:

Unless this would somehow help cli= ents to automatically deal with
error conditions, I don't think it belon= gs in the base spec. We can
certainly make some suggestion as to how to = accomplish this for API
designers, but it seems like something that shou= ld be left to the
implementation.

Ethan

On Thu, Dec 3, 200= 9 at 1:55 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

One of the most common requests= I get is to add a debug mode to the protocol, allowing the client to reque= st the server to provide the full signature base string when the signature = check fails. Since this part does not affect security (since the base strin= g is obvious from the request), it is a matter of preference whether we sho= uld specify such an interface.

Comments?

EHL
_____________= __________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth

_____________________________________________= __
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_________________________________= ______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth


_________________________= ______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E7234378529353DP3PW5EX1MB01E_-- From jpanzer@google.com Thu Dec 3 23:45:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED7E23A6842 for ; Thu, 3 Dec 2009 23:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.945 X-Spam-Level: X-Spam-Status: No, score=-105.945 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSZaJDEpuxbX for ; Thu, 3 Dec 2009 23:45:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id A32DD3A67B5 for ; Thu, 3 Dec 2009 23:45:06 -0800 (PST) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id nB47itxJ000803 for ; Fri, 4 Dec 2009 07:44:55 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259912696; bh=RfDrEoQv1rYhH5OQ8EavuAx6yQ0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=U7QYF2/HGy6H1yBjfJAuqL0fURHQuqmR76W+DCCK120XF3NHWVNwREgFBT7PCSxAB BGsgzI9xgU1ujMT/fW9GA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=u6fVs1DiBu2OIRrPIGAAv3JfwLDnZM9X73YDNN16FKWcWqBlb4FdX0R8qWERaImck KmV+gG4+tVgXcPZ89eoSQ== Received: from pwi5 (pwi5.prod.google.com [10.241.219.5]) by zps37.corp.google.com with ESMTP id nB47iqn5008121 for ; Thu, 3 Dec 2009 23:44:53 -0800 Received: by pwi5 with SMTP id 5so1144220pwi.9 for ; Thu, 03 Dec 2009 23:44:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.2.29 with SMTP id 29mr3754463wab.48.1259912692160; Thu, 03 Dec 2009 23:44:52 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529353C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529353C@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 3 Dec 2009 23:44:32 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00504502f5ea76db950479e24819 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Challenge/Response complexity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 07:45:08 -0000 --00504502f5ea76db950479e24819 Content-Type: text/plain; charset=ISO-8859-1 I think it'd be reasonable to allow only a single Authorization: header from client to server when used with the Token scheme. What do you mean by multiple challenges per WWW-Authenticate header? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 11:34 PM, Eran Hammer-Lahav wrote: > The authentication framework defined in 2616 and 2617 allows for very > complicated combinations of challenges and responses. For example, servers > can provide multiple challenges in separate headers and in a single header, > and clients can respond with a multiple credentials in one request. > > Do we want to limit this? We are allowed to profile the framework. For > example: > > * Allow only a single Authorization header when used with the Token scheme. > * Forbid more than one challenge per WWW-Authenticate header. > > The main motivation for these limits comes from the error reporting > requirement. If the server is to provide error information to possible > multiple Authorization headers, it needs to be able to identify which error > is for which attempt. Also, if a single header can pose multiple challenges, > it gets harder to inline error information with the new challenge (which > will require defining a new error header). > > This is all easy to spec out, but much more work to implement. How do > people feel about adding these restrictions vs. maintaining the full > flexibility of the current framework? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00504502f5ea76db950479e24819 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think it'd be reasonable to allow only a single Authorization: header= from client to server when used with the Token scheme.

= What do you mean by multiple challenges per WWW-Authenticate header?=A0
--
John Panzer / Google
jpanzer= @google.com / abstractioneer.org<= /a> / @jpanzer



On Thu, Dec 3, 2009 at 11:34 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
The authentication framework defined in 2616 and 2617 allows for very compl= icated combinations of challenges and responses. For example, servers can p= rovide multiple challenges in separate headers and in a single header, and = clients can respond with a multiple credentials in one request.

Do we want to limit this? We are allowed to profile the framework. For exam= ple:

* Allow only a single Authorization header when used with the Token scheme.=
* Forbid more than one challenge per WWW-Authenticate header.

The main motivation for these limits comes from the error reporting require= ment. If the server is to provide error information to possible multiple Au= thorization headers, it needs to be able to identify which error is for whi= ch attempt. Also, if a single header can pose multiple challenges, it gets = harder to inline error information with the new challenge (which will requi= re defining a new error header).

This is all easy to spec out, but much more work to implement. How do peopl= e feel about adding these restrictions vs. maintaining the full flexibility= of the current framework?

EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--00504502f5ea76db950479e24819-- From jpanzer@google.com Thu Dec 3 23:49:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBB53A677E for ; Thu, 3 Dec 2009 23:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.947 X-Spam-Level: X-Spam-Status: No, score=-105.947 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZwReFgUs7Zx for ; Thu, 3 Dec 2009 23:49:57 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 91A403A6778 for ; Thu, 3 Dec 2009 23:49:57 -0800 (PST) Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id nB47nlV9021756 for ; Thu, 3 Dec 2009 23:49:47 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259912988; bh=AHynXV2BfmfZ2hYqcWX97/Q0OIA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BkpbwUksfRwZbrY2iF/qlkPhAHUWlOzEWbak933N4jcbAUoFGbu6n+braRfrF43TH sWBcsQXdyxRaaJdKJVtDg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=mmSiugBELXnppSDXFV0hxC+LEQljQ3HPRH8i5r/c1n4T+GfI9sP9gYYb6WQkBmuHs eU/XpHp/OGyCMo3YEj26Q== Received: from pzk32 (pzk32.prod.google.com [10.243.19.160]) by spaceape13.eur.corp.google.com with ESMTP id nB47nd7c000824 for ; Thu, 3 Dec 2009 23:49:41 -0800 Received: by pzk32 with SMTP id 32so2136392pzk.21 for ; Thu, 03 Dec 2009 23:49:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.84.40 with SMTP id m40mr3574641wal.192.1259912538160; Thu, 03 Dec 2009 23:42:18 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529353D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> <4B17C5FD.8030609@aol.com> <3BDC5F3D-328B-4BBD-91EF-ED26946A385D@bbn.com> <90C41DD21FB7C64BB94121FBBC2E7234378529353D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Thu, 3 Dec 2009 23:41:58 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64ccb9c48fed40479e23ffa X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 07:49:59 -0000 --0016e64ccb9c48fed40479e23ffa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So establish a loose convention of adding ?token_debug=3D1 to resource URLs and move on? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 11:36 PM, Eran Hammer-Lahav wro= te: > This would be authentication specific, so debug is pretty much limited to > returning the signature base string=85 > > > > EHL > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *John Panzer > *Sent:* Thursday, December 03, 2009 11:15 PM > *To:* Richard Barnes > *Cc:* OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Debug mode > > > > Well, except that most people will be interacting with this stuff through > libraries. Which won't necessarily be granting direct access to whatever > extra flags specific services might add like debug headers or query > parameters. > > > > It might be nice to define some simple, standard way to pass extra metada= ta > with each request that libraries could be aware of for purposes of > pass-through. For protected resources there's already a URL under the > control of the client, but not necessarily for other endpoints acquired v= ia > discovery etc. > > > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > On Thu, Dec 3, 2009 at 9:01 PM, Richard Barnes wrote: > > +1 > > Seems like a tool, not a protocol feature. > > --Richard > > > > > > On Dec 3, 2009, at 4:06 AM, George Fletcher wrote: > > +1 > > It's pretty easy to set up a http://example.com/debugOauth resource that > takes the request and validates the signature, returning as much debug > information as possible. > > Thanks, > George > > Ethan Jewett wrote: > > Unless this would somehow help clients to automatically deal with > error conditions, I don't think it belongs in the base spec. We can > certainly make some suggestion as to how to accomplish this for API > designers, but it seems like something that should be left to the > implementation. > > Ethan > > On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav > wrote: > > One of the most common requests I get is to add a debug mode to the > protocol, allowing the client to request the server to provide the full > signature base string when the signature check fails. Since this part doe= s > not affect security (since the base string is obvious from the request), = it > is a matter of preference whether we should specify such an interface. > > Comments? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --0016e64ccb9c48fed40479e23ffa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So establish a loose convention of adding ?token_debug=3D1 to resource URLs= and move on?
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Thu, Dec 3, 2009 at 11:36 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:

This would be authentica= tion specific, so debug is pretty much limited to returning the signature b= ase string=85

=A0

EHL

=A0

From: oauth-bounces@ietf.org [mailto:= oauth-bounces@i= etf.org] On Behalf Of John Panzer
Sent: Thursday, December 03, 2009 11:15 PM
To: Richard Bar= nes
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Debug mode

=A0

Well, except that most people will be interacting w= ith this stuff through libraries. =A0Which won't necessarily be grantin= g direct access to whatever extra flags specific services might add like de= bug headers or query parameters. =A0

=A0

It mig= ht be nice to define some simple, standard way to pass extra metadata with = each request that libraries could be aware of for purposes of pass-through.= =A0For protected resources there's already a URL under the control of = the client, but not necessarily for other endpoints acquired via discovery = etc.


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer


On Thu, Dec 3, 2009 at 9:01 PM, Ric= hard Barnes <rbarne= s@bbn.com> wrote:

+1

Seems like a t= ool, not a protocol feature.

--Richard





On Dec 3, 2009, = at 4:06 AM, George Fletcher wrote:

+1

It&#= 39;s pretty easy to set up a http://example.com/debugOauth resource that takes the req= uest and validates the signature, returning as much debug information as po= ssible.

Thanks,
George

Ethan Jewett wrote:

Unless this would somehow help clients to au= tomatically deal with
error conditions, I don't think it belongs in = the base spec. We can
certainly make some suggestion as to how to accomplish this for API
desi= gners, but it seems like something that should be left to the
implementa= tion.

Ethan

On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav= <eran@hueniver= se.com> wrote:

One of the most commo= n requests I get is to add a debug mode to the protocol, allowing the clien= t to request the server to provide the full signature base string when the = signature check fails. Since this part does not affect security (since the = base string is obvious from the request), it is a matter of preference whet= her we should specify such an interface.

Comments?

EHL
_______________________________________________=
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_____________= __________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth

____________________________________________= ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /p>


_______________________________________________<= br>OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=A0


--0016e64ccb9c48fed40479e23ffa-- From eran@hueniverse.com Fri Dec 4 00:04:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20EE3A6778 for ; Fri, 4 Dec 2009 00:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJvjUVhCqDEw for ; Fri, 4 Dec 2009 00:04:00 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AC8303A67B5 for ; Fri, 4 Dec 2009 00:04:00 -0800 (PST) Received: (qmail 8509 invoked from network); 4 Dec 2009 08:03:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 08:03:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 4 Dec 2009 01:03:50 -0700 From: Eran Hammer-Lahav To: John Panzer Date: Fri, 4 Dec 2009 01:04:06 -0700 Thread-Topic: [OAUTH-WG] Challenge/Response complexity Thread-Index: Acp0ta4GcIxr7pUJRgi35LBJwYYdpAAAp5bw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293542@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529353C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785293542P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Challenge/Response complexity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 08:04:02 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785293542P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I mean this: WWW-Autenticate: Basic realm=3D"X1", Digest realm=3D"X1", domain=3D"http://= example.com", Basic realm=3D"X2" Which is nasty but fully compliant. See related thread on HTTPbis. EHL From: John Panzer [mailto:jpanzer@google.com] Sent: Thursday, December 03, 2009 11:45 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Challenge/Response complexity I think it'd be reasonable to allow only a single Authorization: header fro= m client to server when used with the Token scheme. What do you mean by multiple challenges per WWW-Authenticate header? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 11:34 PM, Eran Hammer-Lahav > wrote: The authentication framework defined in 2616 and 2617 allows for very compl= icated combinations of challenges and responses. For example, servers can p= rovide multiple challenges in separate headers and in a single header, and = clients can respond with a multiple credentials in one request. Do we want to limit this? We are allowed to profile the framework. For exam= ple: * Allow only a single Authorization header when used with the Token scheme. * Forbid more than one challenge per WWW-Authenticate header. The main motivation for these limits comes from the error reporting require= ment. If the server is to provide error information to possible multiple Au= thorization headers, it needs to be able to identify which error is for whi= ch attempt. Also, if a single header can pose multiple challenges, it gets = harder to inline error information with the new challenge (which will requi= re defining a new error header). This is all easy to spec out, but much more work to implement. How do peopl= e feel about adding these restrictions vs. maintaining the full flexibility= of the current framework? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343785293542P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I mean th= is:

 

WWW-Autenticate: Basic realm=3D"X1"= , Digest realm=3D"X1", domain=3D"http://example.com", Basic realm=3D"X2"

 

Which is nasty but fully compliant. See related thread on HTTPbi= s.

 

EHL

 

From: John Panzer [mailto:jpanzer@google.com]
Sent: Thursday= , December 03, 2009 11:45 PM
To: Eran Hammer-Lahav
Cc: = OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Challenge/Respo= nse complexity

&= nbsp;

I think it'd be reasonable to allow onl= y a single Authorization: header from client to server when used with the T= oken scheme.

 

<= /div>

What do you m= ean by multiple challenges per WWW-Authenticate header? 
--
John Panzer / Google
jpanz= er@google.com / abstractioneer.or= g / @jpanzer


On Thu= , Dec 3, 2009 at 11:34 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

The authentication framework defined in 2616 and 2617 allows for ve= ry complicated combinations of challenges and responses. For example, serve= rs can provide multiple challenges in separate headers and in a single head= er, and clients can respond with a multiple credentials in one request.
=
Do we want to limit this? We are allowed to profile the framework. For = example:

* Allow only a single Authorization header when used with t= he Token scheme.
* Forbid more than one challenge per WWW-Authenticate h= eader.

The main motivation for these limits comes from the error rep= orting requirement. If the server is to provide error information to possib= le multiple Authorization headers, it needs to be able to identify which er= ror is for which attempt. Also, if a single header can pose multiple challe= nges, it gets harder to inline error information with the new challenge (wh= ich will require defining a new error header).

This is all easy to s= pec out, but much more work to implement. How do people feel about adding t= hese restrictions vs. maintaining the full flexibility of the current frame= work?

EHL
_______________________________________________
OAut= h mailing list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785293542P3PW5EX1MB01E_-- From hubertlvg@gmail.com Fri Dec 4 01:10:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5D03A695C for ; Fri, 4 Dec 2009 01:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qSXZVsr1klG for ; Fri, 4 Dec 2009 01:10:07 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id A1B2E3A6929 for ; Fri, 4 Dec 2009 01:10:06 -0800 (PST) Received: by ewy8 with SMTP id 8so2611241ewy.15 for ; Fri, 04 Dec 2009 01:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eAZfmVzVzdtU/RM02dpAhmmr5lSdy9TH6uKVesENKqs=; b=tW/iughtvzcmfG2tOifElwYPj+jdZUZbEepUcK1uw2DXbjbeI/dMJ7Os8uEfKSwapF nuOqeaMi0IiDmk1P4iYe8bXHDbTycDWNl8QYAJw6Hy6zOSgwBboYe9abWKGl00nelkwR 7rBkV822YAbepuXAHURAuEAMkCg0phfa+KEb0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=lqSM5NYw6i588ZG6pyYN3jh15Q6neNckwXRPJtCO8wz7hqLFQdz71Imsz+I3A/Z+uO H/B9GnJkEjGSKhCuNucpiNJFL6eVVMm3xMxUIiQ0LRkRpJPXRKD0nfFm/dsmPuYGTC0V nTCDlLUg6hl8NAqtw5CvQX/n5Zi5j0DuMNm5M= MIME-Version: 1.0 Received: by 10.213.37.203 with SMTP id y11mr4241762ebd.29.1259917794648; Fri, 04 Dec 2009 01:09:54 -0800 (PST) In-Reply-To: <6c0fd2bc0912040108u521b6225ua38c4224c2e79a2b@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> <4B17C5FD.8030609@aol.com> <3BDC5F3D-328B-4BBD-91EF-ED26946A385D@bbn.com> <90C41DD21FB7C64BB94121FBBC2E7234378529353D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0912040108u521b6225ua38c4224c2e79a2b@mail.gmail.com> Date: Fri, 4 Dec 2009 10:09:54 +0100 Message-ID: <6c0fd2bc0912040109j3a1ba65cv84746a63a619ab58@mail.gmail.com> From: Hubert Le Van Gong To: oauth@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 09:10:10 -0000 I agree this might be useful but I don't think this belongs to the base spe= c. Presumably most implementation already include some ways of retrieving the request and all its headers, parameters. Hubert On Fri, Dec 4, 2009 at 8:41 AM, John Panzer wrote: > So establish a loose convention of adding ?token_debug=3D1 to resource UR= Ls > and move on? > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > > > > On Thu, Dec 3, 2009 at 11:36 PM, Eran Hammer-Lahav > wrote: >> >> This would be authentication specific, so debug is pretty much limited t= o >> returning the signature base string=85 >> >> >> >> EHL >> >> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f >> John Panzer >> Sent: Thursday, December 03, 2009 11:15 PM >> To: Richard Barnes >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Debug mode >> >> >> >> Well, except that most people will be interacting with this stuff throug= h >> libraries. =A0Which won't necessarily be granting direct access to whate= ver >> extra flags specific services might add like debug headers or query >> parameters. >> >> >> >> It might be nice to define some simple, standard way to pass extra >> metadata with each request that libraries could be aware of for purposes= of >> pass-through. =A0For protected resources there's already a URL under the >> control of the client, but not necessarily for other endpoints acquired = via >> discovery etc. >> >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer >> >> >> On Thu, Dec 3, 2009 at 9:01 PM, Richard Barnes wrote: >> >> +1 >> >> Seems like a tool, not a protocol feature. >> >> --Richard >> >> >> >> On Dec 3, 2009, at 4:06 AM, George Fletcher wrote: >> >> +1 >> >> It's pretty easy to set up a http://example.com/debugOauth resource that >> takes the request and validates the signature, returning as much debug >> information as possible. >> >> Thanks, >> George >> >> Ethan Jewett wrote: >> >> Unless this would somehow help clients to automatically deal with >> error conditions, I don't think it belongs in the base spec. We can >> certainly make some suggestion as to how to accomplish this for API >> designers, but it seems like something that should be left to the >> implementation. >> >> Ethan >> >> On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav >> wrote: >> >> One of the most common requests I get is to add a debug mode to the >> protocol, allowing the client to request the server to provide the full >> signature base string when the signature check fails. Since this part do= es >> not affect security (since the base string is obvious from the request),= it >> is a matter of preference whether we should specify such an interface. >> >> Comments? >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From Bart.bv.Vrancken@alcatel-lucent.com Fri Dec 4 01:11:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3433A6960 for ; Fri, 4 Dec 2009 01:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5JDg03EIwcw for ; Fri, 4 Dec 2009 01:11:46 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 3FBA53A695C for ; Fri, 4 Dec 2009 01:11:46 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nB49BLs8030873 for ; Fri, 4 Dec 2009 10:11:34 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 10:11:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Dec 2009 10:11:15 +0100 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E045C77BC@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4B1830FA.7000402@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] multi-level delegation Thread-Index: Acp0YaihepT+Qic8TheubYCO+WoMSwAW3YeA References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5710F82C0E73B04FA559560098BF95B124EEB6B910@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4B1830FA.7000402@stpeter.im> From: "Vrancken Bart bv" To: X-OriginalArrivalTime: 04 Dec 2009 09:11:15.0973 (UTC) FILETIME=[BBADF350:01CA74C1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: [OAUTH-WG] multi-level delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 09:11:48 -0000 Hi folks, An example of a case of multi-level delegation, formerly known as "four-legged auth" is described in the ID http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-00 . If we have a server that acts as a content manager or a mash-up for one or multiple web services that uses OAuth and we want different clients to connect to this server, with the standard, like it is today, we have 2 possibilities: 1. We distribute the OAuth credentials from the server to the different client. (What is against the philosophy of OAuth and sometimes not even possible) 2. We act as a proxy and the client can get all the content from our server. (And why would we like to generate unnecessary internet traffic, the idea of OAuth is to grant direct access) If we assume that the server and the clients are part of 1 application (act as one client/consumer) and we are not happy that credentials in client applications could easily be hacked, the system described in the ID will give some extra security. The hacked credentials are only valid for one specific client. A policy could be that credentials on such clients are more limited in time and limited in rights to improve the security. The user mustn't be involved anymore to renew these credentials, because the server could grant permission. Another case could be that a user wants to grant a printing service (the famous case in the original ID :-)) to have access to its private photos stored at different photo sharing services, via a content manager. The user shouldn't be bothered to go to the whole authorization flows again, if the content manager could prove that he can act on the behalf of the user. These are just 2 cases, but I can assume there are a lot more... Best regards, Bart Vrancken From Bart.bv.Vrancken@alcatel-lucent.com Fri Dec 4 01:22:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A842C3A68EA for ; Fri, 4 Dec 2009 01:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2nCHSER3V4A for ; Fri, 4 Dec 2009 01:22:43 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 240F53A696F for ; Fri, 4 Dec 2009 01:22:42 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id nB49Ag86030417 for ; Fri, 4 Dec 2009 10:11:35 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 10:11:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA74C1.BAA8C5B1" Date: Fri, 4 Dec 2009 10:11:12 +0100 Message-ID: <7A6D4815C5E8F74988784FEBD50F2F1E045C77BB@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Debug mode Thread-Index: Acp0sZV0fiam1I4dQpiGc5P9udyWuAACuQow References: <90C41DD21FB7C64BB94121FBBC2E7234378520A482@P3PW5EX1MB01.EX1.SECURESERVER.NET><68f4a0e80912030528l3ec1151fx5d6ab902045001d6@mail.gmail.com> <4B17C5FD.8030609@aol.com><3BDC5F3D-328B-4BBD-91EF-ED26946A385D@bbn.com> From: "Vrancken Bart bv" To: X-OriginalArrivalTime: 04 Dec 2009 09:11:14.0302 (UTC) FILETIME=[BAAEF9E0:01CA74C1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: Re: [OAUTH-WG] Debug mode X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 09:22:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA74C1.BAA8C5B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I expect that the library will offer such a debug mode as a feature, but that it is not included in the spec, because it doesn't bring extra value to the protocol it self.=20 And like Peter said, *ouch*, if the protocol needs a debug mode ... =20 ________________________________ From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Panzer Sent: vrijdag 4 december 2009 8:15 To: Richard Barnes Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Debug mode =20 Well, except that most people will be interacting with this stuff through libraries. Which won't necessarily be granting direct access to whatever extra flags specific services might add like debug headers or query parameters. =20 =20 It might be nice to define some simple, standard way to pass extra metadata with each request that libraries could be aware of for purposes of pass-through. For protected resources there's already a URL under the control of the client, but not necessarily for other endpoints acquired via discovery etc. -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Thu, Dec 3, 2009 at 9:01 PM, Richard Barnes wrote: +1 Seems like a tool, not a protocol feature. --Richard On Dec 3, 2009, at 4:06 AM, George Fletcher wrote: +1 It's pretty easy to set up a http://example.com/debugOauth resource that takes the request and validates the signature, returning as much debug information as possible. Thanks, George Ethan Jewett wrote: Unless this would somehow help clients to automatically deal with error conditions, I don't think it belongs in the base spec. We can certainly make some suggestion as to how to accomplish this for API designers, but it seems like something that should be left to the implementation. Ethan On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav wrote: One of the most common requests I get is to add a debug mode to the protocol, allowing the client to request the server to provide the full signature base string when the signature check fails. Since this part does not affect security (since the base string is obvious from the request), it is a matter of preference whether we should specify such an interface. Comments? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 ------_=_NextPart_001_01CA74C1.BAA8C5B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I expect that = the library will offer such a debug mode as a feature, but that it is not included = in the spec, because it doesn’t bring extra value to the protocol it = self.

And like Peter = said, *ouch*, if the protocol needs a = debug mode …

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of John Panzer
Sent: vrijdag 4 december = 2009 8:15
To: Richard Barnes
Cc: OAuth WG = (oauth@ietf.org)
Subject: Re: [OAUTH-WG] = Debug mode

 

Well, except that most people will be interacting with this = stuff through libraries.  Which won't necessarily be granting direct = access to whatever extra flags specific services might add like debug headers or = query parameters.  

 

It might be nice to define some simple, standard way to pass = extra metadata with each request that libraries could be aware of for purposes = of pass-through.  For protected resources there's already a URL under = the control of the client, but not necessarily for other endpoints acquired = via discovery etc.


--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer


On Thu, Dec 3, 2009 at 9:01 PM, Richard Barnes <rbarnes@bbn.com> = wrote:

+1

Seems like a tool, not a protocol feature.

--Richard





On Dec 3, 2009, at 4:06 AM, George Fletcher = wrote:

+1

It's pretty easy to set up a http://example.com/debugOauth resource that takes = the request and validates the signature, returning as much debug information = as possible.

Thanks,
George

Ethan Jewett wrote:

Unless this = would somehow help clients to automatically deal with
error conditions, I don't think it belongs in the base spec. We can
certainly make some suggestion as to how to accomplish this for API
designers, but it seems like something that should be left to the
implementation.

Ethan

On Thu, Dec 3, 2009 at 1:55 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

One of the = most common requests I get is to add a debug mode to the protocol, allowing the = client to request the server to provide the full signature base string when the = signature check fails. Since this part does not affect security (since the base = string is obvious from the request), it is a matter of preference whether we = should specify such an interface.

Comments?

EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

______________________________________________= _
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

 

------_=_NextPart_001_01CA74C1.BAA8C5B1-- From zachary.zeltsan@alcatel-lucent.com Fri Dec 4 04:40:04 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F01B3A6A00 for ; Fri, 4 Dec 2009 04:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS8pJ+7IxQC8 for ; Fri, 4 Dec 2009 04:40:03 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 07BDC3A68CC for ; Fri, 4 Dec 2009 04:40:02 -0800 (PST) Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id nB4CdnYh003594; Fri, 4 Dec 2009 06:39:49 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id nB4CdmuU017438; Fri, 4 Dec 2009 06:39:49 -0600 (CST) Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Fri, 4 Dec 2009 06:39:48 -0600 From: "Zeltsan, Zachary (Zachary)" To: Peter Saint-Andre Date: Fri, 4 Dec 2009 06:39:47 -0600 Thread-Topic: multi-level delegation (was: Re: [OAUTH-WG] why are we signing?; OAuth 2.0 / Charter) Thread-Index: Acp0YahaKEAqTquHTmmijFGiYlF56gAeMnHA Message-ID: <5710F82C0E73B04FA559560098BF95B124EEBB8994@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785102B49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5710F82C0E73B04FA559560098BF95B124EEB6B910@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> <4B1830FA.7000402@stpeter.im> In-Reply-To: <4B1830FA.7000402@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: Hardt , Dick, "oauth@ietf.org" Subject: Re: [OAUTH-WG] multi-level delegation (was: Re: why are we signing?; OAuth 2.0 / Charter) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 12:40:04 -0000 =20 On Thu, Dec 3, 2009 at 4:43 PM, Peter Saint-Andre wrote: > >=20 [....]=20 > Without getting into the whole issue of re-chartering (yet),=20 > I do think it would be helpful to have more discussion about=20 > the draft you mention (because we know that multi-level=20 > delegation, formerly known as "four-legged auth", is=20 > something that people are interested in). Feel free to start=20 > a separate thread about that, or reply to this message. > Peter It is also my impression that there is interest in multi-level delegation.= =20 As you have suggested, Bart Vrancken has just started such a thread (Subjec= t: multi-level delegation). Zachary= From James.H.Manger@team.telstra.com Fri Dec 4 05:59:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17B13A68A2 for ; Fri, 4 Dec 2009 05:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpzmXqLo5I7Z for ; Fri, 4 Dec 2009 05:59:50 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id C1E8F3A6923 for ; Fri, 4 Dec 2009 05:59:49 -0800 (PST) Received: from unknown (HELO mailai.ntcif.telstra.com.au) ([202.12.162.17]) by mailipbi.ntcif.telstra.com.au with ESMTP; 05 Dec 2009 00:59:40 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.ntcif.telstra.com.au (Postfix) with ESMTP id 2DAE3FF81; Sat, 5 Dec 2009 00:59:40 +1100 (EST) Received: from WSMSG3702.srv.dir.telstra.com (wsmsg3702.srv.dir.telstra.com [172.49.40.170]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 8DACB41D04; Sat, 5 Dec 2009 00:59:16 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Sat, 5 Dec 2009 00:59:39 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Sat, 5 Dec 2009 00:59:34 +1100 Thread-Topic: Timestamp & Nonce, together or apart Thread-Index: Acp0ojS571sTyJnqSeycruSZ6BYjowAQ+Yew Message-ID: <255B9BB34FB7D647A506DC292726F6E1124AA02D39@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293535@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293535@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {97DB89BA-252D-4BE9-B685-CF311C1BA3F4} x-cr-hashedpuzzle: AEFK BRte CHof CTHj Depr EcrZ H/LB Ivf9 JHIa KLBk NNvO NO7e Oo5D O14T PGjE RLNf; 2; ZQByAGEAbgBAAGgAdQBlAG4AaQB2AGUAcgBzAGUALgBjAG8AbQA7AG8AYQB1AHQAaABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {97DB89BA-252D-4BE9-B685-CF311C1BA3F4}; agBhAG0AZQBzAC4AaAAuAG0AYQBuAGcAZQByAEAAdABlAGEAbQAuAHQAZQBsAHMAdAByAGEALgBjAG8AbQA=; Fri, 04 Dec 2009 13:59:34 GMT; UgBFADoAIABUAGkAbQBlAHMAdABhAG0AcAAgACYAIABOAG8AbgBjAGUALAAgAHQAbwBnAGUAdABoAGUAcgAgAG8AcgAgAGEAcABhAHIAdAA= acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Timestamp & Nonce, together or apart X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 13:59:50 -0000 PiAgICAgICAgICAgICAgICAgICAgICAgIHRpbWVzdGFtcD0iMTM3MTMxMjAwIiwgIG5vbmNlPSJk ajgzaHM5cyINCj4gT1INCj4gICAgICAgICAgICAgICAgICAgICAgICBub25jZT0iMTM3MTMxMjAw OmRqODNoczlzIg0KDQpNeSBzdWdnZXN0aW9uOiAgIHQ9MTM3MTMxMjAwLjY1NzU3DQoNClRpbWUg aW4gc2Vjb25kcyBzaW5jZSAxOTcwIGFzIGEgcmVhbCBudW1iZXIgKGllIGNhbiBoYXZlIGEgZGVj aW1hbCBwb2ludCkuDQpTZXJ2ZXIgYWNjZXB0cyBhbnkgdmFsdWUgdGhhdCBpcyAicmVjZW50IGVu b3VnaCIgYW5kIGhhc24ndCBiZWVuIHNlZW4gYmVmb3JlLg0KU2VydmVyIHNob3VsZCBub3QgZ2Vu ZXJhbGx5IHJlcXVpcmUgc3RyaWN0bHkgaW5jcmVhc2luZyB2YWx1ZXMgKHRvIGNvcGUgd2l0aCBy ZW9yZGVyaW5nIG9mIHJlcXVlc3RzIG9yIGRpc3RyaWJ1dGVkIGNsaWVudHMgLS0gdW5sZXNzIG9y ZGVyaW5nIGlzIGNydWNpYWwgZm9yIHRoZSBzcGVjaWZpYyBhcHApLg0KU2VydmVycyBzaG91bGQg dXNlIHN0cmluZyBjb21wYXJpc29ucyB0byBjaGVjayBpZiBhIHZhbHVlIGhhcyBiZWVuIHNlZW4g YmVmb3JlIHRvIGF2b2lkIGFueSBmbG9hdGluZyBwb2ludCBsaW1pdGF0aW9ucyAoY2xpZW50IGNh biBzZW5kIHZhbHVlcyB3aXRoIGFueSAocmVhc29uYWJsZSkgcHJlY2lzaW9uKS4NCg0KQ2xpZW50 cyBjYW4gYXBwZW5kIGV4dHJhIGRpZ2l0cyAocmFuZG9tIG9yIGluY3JlbWVudGluZykgKGFmdGVy IHRoZSBkZWNpbWFsIHBvaW50KSBpZiBuZWNlc3NhcnkuIEEgZGlzdHJpYnV0ZWQgY2xpZW50IGNv dWxkIGRvIHRoaXMgdG8gKHN0YXRpc3RpY2FsbHkpIGVuc3VyZSB2YWx1ZXMgYXJlIHVuaXF1ZS4N CkEgZmFzdCBjbGllbnQgKG1ha2luZyBtdWx0aXBsZSByZXF1ZXN0cyBwZXIgY2xvY2sgdGljaykg Y291bGQgZG8gdGhpcy4NCkFueSBjbGllbnQgY291bGQgZG8gdGhpcyB0byBlbnN1cmUgdGhlIHZh bHVlIGlzIG5vdCBwcmVkaWN0YWJsZSAob3Igc3ViamVjdCB0byBtYW5pcHVsYXRpb24gYnkgYSBz ZXJ2ZXIgcHJldGVuZGluZyBpdHMgY2xvY2sgd2FzIGEgc3BlY2lmaWMgdGltZSkuDQoNCg0KQSBj bGllbnQgY2FuIGRldGVybWluZSB0aGUgdGltZSBhdCB0aGUgc2VydmVyIGZyb20gdGhlIERhdGUg YW5kIG9wdGlvbmFsIEFnZSBIVFRQIGhlYWRlciBmaWVsZHMuDQpUaG9zZSBzaG91bGQgYmUgZW5v dWdoLiBJdCBzb3VuZHMgbGlrZSBhbiBleHBsaWNpdCBzdWdnZXN0aW9uIGZvciBjbGllbnRzIHRv IGxvb2sgYXQgdGhvc2UgbWlnaHQgYmUgaGVscGZ1bC4NCg0KDQotLSANCkphbWVzIE1hbmdlcg0K DQo= From jricher@mitre.org Fri Dec 4 06:28:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE583A6922 for ; Fri, 4 Dec 2009 06:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl366PzvKVcY for ; Fri, 4 Dec 2009 06:28:27 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 1514B3A68DB for ; Fri, 4 Dec 2009 06:28:26 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id nB4ESHHZ032279 for ; Fri, 4 Dec 2009 09:28:17 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id nB4ESG8g032269; Fri, 4 Dec 2009 09:28:16 -0500 Received: from [129.83.50.47] (129.83.50.47) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.1.375.2; Fri, 4 Dec 2009 09:28:16 -0500 From: Justin Richer To: Idan Gazit In-Reply-To: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> Content-Type: text/plain Date: Fri, 4 Dec 2009 09:28:16 -0500 Message-ID: <1259936896.26062.9.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 14:28:29 -0000 When I was doing my implementations of 1.0, I kept a printout of the original diagrams on my desk. They were much more helpful than the actual technical spec for most of the implementation details that I cared about, particularly since I was using a library for each part and simply needed to know when to call what. I also re-used them in all of my evangelistic talks on OAuth around the company. Thank you for updating them to rev. a! I'd like to see these (or diagrams much like them) included in the specs (or part of an "implementor's guide") in the future. -- Justin On Tue, 2009-12-01 at 19:21 -0500, Idan Gazit wrote: > Hey folks, > > I redrew/updated an old diagram (http://documentation.fring.com/images/1/11/Oauth_diagram.png > ) outlining the OAuth authentication flow. The old one didn't reflect > the changes in 1.0a. > > The updated diagrams are here: > > http://s3.pixane.com/Oauth_diagram.png > http://s3.pixane.com/Oauth_diagram.pdf > > Please feel free to use them, I hereby place them in the public domain. > > I was pointed in their direction by Mike Malone, after having looked > for exactly such a thing (for quite a while). He mentioned that the > reason it was chucked from the documentation is that it doesn't > reflect the changes made in the wake of the session fixation attack. I > took the old diagram, took the spec, and updated as required, with > some minor changes for legibility and aesthetics. > > Speaking as somebody who has tried (and failed) to digest OAuth by > means of the long and detailed spec, this sort of diagram is extremely > helpful in getting the "big picture" across. I'm not knocking the need > for a good spec, but a one-page overview that pulls it all together > without going into too much detail is sorely missing from the docs. > This diagram goes a long way towards meeting that need. > > Just my $0.02! Thanks for authoring this standard, hope this is useful! > > -Idan > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From dan.winship@gmail.com Fri Dec 4 06:39:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A243A68CC for ; Fri, 4 Dec 2009 06:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-2.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxdzMR4zhwCM for ; Fri, 4 Dec 2009 06:39:27 -0800 (PST) Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id C27593A659B for ; Fri, 4 Dec 2009 06:39:27 -0800 (PST) Received: from x61.home.mysterion.org (c-76-111-61-212.hsd1.ga.comcast.net [76.111.61.212]) by mysterion.org (Postfix) with ESMTPA id 00659802AE; Fri, 4 Dec 2009 09:39:18 -0500 (EST) Message-ID: <4B191F22.2050809@gmail.com> Date: Fri, 04 Dec 2009 09:39:30 -0500 From: Dan Winship User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234378529353C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529353C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Challenge/Response complexity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 14:39:28 -0000 On 12/04/2009 02:34 AM, Eran Hammer-Lahav wrote: > The authentication framework defined in 2616 and 2617 allows for very > complicated combinations of challenges and responses. For example, > servers can provide multiple challenges in separate headers and in > a single header, and clients can respond with a multiple credentials > in one request. It's not quite that bad; the server can send multiple challenges, but the client can only respond to one of them at a time. (The "Authorization" header is not multi-valued like "WWW-Authenticate" is.) It's expected that the client will pick the best/strongest WWW-Authenticate option that it knows how to deal with, and then try to authenticate using that, ignoring the other WWW-Authenticate headers (or possibly, if the first attempt fails, it might fall back to using its second choice, etc). -- Dan From eran@hueniverse.com Fri Dec 4 08:38:58 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA923A6A2C for ; Fri, 4 Dec 2009 08:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHowbTd7F7vA for ; Fri, 4 Dec 2009 08:38:57 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 27B6B3A680D for ; Fri, 4 Dec 2009 08:38:57 -0800 (PST) Received: (qmail 31068 invoked from network); 4 Dec 2009 16:38:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 16:38:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 4 Dec 2009 09:37:53 -0700 From: Eran Hammer-Lahav To: Dan Winship Date: Fri, 4 Dec 2009 09:38:11 -0700 Thread-Topic: [OAUTH-WG] Challenge/Response complexity Thread-Index: Acp075DHy6cH+t8TSVGbRf01BRpa0wAED3zA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852935EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529353C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B191F22.2050809@gmail.com> In-Reply-To: <4B191F22.2050809@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Challenge/Response complexity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 16:38:58 -0000 For those not following the HTTBbis WG, Dan also pointed this section out: Multiple header fields with the same field name MUST NOT be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)]. Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message. This basically prevents us from profiling the header to only permit a singl= e challenge. We can limit a single challenge for the entire response, but t= hat would defeat the purpose of providing clients with multiple options and= will break existing sites. EHL > -----Original Message----- > From: Dan Winship [mailto:dan.winship@gmail.com] > Sent: Friday, December 04, 2009 6:40 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Challenge/Response complexity >=20 > On 12/04/2009 02:34 AM, Eran Hammer-Lahav wrote: > > The authentication framework defined in 2616 and 2617 allows for very > > complicated combinations of challenges and responses. For example, > > servers can provide multiple challenges in separate headers and in a > > single header, and clients can respond with a multiple credentials in > > one request. >=20 > It's not quite that bad; the server can send multiple challenges, but the= client > can only respond to one of them at a time. (The "Authorization" header is > not multi-valued like "WWW-Authenticate" is.) It's expected that the clie= nt > will pick the best/strongest WWW-Authenticate option that it knows how to > deal with, and then try to authenticate using that, ignoring the other WW= W- > Authenticate headers (or possibly, if the first attempt fails, it might f= all back > to using its second choice, etc). >=20 > -- Dan From julian.reschke@gmx.de Fri Dec 4 08:21:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1613A67A8 for ; Fri, 4 Dec 2009 08:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.678 X-Spam-Level: X-Spam-Status: No, score=-4.678 tagged_above=-999 required=5 tests=[AWL=-2.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y64sYapNFAn6 for ; Fri, 4 Dec 2009 08:21:54 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id ABC2F3A684A for ; Fri, 4 Dec 2009 08:21:53 -0800 (PST) Received: (qmail invoked by alias); 04 Dec 2009 16:21:42 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 04 Dec 2009 17:21:42 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18KCpEYbUIKKi3Ke/LZ1P1JZj6ttkEuzFxw0MCMhx 87N5HRj+bJxcgM Message-ID: <4B19370F.5050506@gmx.de> Date: Fri, 04 Dec 2009 17:21:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234378529351F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529351F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 X-Mailman-Approved-At: Fri, 04 Dec 2009 08:59:30 -0800 Cc: "OAuth WG \(oauth@ietf.org\)" , "HTTP Working Group \(ietf-http-wg@w3.org\)" Subject: Re: [OAUTH-WG] RFC2616 vs draft-ietf-httpbis-p7-auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 16:21:56 -0000 Eran Hammer-Lahav wrote: > The OAuth working group is working to define a new HTTP authentication scheme. This requires referencing either RFC 2617 or draft-ietf-httpbis-p7-auth. The goal is to move the spec into last call in 3-6 months. > > Which ABNF and reference should the new work use? It's very hard to predict how long we'll need to go to LC. So a good strategy might be to leave things the way they are now, and to get back to this question once you're preparing WGLC. Best regards, Julian From stpeter@stpeter.im Fri Dec 4 09:17:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8575428C12C for ; Fri, 4 Dec 2009 09:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZgENqxq45-f for ; Fri, 4 Dec 2009 09:17:27 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6A2A13A682B for ; Fri, 4 Dec 2009 09:17:27 -0800 (PST) Received: from dhcp-64-101-72-196.cisco.com (dhcp-64-101-72-196.cisco.com [64.101.72.196]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 631D340337; Fri, 4 Dec 2009 10:17:17 -0700 (MST) Message-ID: <4B19441D.30907@stpeter.im> Date: Fri, 04 Dec 2009 10:17:17 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Julian Reschke References: <90C41DD21FB7C64BB94121FBBC2E7234378529351F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B19370F.5050506@gmx.de> In-Reply-To: <4B19370F.5050506@gmx.de> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060503000601090202030800" Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] RFC2616 vs draft-ietf-httpbis-p7-auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:17:28 -0000 This is a cryptographically signed message in MIME format. --------------ms060503000601090202030800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/4/09 9:21 AM, Julian Reschke wrote: > Eran Hammer-Lahav wrote: >> The OAuth working group is working to define a new HTTP authentication >> scheme. This requires referencing either RFC 2617 or >> draft-ietf-httpbis-p7-auth. The goal is to move the spec into last >> call in 3-6 months. >> >> Which ABNF and reference should the new work use? > > It's very hard to predict how long we'll need to go to LC. So a good > strategy might be to leave things the way they are now, and to get back > to this question once you're preparing WGLC. Agreed. We'll burn that bridge when we come to it. For now, I'd say use RFC 2617 since it's a stable reference. Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms060503000601090202030800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIwNDE3MTcxN1owIwYJKoZIhvcNAQkEMRYEFDB+J9CKw3r05Etwv4s+ vvB173qZMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEABP7OZ1Jjf3G/ehh5/UI7m+P0UXpoTN0weZo0XA8h nlM5vrZBDuVMTqYnPCGk/Dspc+Gtl1htBOQMsD1Co9M/9LbEwvbEAGRqLjGZUc9dBMQlIleX 2eBHXtIkmK3Zo6Ja/WoM/cf61K+sUWidyD3T0WuLjLFAsIhshF1SmvsO9wymVIjkIukKiGgT KpzIrUgIYl/DPJD5LrXQ+xvgNeE3n2b1t6danvgiVZTH0A3jvxDUvMYousMOKAe3bOOITr24 EqDB1z16IIE72bs9PIG9UaTFUVUAfKj4gmnpWIegQxov1KzsYBpT4W+U16leSJ9rt7hF++p6 7CKN4a5T6yrMiAAAAAAAAA== --------------ms060503000601090202030800-- From eran@hueniverse.com Fri Dec 4 09:25:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED8F28C0E7 for ; Fri, 4 Dec 2009 09:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxHHWCcreqVK for ; Fri, 4 Dec 2009 09:25:34 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DBA873A6937 for ; Fri, 4 Dec 2009 09:25:33 -0800 (PST) Received: (qmail 16269 invoked from network); 4 Dec 2009 17:25:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 17:25:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 10:25:21 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , Julian Reschke Date: Fri, 4 Dec 2009 10:25:38 -0700 Thread-Topic: [OAUTH-WG] RFC2616 vs draft-ietf-httpbis-p7-auth Thread-Index: Acp1BaP7RMSLUFHsT96AJOi64yg6wQAAOn0w Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293639@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529351F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B19370F.5050506@gmx.de> <4B19441D.30907@stpeter.im> In-Reply-To: <4B19441D.30907@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] RFC2616 vs draft-ietf-httpbis-p7-auth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:25:35 -0000 SSdtIGdvaW5nIHRvIG5lZWQgT1dTIGFuZCBSV1Mgc28gSSBhbSBnb2luZyB0byB1c2UgYm90aCBp biB0aGUgZmlyc3QgZHJhZnQgYW5kIGNsZWFuIGl0IHVwIGFzIHdlIG1vdmUgYWxvbmcuIENlcnRh aW4gY2hvaWNlcyBtaWdodCByZXF1aXJlIHVwZGF0aW5nIDI2MTcgd2hpY2ggd2UgYXJlIG5vdCBj aGFydGVyZWQgKG9yIHdhbnQpIHRvIGRvLg0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBQZXRlciBTYWludC1BbmRyZSBbbWFpbHRvOnN0cGV0ZXJAc3RwZXRl ci5pbV0NCj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNCwgMjAwOSA5OjE3IEFNDQo+IFRvOiBK dWxpYW4gUmVzY2hrZQ0KPiBDYzogRXJhbiBIYW1tZXItTGFoYXY7IE9BdXRoIFdHIChvYXV0aEBp ZXRmLm9yZykNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUkZDMjYxNiB2cyBkcmFmdC1pZXRm LWh0dHBiaXMtcDctYXV0aA0KPiANCj4gPGhhdCB0eXBlPSdjaGFpcicvPg0KPiANCj4gT24gMTIv NC8wOSA5OjIxIEFNLCBKdWxpYW4gUmVzY2hrZSB3cm90ZToNCj4gPiBFcmFuIEhhbW1lci1MYWhh diB3cm90ZToNCj4gPj4gVGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgaXMgd29ya2luZyB0byBkZWZp bmUgYSBuZXcgSFRUUCBhdXRoZW50aWNhdGlvbg0KPiA+PiBzY2hlbWUuIFRoaXMgcmVxdWlyZXMg cmVmZXJlbmNpbmcgZWl0aGVyIFJGQyAyNjE3IG9yDQo+ID4+IGRyYWZ0LWlldGYtaHR0cGJpcy1w Ny1hdXRoLiBUaGUgZ29hbCBpcyB0byBtb3ZlIHRoZSBzcGVjIGludG8gbGFzdA0KPiA+PiBjYWxs IGluIDMtNiBtb250aHMuDQo+ID4+DQo+ID4+IFdoaWNoIEFCTkYgYW5kIHJlZmVyZW5jZSBzaG91 bGQgdGhlIG5ldyB3b3JrIHVzZT8NCj4gPg0KPiA+IEl0J3MgdmVyeSBoYXJkIHRvIHByZWRpY3Qg aG93IGxvbmcgd2UnbGwgbmVlZCB0byBnbyB0byBMQy4gU28gYSBnb29kDQo+ID4gc3RyYXRlZ3kg bWlnaHQgYmUgdG8gbGVhdmUgdGhpbmdzIHRoZSB3YXkgdGhleSBhcmUgbm93LCBhbmQgdG8gZ2V0 IGJhY2sNCj4gPiB0byB0aGlzIHF1ZXN0aW9uIG9uY2UgeW91J3JlIHByZXBhcmluZyBXR0xDLg0K PiANCj4gQWdyZWVkLiBXZSdsbCBidXJuIHRoYXQgYnJpZGdlIHdoZW4gd2UgY29tZSB0byBpdC4g Rm9yIG5vdywgSSdkIHNheSB1c2UNCj4gUkZDIDI2MTcgc2luY2UgaXQncyBhIHN0YWJsZSByZWZl cmVuY2UuDQo+IA0KPiBQZXRlcg0KPiANCj4gLS0NCj4gUGV0ZXIgU2FpbnQtQW5kcmUNCj4gaHR0 cHM6Ly9zdHBldGVyLmltLw0KPiANCg0K From beaton@google.com Fri Dec 4 09:35:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924B43A682B for ; Fri, 4 Dec 2009 09:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoUc5NvYn5e6 for ; Fri, 4 Dec 2009 09:35:58 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 905693A676A for ; Fri, 4 Dec 2009 09:35:54 -0800 (PST) Received: from zps19.corp.google.com (zps19.corp.google.com [172.25.146.19]) by smtp-out.google.com with ESMTP id nB4HZiK1015935 for ; Fri, 4 Dec 2009 17:35:44 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259948145; bh=0DNdwloZeTIMhR/jEN8y2Mk/ZOY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YiGQAt9aAvsqomwMXqtrg8n9lpzTga44bJDVsfAuATH4nomdQ+ddFHC4yywfO6eTx nNrhtQE6ud6aebdsW/ESg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=oXaWbwrE14lwUoVqXGixRGO2R7qHu6tyYsMfx4J3Dm8VME7/OKQ3GsyWiy2m2a+sP X5Y/6oWQs1RwvFRPIVvAw== Received: from pwj13 (pwj13.prod.google.com [10.241.219.77]) by zps19.corp.google.com with ESMTP id nB4HZO1N024019 for ; Fri, 4 Dec 2009 09:35:41 -0800 Received: by pwj13 with SMTP id 13so859323pwj.19 for ; Fri, 04 Dec 2009 09:35:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.45.17 with SMTP id x17mr216249rvj.62.1259948141439; Fri, 04 Dec 2009 09:35:41 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852935EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529353C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B191F22.2050809@gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437852935EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 09:35:41 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Challenge/Response complexity X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 17:35:59 -0000 On Fri, Dec 4, 2009 at 8:38 AM, Eran Hammer-Lahav wrote: > This basically prevents us from profiling the header to only permit a single challenge. We can limit a single challenge for the entire response, but that would defeat the purpose of providing clients with multiple options and will break existing sites. Agreed. It's not uncommon to see things like: WWW-Authenticate: Negotiate WWW-Authenticate: Basic ... for example. Cheers, Brian From eran@hueniverse.com Fri Dec 4 10:07:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC953A672E for ; Fri, 4 Dec 2009 10:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouducWxFvIKj for ; Fri, 4 Dec 2009 10:07:17 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B25A73A67AC for ; Fri, 4 Dec 2009 10:07:17 -0800 (PST) Received: (qmail 10880 invoked from network); 4 Dec 2009 18:07:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 18:07:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 11:07:07 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , Stephen Farrell Date: Fri, 4 Dec 2009 11:07:25 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acpt7pSuYnX/bLa8QDafocxOnS4STwACWuuwACb5iVABnipBcA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:07:18 -0000 SXMgdGhlcmUgYWN0dWFsIGRlbWFuZCB0byBtYWtlIHRoZSBITUFDIG1ldGhvZCBtb3JlIGdlbmVy aWMgdG8gYWxsb3cgb3RoZXIga2luZHMgb2YgTUFDPw0KDQpFSEwNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpKYW1lcy5ILk1h bmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjYsIDIw MDkgNzo0MyBQTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXY7IFN0ZXBoZW4gRmFycmVsbA0KPiBD YzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBSRTogW09BVVRILVdHXSBT aWduYXR1cmUgY3J5cHRvDQo+IA0KPiA+PiBTb3VuZHMgcmVhc29uYWJsZSBpZiBhbGwgeW91IG5l ZWQgdG8gbmVnb3RpYXRlIGFyZSBoYXNoIGFsZ29yaXRobSBuYW1lcy4NCj4gPj4gSXMgdGhhdCB0 aGUgY2FzZT8NCj4gDQo+ID4gWWVzLg0KPiANCj4gTm90IHF1aXRlLg0KPiBPQXV0aCAoYXQgbGVh c3QgdGhlIGF1dGhlbnRpY2F0aW9uIHBhcnQpIG1haW5seSBuZWVkcyBhIE1BQyBhbGdvcml0aG0s IG5vdCBhDQo+IGhhc2ggYWxnb3JpdGhtLg0KPiBITUFDIGlzIG9uZSBwb3B1bGFyIE1BQyBhbGdv cml0aG0gdGhhdCBpcyBidWlsZCBmcm9tIGEgaGFzaCBhbGdvcml0aG0uDQo+IEhvd2V2ZXIsIHRo ZXJlIGFyZSBvdGhlciBNQUMgYWxnb3JpdGhtcyDigJQgYmFzZWQgb24gYmxvY2sgY2lwaGVycyBm b3INCj4gaW5zdGFuY2UgKGVnIENNQUMtQUVTKS4NCj4gVGhlIGhhc2ggcmVnaXN0cnkgaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9oYXNoLWZ1bmN0aW9uLXRleHQtDQo+IG5hbWVzLyBp cyBub3QgcmVhbGx5IGdvaW5nIHRvIGhlbHAuDQo+IA0KPiBQLlMuIFRoZSBib2R5LXNpZ25pbmcg T0F1dGggZXh0ZW5zaW9uIGlzIHRoZSBvbmUgcGxhY2UgdGhhdCB1c2VzIGEgaGFzaCAobm90DQo+ IGEgTUFDKSBkaXJlY3RseS4NCj4gDQo+IEphbWVzIE1hbmdlcg0K From breno.demedeiros@gmail.com Fri Dec 4 10:17:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19FD328C0EF for ; Fri, 4 Dec 2009 10:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zlGJBnUkqm4 for ; Fri, 4 Dec 2009 10:17:12 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id F3D8128C0E9 for ; Fri, 4 Dec 2009 10:17:11 -0800 (PST) Received: by yxe30 with SMTP id 30so2674149yxe.29 for ; Fri, 04 Dec 2009 10:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9j7P5PABD+z6obpboODaEpYJM8W9IVSWV5OxHOtoyyY=; b=j5h/cl0a4Ujzdz4+1tygFSEdJRz/iP+m0/GAN4JJoPojUZ2mf46GA8vfVkNalFil4Z ObY4ekipEwkOobEGLC1zgdjUpudJ5DjBX/XBo+owv6NX5lJUzDffPb4Y0xef99m6RGo5 loTJeIo31crmsJlUnX4m6qxPqDa/bXpmMpiRY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xsFTrih0xPcHX4a4xvMh3wF4i9xiwYKhq92E2C+TZmwGlyjU5UUR8vyI4OFtgc06RP LB+P85b6HXoco2i6FCmLjLoBM786dQ1q87d3+pQvRkdunV3Vd8r08grNkYfEPI/ZdLES 4acO8AVGD2C3cN37AOmHumjUNvibU0/GU4Ci0= MIME-Version: 1.0 Received: by 10.101.7.28 with SMTP id k28mr4423039ani.49.1259950611560; Fri, 04 Dec 2009 10:16:51 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 10:16:51 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636c92cc8a2f8900479eb1c34 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:17:13 -0000 --001636c92cc8a2f8900479eb1c34 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable While there are technical merits, both from security and performance standpoints, to the alternative MAC proposals, there is not extensive library support for those, and AFAIK they have little usage in the Internet= . I am not sure if it makes sense for OAuth to be on the leading edge in term= s of MAC algorithm adoption. On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav wro= te: > Is there actual demand to make the HMAC method more generic to allow othe= r > kinds of MAC? > > EHL > > > -----Original Message----- > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Sent: Thursday, November 26, 2009 7:43 PM > > To: Eran Hammer-Lahav; Stephen Farrell > > Cc: OAuth WG (oauth@ietf.org) > > Subject: RE: [OAUTH-WG] Signature crypto > > > > >> Sounds reasonable if all you need to negotiate are hash algorithm > names. > > >> Is that the case? > > > > > Yes. > > > > Not quite. > > OAuth (at least the authentication part) mainly needs a MAC algorithm, > not a > > hash algorithm. > > HMAC is one popular MAC algorithm that is build from a hash algorithm. > > However, there are other MAC algorithms =97 based on block ciphers for > > instance (eg CMAC-AES). > > The hash registry http://www.iana.org/assignments/hash-function-text- > > names/ is not really going to help. > > > > P.S. The body-signing OAuth extension is the one place that uses a hash > (not > > a MAC) directly. > > > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Breno de Medeiros --001636c92cc8a2f8900479eb1c34 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable While there are technical merits, both from security and performance standp= oints, to the alternative MAC proposals, there is not extensive library sup= port for those, and AFAIK they have little usage in the Internet. I am not = sure if it makes sense for OAuth to be on the leading edge in terms of MAC = algorithm adoption.

On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer= -Lahav <eran@hu= eniverse.com> wrote:
Is there actual demand to make the HMAC method more generic to allow other = kinds of MAC?

EHL

> -----Original Message-----
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> Sent: Thursday, November 26, 2009 7:43 PM
> To: Eran Hammer-Lahav; Stephen Farrell
> Cc: OAuth WG (oauth@ietf.org)
> Subject: RE: [OAUTH-WG] Signat= ure crypto
>
> >> Sounds reasonable if all you need to negotiate are hash algor= ithm names.
> >> Is that the case?
>
> > Yes.
>
> Not quite.
> OAuth (at least the authentication part) mainly needs a MAC algorithm,= not a
> hash algorithm.
> HMAC is one popular MAC algorithm that is build from a hash algorithm.=
> However, there are other MAC algorithms =97 based on block ciphers for=
> instance (eg CMAC-AES).
> The hash registry http://www.iana.org/assignments/hash-function= -text-
> names/ is not really going to help.
>
> P.S. The body-signing OAuth extension is the one place that uses a has= h (not
> a MAC) directly.
>
> James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Breno de Me= deiros

--001636c92cc8a2f8900479eb1c34-- From eran@hueniverse.com Fri Dec 4 10:21:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5EF3A6936 for ; Fri, 4 Dec 2009 10:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yYq51oN3uf9 for ; Fri, 4 Dec 2009 10:21:41 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EA6F63A676A for ; Fri, 4 Dec 2009 10:21:40 -0800 (PST) Received: (qmail 13270 invoked from network); 4 Dec 2009 18:21:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 18:21:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 4 Dec 2009 11:21:29 -0700 From: Eran Hammer-Lahav To: Breno Date: Fri, 4 Dec 2009 11:21:47 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1DfoKVFZn651CTY+nRdcS2P72vgAAFpJw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785293683P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:21:46 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785293683P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was not suggesting to explicitly mention them, just allow them. Currently, I am proposing a HMAC option with the hash algorithm as a parame= ter. This would mean changing it to a MAC option with the MAC type and hash= algorithm as parameters. It adds a bit more complexity but nothing significant. However, if there ar= e no compelling reasons to do so (no actual use cases or requirements), I a= m more inclined to stick with HMAC and allow others to extend it by adding = a new CMAC (etc.) method. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 10:17 AM To: Eran Hammer-Lahav Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto While there are technical merits, both from security and performance standp= oints, to the alternative MAC proposals, there is not extensive library sup= port for those, and AFAIK they have little usage in the Internet. I am not = sure if it makes sense for OAuth to be on the leading edge in terms of MAC = algorithm adoption. On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > wrote: Is there actual demand to make the HMAC method more generic to allow other = kinds of MAC? EHL > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Thursday, November 26, 2009 7:43 PM > To: Eran Hammer-Lahav; Stephen Farrell > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Signature crypto > > >> Sounds reasonable if all you need to negotiate are hash algorithm name= s. > >> Is that the case? > > > Yes. > > Not quite. > OAuth (at least the authentication part) mainly needs a MAC algorithm, no= t a > hash algorithm. > HMAC is one popular MAC algorithm that is build from a hash algorithm. > However, there are other MAC algorithms - based on block ciphers for > instance (eg CMAC-AES). > The hash registry http://www.iana.org/assignments/hash-function-text- > names/ is not really going to help. > > P.S. The body-signing OAuth extension is the one place that uses a hash (= not > a MAC) directly. > > James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E72343785293683P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was not= suggesting to explicitly mention them, just allow them.<= /p>

 

Currently, I am proposing a HMAC option with the hash algorithm= as a parameter. This would mean changing it to a MAC option with the MAC t= ype and hash algorithm as parameters.

 

It adds= a bit more complexity but nothing significant. However, if there are no co= mpelling reasons to do so (no actual use cases or requirements), I am more = inclined to stick with HMAC and allow others to extend it by adding a new C= MAC (etc.) method.

&n= bsp;

EHL

<= p class=3DMsoNormal> 

From: Breno [mailto:breno.demedeiros@gmail.com]
= Sent: Friday, December 04, 2009 10:17 AM
To: Eran Hammer-Laha= v
Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)=
Subject: Re: [OAUTH-WG] Signature crypto

 

While there are technical merits, both from se= curity and performance standpoints, to the alternative MAC proposals, there= is not extensive library support for those, and AFAIK they have little usa= ge in the Internet. I am not sure if it makes sense for OAuth to be on the = leading edge in terms of MAC algorithm adoption.

On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Is there actual demand to make the HMAC method = more generic to allow other kinds of MAC?
=
EHL


> -----Origin= al Message-----
> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> = Sent: Thursday, November 26, 2009 7:43 PM
> To: Eran Hammer-Lahav; St= ephen Farrell
> Cc: OAuth WG (oauth= @ietf.org)

> Subj= ect: RE: [OAUTH-WG] Signature crypto
>
> >> Sounds reason= able if all you need to negotiate are hash algorithm names.
> >>= ; Is that the case?
>
> > Yes.
>
> Not quite.> OAuth (at least the authentication part) mainly needs a MAC algorithm= , not a
> hash algorithm.
> HMAC is one popular MAC algorithm t= hat is build from a hash algorithm.
> However, there are other MAC al= gorithms — based on block ciphers for
> instance (eg CMAC-AES).=
> The hash registry http://www.iana.org/assignments/hash-func= tion-text-
> names/ is not really going to help.
>
> = P.S. The body-signing OAuth extension is the one place that uses a hash (no= t
> a MAC) directly.
>
> James Manger
________________= _______________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/= oauth




--
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785293683P3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Fri Dec 4 10:23:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADBB028C0E8 for ; Fri, 4 Dec 2009 10:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2hr7VBWFzqN for ; Fri, 4 Dec 2009 10:23:37 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 618833A672E for ; Fri, 4 Dec 2009 10:23:37 -0800 (PST) Received: by yxe30 with SMTP id 30so2680488yxe.29 for ; Fri, 04 Dec 2009 10:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bUK7OtQ5R1fvJ/cJ5U/zEzokR/7ghySBJPftBpxP+WU=; b=FR0lxcaDt1a3NfWiICRw2XyZphgCO7BHFrS2+m3wegEI0HMlrywGXLK9GYmEIfS9gr 5ljYqFfuc7BJRSJv8oAhLGCQ6PYhqCbw1qFZ9P2PI1sBWenPzZlLdAXKSV877IRY0fz2 orinofU8aOSVfTe53T9GAs1+sSPYLZ8XHRHCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NQ5/ZMDfyEs4HXw/xCGoB9qbuzprz8gX1I3dpyKxtxQKiuSX69SoSSwguwnibZeCca 1ftaROA+SQl0rOiYz+r7BXX/US66CA5G9cPL1JuPfTwmMRx36kpzjiCAZntdGkYsNaIR C3v39VV1SycLXT0Pq8fjWySzK9t3+19SPiRmY= MIME-Version: 1.0 Received: by 10.101.29.9 with SMTP id g9mr4404060anj.123.1259951005269; Fri, 04 Dec 2009 10:23:25 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 10:23:25 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636b2b0cd1a81390479eb345a Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:23:38 -0000 --001636b2b0cd1a81390479eb345a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable There is no reason to make HMAC + hash a separate thing. It would make sense to define a way to specify a MAC, and to specify HMAC with SHA-1 you need only say HMAC-SHA1 as the algorithm name. This is pretty conventional. On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav wro= te: > I was not suggesting to explicitly mention them, just allow them. > > > > Currently, I am proposing a HMAC option with the hash algorithm as a > parameter. This would mean changing it to a MAC option with the MAC type = and > hash algorithm as parameters. > > > > It adds a bit more complexity but nothing significant. However, if there > are no compelling reasons to do so (no actual use cases or requirements),= I > am more inclined to stick with HMAC and allow others to extend it by addi= ng > a new CMAC (etc.) method. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Friday, December 04, 2009 10:17 AM > *To:* Eran Hammer-Lahav > *Cc:* Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] Signature crypto > > > > While there are technical merits, both from security and performance > standpoints, to the alternative MAC proposals, there is not extensive > library support for those, and AFAIK they have little usage in the Intern= et. > I am not sure if it makes sense for OAuth to be on the leading edge in te= rms > of MAC algorithm adoption. > > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > wrote: > > Is there actual demand to make the HMAC method more generic to allow othe= r > kinds of MAC? > > EHL > > > > -----Original Message----- > > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > Sent: Thursday, November 26, 2009 7:43 PM > > To: Eran Hammer-Lahav; Stephen Farrell > > Cc: OAuth WG (oauth@ietf.org) > > > Subject: RE: [OAUTH-WG] Signature crypto > > > > >> Sounds reasonable if all you need to negotiate are hash algorithm > names. > > >> Is that the case? > > > > > Yes. > > > > Not quite. > > OAuth (at least the authentication part) mainly needs a MAC algorithm, > not a > > hash algorithm. > > HMAC is one popular MAC algorithm that is build from a hash algorithm. > > However, there are other MAC algorithms =97 based on block ciphers for > > instance (eg CMAC-AES). > > The hash registry http://www.iana.org/assignments/hash-function-text- > > names/ is not really going to help. > > > > P.S. The body-signing OAuth extension is the one place that uses a hash > (not > > a MAC) directly. > > > > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Breno de Medeiros > --=20 Breno de Medeiros --001636b2b0cd1a81390479eb345a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable There is no reason to make HMAC + hash a separate thing.

It would make sense to define a way to specify a MAC, and to specify HMAC = with SHA-1 you need only say HMAC-SHA1 as the algorithm name.

This is pretty conventional.

On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> = wrote:

I was not suggesting to explicitly mention them, just allow them.

=A0

Currently, I am proposing a HMAC option with the hash algorithm as a pa= rameter. This would mean changing it to a MAC option with the MAC type and = hash algorithm as parameters.

=A0

It adds a bit more complexity but nothing significant. However, if ther= e are no compelling reasons to do so (no actual use cases or requirements),= I am more inclined to stick with HMAC and allow others to extend it by add= ing a new CMAC (etc.) method.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]
Sent: Friday, December 04, 2009 10:17 AM
To: Eran Hammer-L= ahav
Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)


Subject: Re: [OAUTH-WG] Signature crypto

=A0

While there are technical merits, both from security and performa= nce standpoints, to the alternative MAC proposals, there is not extensive l= ibrary support for those, and AFAIK they have little usage in the Internet.= I am not sure if it makes sense for OAuth to be on the leading edge in ter= ms of MAC algorithm adoption.

On Fri, Dec 4= , 2009 at 10:07 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Is there actual demand to make the HMAC method more generic to allow other = kinds of MAC?

EHL


> -----Original Message-----
> From: Manger,= James H [mailto:James.H.Manger@team.telstra.com]
> Sent: Thursday, November 26, 2009 7:43 PM
> To: Eran Hammer-Laha= v; Stephen Farrell
> Cc: OAuth WG (oauth@ietf.org)

> Subject: RE: [OAUTH-WG] Signature crypto
>
> >> Soun= ds reasonable if all you need to negotiate are hash algorithm names.
>= ; >> Is that the case?
>
> > Yes.
>
> Not = quite.
> OAuth (at least the authentication part) mainly needs a MAC algorithm,= not a
> hash algorithm.
> HMAC is one popular MAC algorithm th= at is build from a hash algorithm.
> However, there are other MAC alg= orithms =97 based on block ciphers for
> instance (eg CMAC-AES).
> The hash registry http://www.ia= na.org/assignments/hash-function-text-
> names/ is not really goi= ng to help.
>
> P.S. The body-signing OAuth extension is the one place that us= es a hash (not
> a MAC) directly.
>
> James Manger
___= ____________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--=
Breno de Medeiros




= --
Breno de Medeiros

--001636b2b0cd1a81390479eb345a-- From eran@hueniverse.com Fri Dec 4 10:28:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94CF3A693B for ; Fri, 4 Dec 2009 10:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.982 X-Spam-Level: X-Spam-Status: No, score=-2.982 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7qoEqq0HE7M for ; Fri, 4 Dec 2009 10:28:24 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DCC5F3A67AC for ; Fri, 4 Dec 2009 10:28:23 -0800 (PST) Received: (qmail 3112 invoked from network); 4 Dec 2009 18:28:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 18:28:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 4 Dec 2009 11:28:10 -0700 From: Eran Hammer-Lahav To: Breno Date: Fri, 4 Dec 2009 11:28:27 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1Dt9zcaU6LxO5SjOwmo1b+5cBwgAAEYhw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D3698.8070706@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234378529368AP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:28:31 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234378529368AP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's not really. We are talking about: 1. HMAC-specific: The server sends: methods=3D"HMAC:sha-1,sha-256" The client replies: method=3D"HMAC:sha-256" 2. MAC-generic: The server sends: methods=3D"MAC:hmac-sha1,hmac-sha256" The client replies: method=3D"MAC:hmac-sha256" Pick! EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 10:23 AM To: Eran Hammer-Lahav Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto There is no reason to make HMAC + hash a separate thing. It would make sense to define a way to specify a MAC, and to specify HMAC w= ith SHA-1 you need only say HMAC-SHA1 as the algorithm name. This is pretty conventional. On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav > wrote: I was not suggesting to explicitly mention them, just allow them. Currently, I am proposing a HMAC option with the hash algorithm as a parame= ter. This would mean changing it to a MAC option with the MAC type and hash= algorithm as parameters. It adds a bit more complexity but nothing significant. However, if there ar= e no compelling reasons to do so (no actual use cases or requirements), I a= m more inclined to stick with HMAC and allow others to extend it by adding = a new CMAC (etc.) method. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 10:17 AM To: Eran Hammer-Lahav Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto While there are technical merits, both from security and performance standp= oints, to the alternative MAC proposals, there is not extensive library sup= port for those, and AFAIK they have little usage in the Internet. I am not = sure if it makes sense for OAuth to be on the leading edge in terms of MAC = algorithm adoption. On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > wrote: Is there actual demand to make the HMAC method more generic to allow other = kinds of MAC? EHL > -----Original Message----- > From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > Sent: Thursday, November 26, 2009 7:43 PM > To: Eran Hammer-Lahav; Stephen Farrell > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Signature crypto > > >> Sounds reasonable if all you need to negotiate are hash algorithm name= s. > >> Is that the case? > > > Yes. > > Not quite. > OAuth (at least the authentication part) mainly needs a MAC algorithm, no= t a > hash algorithm. > HMAC is one popular MAC algorithm that is build from a hash algorithm. > However, there are other MAC algorithms - based on block ciphers for > instance (eg CMAC-AES). > The hash registry http://www.iana.org/assignments/hash-function-text- > names/ is not really going to help. > > P.S. The body-signing OAuth extension is the one place that uses a hash (= not > a MAC) directly. > > James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E7234378529368AP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’= s not really.

 <= /o:p>

We are talking about:

 

1. HMAC-specific:

 

The = server sends:

 <= /o:p>

methods=3D”HMAC:sha-1,sha= -256”

 

The client replies:

 

method=3D”HMAC:sha-256”

<= p class=3DMsoNormal> 

2. MAC-generic:

 

The server sends:

 

<= p class=3DMsoNormal>methods=3D”MAC:hmac-sha1,hmac-sha256”= ;

 =

The client replies:

 

= method=3D”MAC:hmac-sha256”

 

Pick!

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Fr= iday, December 04, 2009 10:23 AM
To: Eran Hammer-Lahav
Cc:<= /b> Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
Subje= ct: Re: [OAUTH-WG] Signature crypto

 

There is no re= ason to make HMAC + hash a separate thing.

 

It would make = sense to define a way to specify a MAC, and to specify HMAC with SHA-1 you = need only say HMAC-SHA1 as the algorithm name.

 

This is pretty conventional.

=

On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com> wrote:<= o:p>

I was not suggesting to explicitly mention them, just allow them.=

 =

Currently, I am proposing a HMAC option with the hash algorithm as a param= eter. This would mean changing it to a MAC option with the MAC type and has= h algorithm as parameters.

 

It adds a bit more complexity but nothi= ng significant. However, if there are no compelling reasons to do so (no ac= tual use cases or requirements), I am more inclined to stick with HMAC and = allow others to extend it by adding a new CMAC (etc.) method.

 =

EHL

&n= bsp;

From: Breno [m= ailto:breno= .demedeiros@gmail.com]
Sent: Friday, December 04, 2009 10:17= AM
To: Eran Hammer-Lahav
Cc: Manger, James H; Stephen = Farrell; OAuth WG (oaut= h@ietf.org)


Subje= ct: Re: [OAUTH-WG] Signature crypto

 

While there are technical merits, both from secur= ity and performance standpoints, to the alternative MAC proposals, there is= not extensive library support for those, and AFAIK they have little usage = in the Internet. I am not sure if it makes sense for OAuth to be on the lea= ding edge in terms of MAC algorithm adoption.

=

On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te:

Is there actual demand to make the HMAC method mor= e generic to allow other kinds of MAC?
EHL


> -----Original Message-----> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
>= Sent: Thursday, November 26, 2009 7:43 PM
> To: Eran Hammer-Lahav; S= tephen Farrell
> Cc: OAuth WG (oauth@ietf.org)

>= Subject: RE: [OAUTH-WG] Signature crypto
>
> >> Sounds r= easonable if all you need to negotiate are hash algorithm names.
> &g= t;> Is that the case?
>
> > Yes.
>
> Not quit= e.
> OAuth (at least the authentication part) mainly needs a MAC algo= rithm, not a
> hash algorithm.
> HMAC is one popular MAC algori= thm that is build from a hash algorithm.
> However, there are other M= AC algorithms — based on block ciphers for
> instance (eg CMAC-= AES).
> The hash registry http://www.iana.org/assignments/hash= -function-text-
> names/ is not really going to help.
>
= > P.S. The body-signing OAuth extension is the one place that uses a has= h (not
> a MAC) directly.
>
> James Manger
___________= ____________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth



--
Breno de Medeiros

<= /div>



--
Breno de Medeiros

= = --_000_90C41DD21FB7C64BB94121FBBC2E7234378529368AP3PW5EX1MB01E_-- From breno.demedeiros@gmail.com Fri Dec 4 10:30:09 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E048A28C108 for ; Fri, 4 Dec 2009 10:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWDND2NfWXB3 for ; Fri, 4 Dec 2009 10:30:06 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 71D943A672E for ; Fri, 4 Dec 2009 10:30:06 -0800 (PST) Received: by yxe30 with SMTP id 30so2686832yxe.29 for ; Fri, 04 Dec 2009 10:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9jQD+eU2E7MPLBfksHkcRLU/G1E7cQ50AVn5gcqcOzE=; b=l2iCiCgkisvCY/UPDzNP6UedHas0cV2H140dpcCCevuESPTRj7ZXbnpbQRLJIFo8Cv dUNAJAkQZzrEdgI9qErgmmiVou0PKARQhKh3zkwalileeEfbHvmC8zEaQ5TIVO3xMpyy fajioIx1xC3LTxQoyYKfmGvRii3LvkfhzYblA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ky14Gldn8tnBfunchUJZre14epPEYB+n+6Z60gKZVxgYb+aTLkZZhiaRo+VkjaZM1V isNK2Obreu3DZCSOKYwPEGWU8jBp6/cdjdcxco0HsZoeY9LectOIHIp6SvZuIQa+xVEU dA/H1zq1woQg1cFMU5Lly+r0kYyrJhoBe9hVg= MIME-Version: 1.0 Received: by 10.101.182.20 with SMTP id j20mr4417091anp.65.1259951393027; Fri, 04 Dec 2009 10:29:53 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 10:29:52 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636c928df3738b40479eb4b80 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:30:09 -0000 --001636c928df3738b40479eb4b80 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > > methods=3D=94HMAC:sha-1,sha-256=94 > > > > The client replies: > > > > method=3D=94HMAC:sha-256=94 > > > > 2. MAC-generic: > > > > The server sends: > > > > methods=3D=94MAC:hmac-sha1,hmac-sha256=94 > > > I pick the second. It's the right level of abstraction and actually slightl= y easier to implement. --001636c928df3738b40479eb4b80 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

=A0

metho= ds=3D=94HMAC:sha-1,sha-256=94

=A0

The client replies:

=A0

method=3D=94HMAC:sha-256=94

=A0

2. MA= C-generic:

=A0

The server sends:

=A0

methods=3D=94MAC:hmac-sha1,hmac-sha256=94

=A0


I pick the second. It's th= e right level of abstraction and actually slightly easier to implement.=A0<= /div>
--001636c928df3738b40479eb4b80-- From eran@hueniverse.com Fri Dec 4 10:34:24 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921B93A682B for ; Fri, 4 Dec 2009 10:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.678 X-Spam-Level: X-Spam-Status: No, score=-2.678 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKvgbnn20Fgn for ; Fri, 4 Dec 2009 10:34:21 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C0DE93A67EF for ; Fri, 4 Dec 2009 10:34:21 -0800 (PST) Received: (qmail 10289 invoked from network); 4 Dec 2009 18:34:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 18:34:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 4 Dec 2009 11:34:11 -0700 From: Eran Hammer-Lahav To: Breno Date: Fri, 4 Dec 2009 11:34:28 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1D8iJYG9qFQ/XSJ2dq0T6I7MYFQAAGdLQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529368E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234378529368EP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:34:24 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E7234378529368EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do all MAC functions work like this: digest =3D mac(key, text) It would be hard to generalize a signature method if not. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 10:30 AM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto methods=3D"HMAC:sha-1,sha-256" The client replies: method=3D"HMAC:sha-256" 2. MAC-generic: The server sends: methods=3D"MAC:hmac-sha1,hmac-sha256" I pick the second. It's the right level of abstraction and actually slightl= y easier to implement. --_000_90C41DD21FB7C64BB94121FBBC2E7234378529368EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Do all MA= C functions work like this:

 

digest =3D mac(ke= y, text)

 =

It would be hard to generalize a sig= nature method if not.

 

EHL

 

From: Breno [mailto:breno.demedeiros@gmail.com]
= Sent: Friday, December 04, 2009 10:30 AM
To: Eran Hammer-L= ahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-= WG] Signature crypto

=  

 

 

methods=3D”HMAC:sha-1,sha-= 256”

 

The client replies:

 

<= span style=3D'font-size:11.0pt;color:#1F497D'>method=3D”HMAC:sha-256&= #8221;

 

2. MAC-generic:

 

The server sends:

 

methods=3D= 221;MAC:hmac-sha1,hmac-sha256”

 

 

I pick the second. It's the right level of abstraction a= nd actually slightly easier to implement. 

<= /div>
= --_000_90C41DD21FB7C64BB94121FBBC2E7234378529368EP3PW5EX1MB01E_-- From beaton@google.com Fri Dec 4 10:38:02 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093063A6839 for ; Fri, 4 Dec 2009 10:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF7+g-r2wdEQ for ; Fri, 4 Dec 2009 10:38:01 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 86C733A67EF for ; Fri, 4 Dec 2009 10:38:00 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id nB4Ibn3o026895 for ; Fri, 4 Dec 2009 10:37:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259951870; bh=sa88XYiXUlEL1bQ3WqgAHGuRTM0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=U9jO34BoIgi32ZHRo0shi92fibHhSeXTMyuP50MPGCL+YJNPqn2izepUgoW+4sGfi Di6NHxjYV17DmZhCh5tyg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=xSlqbwP9eCeRNDIHAKMa4dkhri1hwo+5U+SFapvYU51ePdZWJWZvlCEoYApYk4M2A ociYOP1DV03pJYVOco6yg== Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by wpaz24.hot.corp.google.com with ESMTP id nB4IbkdC003708 for ; Fri, 4 Dec 2009 10:37:46 -0800 Received: by pzk9 with SMTP id 9so2575348pzk.16 for ; Fri, 04 Dec 2009 10:37:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.106.13 with SMTP id i13mr199784rvm.0.1259951866218; Fri, 04 Dec 2009 10:37:46 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 10:37:46 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:38:02 -0000 I think OAuth 1.0 got this right. Just specify the signature algorithm. That can cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, RSA-SHA256, and whatever other fancy magic someone comes up with next year. Cheers, Brian On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav wr= ote: > It=92s not really. > > > > We are talking about: > > > > 1. HMAC-specific: > > > > The server sends: > > > > methods=3D=94HMAC:sha-1,sha-256=94 > > > > The client replies: > > > > method=3D=94HMAC:sha-256=94 > > > > 2. MAC-generic: > > > > The server sends: > > > > methods=3D=94MAC:hmac-sha1,hmac-sha256=94 > > > > The client replies: > > > > method=3D=94MAC:hmac-sha256=94 > > > > Pick! > > > > EHL > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > Sent: Friday, December 04, 2009 10:23 AM > > To: Eran Hammer-Lahav > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto > > > > There is no reason to make HMAC + hash a separate thing. > > > > It would make sense to define a way to specify a MAC, and to specify HMAC > with SHA-1 you need only say HMAC-SHA1 as the algorithm name. > > > > This is pretty conventional. > > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav > wrote: > > I was not suggesting to explicitly mention them, just allow them. > > > > Currently, I am proposing a HMAC option with the hash algorithm as a > parameter. This would mean changing it to a MAC option with the MAC type = and > hash algorithm as parameters. > > > > It adds a bit more complexity but nothing significant. However, if there = are > no compelling reasons to do so (no actual use cases or requirements), I a= m > more inclined to stick with HMAC and allow others to extend it by adding = a > new CMAC (etc.) method. > > > > EHL > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > Sent: Friday, December 04, 2009 10:17 AM > To: Eran Hammer-Lahav > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > > > While there are technical merits, both from security and performance > standpoints, to the alternative MAC proposals, there is not extensive > library support for those, and AFAIK they have little usage in the Intern= et. > I am not sure if it makes sense for OAuth to be on the leading edge in te= rms > of MAC algorithm adoption. > > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > wrote: > > Is there actual demand to make the HMAC method more generic to allow othe= r > kinds of MAC? > > EHL > >> -----Original Message----- >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] >> Sent: Thursday, November 26, 2009 7:43 PM >> To: Eran Hammer-Lahav; Stephen Farrell >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: RE: [OAUTH-WG] Signature crypto >> >> >> Sounds reasonable if all you need to negotiate are hash algorithm >> >> names. >> >> Is that the case? >> >> > Yes. >> >> Not quite. >> OAuth (at least the authentication part) mainly needs a MAC algorithm, n= ot >> a >> hash algorithm. >> HMAC is one popular MAC algorithm that is build from a hash algorithm. >> However, there are other MAC algorithms =97 based on block ciphers for >> instance (eg CMAC-AES). >> The hash registry http://www.iana.org/assignments/hash-function-text- >> names/ is not really going to help. >> >> P.S. The body-signing OAuth extension is the one place that uses a hash >> (not >> a MAC) directly. >> >> James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > -- > Breno de Medeiros > > > -- > Breno de Medeiros > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From breno.demedeiros@gmail.com Fri Dec 4 10:46:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959F03A6A1F for ; Fri, 4 Dec 2009 10:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyIK2orqGq8Q for ; Fri, 4 Dec 2009 10:46:24 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id AF3013A63EB for ; Fri, 4 Dec 2009 10:46:24 -0800 (PST) Received: by gxk28 with SMTP id 28so2454253gxk.9 for ; Fri, 04 Dec 2009 10:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ClvfAhcIzs5FbkHE9f4Xr2zlwYPicfofKvg10mVN7tg=; b=IN52JHgaNV4yfBgHk/7R20LmP5qdcailHHFiXscQ16u1VWWOVLBCegwoYL3pq5PzU5 U6yHO6prtnVIRZ+tySucTfu7/ya/geq2+RYMC+s9TRC7EDbRvNtsnTwLxt2iR7IYY288 MjjjvJEo7IsjobggttozBXdB7hcoiV6QU9/+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UJuGwSoAWftdugU7G/g68VVz/XCBeOKaJSWjY7ItvmQahxvakwZzWUC6Xodi0C0lRK RRfTttVk5vmLgjNRjZWBTxX+KGauIYswLWmx95meGXbWM5/AbfP8DaBYYdtpP3F48PfI yZfE1rSqnC9O5pQiPvELREF0JQrAkLGuEZmQ8= MIME-Version: 1.0 Received: by 10.101.182.20 with SMTP id j20mr4458549anp.65.1259952367614; Fri, 04 Dec 2009 10:46:07 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529368E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 10:46:07 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636c928df4e3ded0479eb85fc Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:46:25 -0000 --001636c928df4e3ded0479eb85fc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, they all do. On Fri, Dec 4, 2009 at 10:34 AM, Eran Hammer-Lahav wro= te: > Do all MAC functions work like this: > > > > digest =3D mac(key, text) > > > > It would be hard to generalize a signature method if not. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Friday, December 04, 2009 10:30 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] Signature crypto > > > > > > > > methods=3D=94HMAC:sha-1,sha-256=94 > > > > The client replies: > > > > method=3D=94HMAC:sha-256=94 > > > > 2. MAC-generic: > > > > The server sends: > > > > methods=3D=94MAC:hmac-sha1,hmac-sha256=94 > > > > > > I pick the second. It's the right level of abstraction and actually > slightly easier to implement. > --=20 Breno de Medeiros --001636c928df4e3ded0479eb85fc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, they all do.

On Fri, Dec 4, 2009 at = 10:34 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Do all MAC functions wor= k like this:

=A0

diges= t =3D mac(key, text)

=A0

It would be hard to generalize a signat= ure method if not.

=A0

EHL

=A0

From: Breno [mailto:breno.demedeiros@= gmail.com]
Sent: Friday, December 04, 2009 10:30 AM
To: Eran Hammer-L= ahav
Cc: OAuth WG (oauth@ietf.org)


Subject: R= e: [OAUTH-WG] Signature crypto

=A0

=A0=

=A0

methods=3D=94HMAC:s= ha-1,sha-256=94

=A0

The c= lient replies:

=A0

method=3D=94HMAC:sha-256=94

=A0

2. MAC-generic:

=A0

The s= erver sends:

=A0

methods=3D=94MAC:hmac-sha1,hmac-sha256=94=

=A0

=A0

I= pick the second. It's the right level of abstraction and actually slig= htly easier to implement.=A0




--
Breno de Medeiros

--001636c928df4e3ded0479eb85fc-- From eran@hueniverse.com Fri Dec 4 10:46:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE5C28C0F8 for ; Fri, 4 Dec 2009 10:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.972 X-Spam-Level: X-Spam-Status: No, score=-2.972 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7eGeqjgB1vt for ; Fri, 4 Dec 2009 10:46:25 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A7A093A63EB for ; Fri, 4 Dec 2009 10:46:25 -0800 (PST) Received: (qmail 24927 invoked from network); 4 Dec 2009 18:46:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 18:46:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 11:46:15 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 4 Dec 2009 11:46:32 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1EOJy93MjiBt5SyCwhdeDtBsl3AAACfqQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:46:27 -0000 We need to group them by class so that they can be applied in a consistent = way. This needs to work without having to write a spec to go from HMAC-SHA1 to H= MAC-SHA256. While it is intuitive for some, it is not for others... I can e= xtrapolate HMAC-SHA256 from the definition of HMAC-SHA1, but I have no clue= what ECC implies and how it should work based on the defined methods (mayb= e it doesn't). Right now we have three classes: HMAC, RSA, and Plain. Plain does not take any parameters. HMAC and RSA take= a hash algorithm name as parameter. If we are to generalize these to MAC (and possibly RSA to PK-something, if = we decide not to drop it), I need to be able to write a spec that can be ap= plied consistently. We have two ways to accomplish a baseline interop. One is to pick a small n= umber of algorithms like 1.0 did and leave the rest to be defined by extens= ions. The second is to pick a small number of well-defined classes of algor= ithm which can be applies in a consistent way, and either define a registry= for algorithm names or reuse one. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, December 04, 2009 10:38 AM > To: Eran Hammer-Lahav > Cc: Breno; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto >=20 > I think OAuth 1.0 got this right. Just specify the signature algorithm. = That can > cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, RSA-SHA256, and > whatever other fancy magic someone comes up with next year. >=20 > Cheers, > Brian >=20 > On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav > wrote: > > It's not really. > > > > > > > > We are talking about: > > > > > > > > 1. HMAC-specific: > > > > > > > > The server sends: > > > > > > > > methods=3D"HMAC:sha-1,sha-256" > > > > > > > > The client replies: > > > > > > > > method=3D"HMAC:sha-256" > > > > > > > > 2. MAC-generic: > > > > > > > > The server sends: > > > > > > > > methods=3D"MAC:hmac-sha1,hmac-sha256" > > > > > > > > The client replies: > > > > > > > > method=3D"MAC:hmac-sha256" > > > > > > > > Pick! > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:23 AM > > > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > There is no reason to make HMAC + hash a separate thing. > > > > > > > > It would make sense to define a way to specify a MAC, and to specify > > HMAC with SHA-1 you need only say HMAC-SHA1 as the algorithm name. > > > > > > > > This is pretty conventional. > > > > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav > > > > wrote: > > > > I was not suggesting to explicitly mention them, just allow them. > > > > > > > > Currently, I am proposing a HMAC option with the hash algorithm as a > > parameter. This would mean changing it to a MAC option with the MAC > > type and hash algorithm as parameters. > > > > > > > > It adds a bit more complexity but nothing significant. However, if > > there are no compelling reasons to do so (no actual use cases or > > requirements), I am more inclined to stick with HMAC and allow others > > to extend it by adding a new CMAC (etc.) method. > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:17 AM > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > While there are technical merits, both from security and performance > > standpoints, to the alternative MAC proposals, there is not extensive > > library support for those, and AFAIK they have little usage in the Inte= rnet. > > I am not sure if it makes sense for OAuth to be on the leading edge in > > terms of MAC algorithm adoption. > > > > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > > > > wrote: > > > > Is there actual demand to make the HMAC method more generic to allow > > other kinds of MAC? > > > > EHL > > > >> -----Original Message----- > >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > >> Sent: Thursday, November 26, 2009 7:43 PM > >> To: Eran Hammer-Lahav; Stephen Farrell > >> Cc: OAuth WG (oauth@ietf.org) > > > >> Subject: RE: [OAUTH-WG] Signature crypto > >> > >> >> Sounds reasonable if all you need to negotiate are hash algorithm > >> >> names. > >> >> Is that the case? > >> > >> > Yes. > >> > >> Not quite. > >> OAuth (at least the authentication part) mainly needs a MAC > >> algorithm, not a hash algorithm. > >> HMAC is one popular MAC algorithm that is build from a hash algorithm. > >> However, there are other MAC algorithms - based on block ciphers for > >> instance (eg CMAC-AES). > >> The hash registry http://www.iana.org/assignments/hash-function-text- > >> names/ is not really going to help. > >> > >> P.S. The body-signing OAuth extension is the one place that uses a > >> hash (not a MAC) directly. > >> > >> James Manger > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Breno de Medeiros > > > > > > -- > > Breno de Medeiros > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > From breno.demedeiros@gmail.com Fri Dec 4 10:46:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E04928C0E9 for ; Fri, 4 Dec 2009 10:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiRuCDQKQcW1 for ; Fri, 4 Dec 2009 10:46:38 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 2A29F28C0F4 for ; Fri, 4 Dec 2009 10:46:38 -0800 (PST) Received: by mail-gx0-f228.google.com with SMTP id 28so2454253gxk.9 for ; Fri, 04 Dec 2009 10:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=K24GKN1OC7q8diNhXPk56lsWdShKS5eb7/CTuac1ov8=; b=xIwOsBq6HJk4XJuUCoDmLVxMxOVza+rsYCBb4K9S8eSygOLhtmMaNQvCdZQJqZi/x4 OuGAD0pTVDbiRe/QPr+MoA/S6h23087EorGr0y5qk11f78aYrfJBKsqcmjPscd8CKzDA zN7LNcut5vhPbCWVBtux4FhoaxTgj8Vz9NZac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N8IKj7U7uXloWt3I2PkIw3ge8yMZqxaHpmwi2QeSOrBthFN76HEAns2iTL/TK+V/JG 82ddG/oCXBKWuLIK5W5a3t4lnxOHzaSzlor5eGDXvxyltJr8yo5NeKGZaMBGF3OkyxTt 5pmWjzrXvDbWKEIXm+FWm83XDMuhzAOLTjOMg= MIME-Version: 1.0 Received: by 10.101.3.1 with SMTP id f1mr4524960ani.85.1259952389656; Fri, 04 Dec 2009 10:46:29 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 10:46:29 -0800 Message-ID: From: Breno To: Brian Eaton Content-Type: multipart/alternative; boundary=001636c597be9e93350479eb8640 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:46:39 -0000 --001636c597be9e93350479eb8640 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 On Fri, Dec 4, 2009 at 10:37 AM, Brian Eaton wrote: > I think OAuth 1.0 got this right. Just specify the signature > algorithm. That can cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, > RSA-SHA256, and whatever other fancy magic someone comes up with next > year. > > Cheers, > Brian > > On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav > wrote: > > It=92s not really. > > > > > > > > We are talking about: > > > > > > > > 1. HMAC-specific: > > > > > > > > The server sends: > > > > > > > > methods=3D=94HMAC:sha-1,sha-256=94 > > > > > > > > The client replies: > > > > > > > > method=3D=94HMAC:sha-256=94 > > > > > > > > 2. MAC-generic: > > > > > > > > The server sends: > > > > > > > > methods=3D=94MAC:hmac-sha1,hmac-sha256=94 > > > > > > > > The client replies: > > > > > > > > method=3D=94MAC:hmac-sha256=94 > > > > > > > > Pick! > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:23 AM > > > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > There is no reason to make HMAC + hash a separate thing. > > > > > > > > It would make sense to define a way to specify a MAC, and to specify HM= AC > > with SHA-1 you need only say HMAC-SHA1 as the algorithm name. > > > > > > > > This is pretty conventional. > > > > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav > > wrote: > > > > I was not suggesting to explicitly mention them, just allow them. > > > > > > > > Currently, I am proposing a HMAC option with the hash algorithm as a > > parameter. This would mean changing it to a MAC option with the MAC typ= e > and > > hash algorithm as parameters. > > > > > > > > It adds a bit more complexity but nothing significant. However, if ther= e > are > > no compelling reasons to do so (no actual use cases or requirements), I > am > > more inclined to stick with HMAC and allow others to extend it by addin= g > a > > new CMAC (etc.) method. > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:17 AM > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > While there are technical merits, both from security and performance > > standpoints, to the alternative MAC proposals, there is not extensive > > library support for those, and AFAIK they have little usage in the > Internet. > > I am not sure if it makes sense for OAuth to be on the leading edge in > terms > > of MAC algorithm adoption. > > > > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > > wrote: > > > > Is there actual demand to make the HMAC method more generic to allow > other > > kinds of MAC? > > > > EHL > > > >> -----Original Message----- > >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > >> Sent: Thursday, November 26, 2009 7:43 PM > >> To: Eran Hammer-Lahav; Stephen Farrell > >> Cc: OAuth WG (oauth@ietf.org) > > > >> Subject: RE: [OAUTH-WG] Signature crypto > >> > >> >> Sounds reasonable if all you need to negotiate are hash algorithm > >> >> names. > >> >> Is that the case? > >> > >> > Yes. > >> > >> Not quite. > >> OAuth (at least the authentication part) mainly needs a MAC algorithm, > not > >> a > >> hash algorithm. > >> HMAC is one popular MAC algorithm that is build from a hash algorithm. > >> However, there are other MAC algorithms =97 based on block ciphers for > >> instance (eg CMAC-AES). > >> The hash registry http://www.iana.org/assignments/hash-function-text- > >> names/ is not really going to help. > >> > >> P.S. The body-signing OAuth extension is the one place that uses a has= h > >> (not > >> a MAC) directly. > >> > >> James Manger > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Breno de Medeiros > > > > > > -- > > Breno de Medeiros > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > --=20 Breno de Medeiros --001636c597be9e93350479eb8640 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1

On Fri, Dec 4, 2009 at 10:37 AM, Brian= Eaton <beaton@go= ogle.com> wrote:
I think OAuth 1.0 got this right. =A0Just specify the signature
algorithm. =A0That can cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1,
RSA-SHA256, and whatever other fancy magic someone comes up with next
year.

Cheers,
Brian

On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> It=92s not really.
>
>
>
> We are talking about:
>
>
>
> 1. HMAC-specific:
>
>
>
> The server sends:
>
>
>
> methods=3D=94HMAC:sha-1,sha-256=94
>
>
>
> The client replies:
>
>
>
> method=3D=94HMAC:sha-256=94
>
>
>
> 2. MAC-generic:
>
>
>
> The server sends:
>
>
>
> methods=3D=94MAC:hmac-sha1,hmac-sha256=94
>
>
>
> The client replies:
>
>
>
> method=3D=94MAC:hmac-sha256=94
>
>
>
> Pick!
>
>
>
> EHL
>
>
>
> From: Breno [mailto:bren= o.demedeiros@gmail.com]
> Sent: Friday, December 04, 2009 10:23 AM
>
> To: Eran Hammer-Lahav
> Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Signature crypto
>
>
>
> There is no reason to make HMAC + hash a separate thing.
>
>
>
> It would make sense to define a way to specify a MAC, and to specify H= MAC
> with SHA-1 you need only say HMAC-SHA1 as the algorithm name.
>
>
>
> This is pretty conventional.
>
> On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>
> I was not suggesting to explicitly mention them, just allow them.
>
>
>
> Currently, I am proposing a HMAC option with the hash algorithm as a > parameter. This would mean changing it to a MAC option with the MAC ty= pe and
> hash algorithm as parameters.
>
>
>
> It adds a bit more complexity but nothing significant. However, if the= re are
> no compelling reasons to do so (no actual use cases or requirements), = I am
> more inclined to stick with HMAC and allow others to extend it by addi= ng a
> new CMAC (etc.) method.
>
>
>
> EHL
>
>
>
> From: Breno [mailto:bren= o.demedeiros@gmail.com]
> Sent: Friday, December 04, 2009 10:17 AM
> To: Eran Hammer-Lahav
> Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
>
> Subject: Re: [OAUTH-WG] Signature crypto
>
>
>
> While there are technical merits, both from security and performance > standpoints, to the alternative MAC proposals, there is not extensive<= br> > library support for those, and AFAIK they have little usage in the Int= ernet.
> I am not sure if it makes sense for OAuth to be on the leading edge in= terms
> of MAC algorithm adoption.
>
> On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>
> Is there actual demand to make the HMAC method more generic to allow o= ther
> kinds of MAC?
>
> EHL
>
>> -----Original Message-----
>> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
>> Sent: Thursday, November 26, 2009 7:43 PM
>> To: Eran Hammer-Lahav; Stephen Farrell
>> Cc: OAuth WG (oauth@ietf.org= )
>
>> Subject: RE: [OAUTH-WG] Signature crypto
>>
>> >> Sounds reasonable if all you need to negotiate are hash a= lgorithm
>> >> names.
>> >> Is that the case?
>>
>> > Yes.
>>
>> Not quite.
>> OAuth (at least the authentication part) mainly needs a MAC algori= thm, not
>> a
>> hash algorithm.
>> HMAC is one popular MAC algorithm that is build from a hash algori= thm.
>> However, there are other MAC algorithms =97 based on block ciphers= for
>> instance (eg CMAC-AES).
>> The hash registry http://www.iana.org/assignments/hash-func= tion-text-
>> names/ is not really going to help.
>>
>> P.S. The body-signing OAuth extension is the one place that uses a= hash
>> (not
>> a MAC) directly.
>>
>> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Breno de Medeiros
>
>
> --
> Breno de Medeiros
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>



--
Breno de Me= deiros

--001636c597be9e93350479eb8640-- From breno.demedeiros@gmail.com Fri Dec 4 10:48:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0B43A686C for ; Fri, 4 Dec 2009 10:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPL5JQaAx00j for ; Fri, 4 Dec 2009 10:48:31 -0800 (PST) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 737553A67C1 for ; Fri, 4 Dec 2009 10:48:31 -0800 (PST) Received: by ywh1 with SMTP id 1so2976992ywh.18 for ; Fri, 04 Dec 2009 10:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=t+9lpRo7KuKpTaF+66V2GFn8ZqcebEW4StfxxrvCnjQ=; b=psvg9HfrC93jFmo7EUYmHvuRGeBILhQvO0L0M5EjFhCBjQk9/T8ZFUaTRHEaABweNT 4+EiKuwZvEoRyzJmonYZhDBCpps84Vc+HZYJP2AE9DOIIYMoABkh5EsyXGfw/trzAeCV QaXaTqqsuqYc7nwp79/MMcI/iUCuKb+BpeE3Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wG89G+DZTXc88Y0KA6QNZnLL8ERJ9bYg5csmX1wN5WPEZ2XTNvj7mrMp8RmOkG8V41 ICEIqCYxfg6DElkDRGXLWtci6Hg74NwMpegfgf+V2HaKeFqxlOolxtXppj1TbyIUhylT rbI03t9s7dKbOQZK3Vt4WGhS79FZAZyq0eiOk= MIME-Version: 1.0 Received: by 10.101.29.9 with SMTP id g9mr4472772anj.123.1259952499388; Fri, 04 Dec 2009 10:48:19 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 10:48:19 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636b2b0cd28f73e0479eb8d4c Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:48:33 -0000 --001636b2b0cd28f73e0479eb8d4c Content-Type: text/plain; charset=ISO-8859-1 The difference between HMAC and RSA is artificial, I agree with Brian. All integrity/authenticity mechanisms take a key and a text. Everything else is defined by the algorithm itself. HMAC-SHA1, HMAC-SHA256, and RSA-SHA1 are completely different mechanisms. The fact that RSA-SHA1 and HMAC-SHA1 share a hash algorithm is an implementation detail that OAuth should not be aware of. On Fri, Dec 4, 2009 at 10:46 AM, Eran Hammer-Lahav wrote: > We need to group them by class so that they can be applied in a consistent > way. > > This needs to work without having to write a spec to go from HMAC-SHA1 to > HMAC-SHA256. While it is intuitive for some, it is not for others... I can > extrapolate HMAC-SHA256 from the definition of HMAC-SHA1, but I have no clue > what ECC implies and how it should work based on the defined methods (maybe > it doesn't). > > Right now we have three classes: > > HMAC, RSA, and Plain. Plain does not take any parameters. HMAC and RSA take > a hash algorithm name as parameter. > > If we are to generalize these to MAC (and possibly RSA to PK-something, if > we decide not to drop it), I need to be able to write a spec that can be > applied consistently. > > We have two ways to accomplish a baseline interop. One is to pick a small > number of algorithms like 1.0 did and leave the rest to be defined by > extensions. The second is to pick a small number of well-defined classes of > algorithm which can be applies in a consistent way, and either define a > registry for algorithm names or reuse one. > > EHL > > > -----Original Message----- > > From: Brian Eaton [mailto:beaton@google.com] > > Sent: Friday, December 04, 2009 10:38 AM > > To: Eran Hammer-Lahav > > Cc: Breno; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > > > I think OAuth 1.0 got this right. Just specify the signature algorithm. > That can > > cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, RSA-SHA256, and > > whatever other fancy magic someone comes up with next year. > > > > Cheers, > > Brian > > > > On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav > > wrote: > > > It's not really. > > > > > > > > > > > > We are talking about: > > > > > > > > > > > > 1. HMAC-specific: > > > > > > > > > > > > The server sends: > > > > > > > > > > > > methods="HMAC:sha-1,sha-256" > > > > > > > > > > > > The client replies: > > > > > > > > > > > > method="HMAC:sha-256" > > > > > > > > > > > > 2. MAC-generic: > > > > > > > > > > > > The server sends: > > > > > > > > > > > > methods="MAC:hmac-sha1,hmac-sha256" > > > > > > > > > > > > The client replies: > > > > > > > > > > > > method="MAC:hmac-sha256" > > > > > > > > > > > > Pick! > > > > > > > > > > > > EHL > > > > > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > > Sent: Friday, December 04, 2009 10:23 AM > > > > > > To: Eran Hammer-Lahav > > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > > > > > There is no reason to make HMAC + hash a separate thing. > > > > > > > > > > > > It would make sense to define a way to specify a MAC, and to specify > > > HMAC with SHA-1 you need only say HMAC-SHA1 as the algorithm name. > > > > > > > > > > > > This is pretty conventional. > > > > > > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav > > > > > > wrote: > > > > > > I was not suggesting to explicitly mention them, just allow them. > > > > > > > > > > > > Currently, I am proposing a HMAC option with the hash algorithm as a > > > parameter. This would mean changing it to a MAC option with the MAC > > > type and hash algorithm as parameters. > > > > > > > > > > > > It adds a bit more complexity but nothing significant. However, if > > > there are no compelling reasons to do so (no actual use cases or > > > requirements), I am more inclined to stick with HMAC and allow others > > > to extend it by adding a new CMAC (etc.) method. > > > > > > > > > > > > EHL > > > > > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > > Sent: Friday, December 04, 2009 10:17 AM > > > To: Eran Hammer-Lahav > > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > > > > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > > > > > While there are technical merits, both from security and performance > > > standpoints, to the alternative MAC proposals, there is not extensive > > > library support for those, and AFAIK they have little usage in the > Internet. > > > I am not sure if it makes sense for OAuth to be on the leading edge in > > > terms of MAC algorithm adoption. > > > > > > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > > > > > > wrote: > > > > > > Is there actual demand to make the HMAC method more generic to allow > > > other kinds of MAC? > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > > >> Sent: Thursday, November 26, 2009 7:43 PM > > >> To: Eran Hammer-Lahav; Stephen Farrell > > >> Cc: OAuth WG (oauth@ietf.org) > > > > > >> Subject: RE: [OAUTH-WG] Signature crypto > > >> > > >> >> Sounds reasonable if all you need to negotiate are hash algorithm > > >> >> names. > > >> >> Is that the case? > > >> > > >> > Yes. > > >> > > >> Not quite. > > >> OAuth (at least the authentication part) mainly needs a MAC > > >> algorithm, not a hash algorithm. > > >> HMAC is one popular MAC algorithm that is build from a hash algorithm. > > >> However, there are other MAC algorithms - based on block ciphers for > > >> instance (eg CMAC-AES). > > >> The hash registry http://www.iana.org/assignments/hash-function-text- > > >> names/ is not really going to help. > > >> > > >> P.S. The body-signing OAuth extension is the one place that uses a > > >> hash (not a MAC) directly. > > >> > > >> James Manger > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > -- > > > Breno de Medeiros > > > > > > > > > -- > > > Breno de Medeiros > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > -- Breno de Medeiros --001636b2b0cd28f73e0479eb8d4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The difference between HMAC and RSA is artificial, I agree with Brian.
=
All integrity/authenticity mechanisms take a key and a text.= Everything else is defined by the algorithm itself.

HMAC-SHA1, HMAC-SHA256, and RSA-SHA1 are completely different mechanis= ms. The fact that RSA-SHA1 and HMAC-SHA1 share a hash algorithm is an imple= mentation detail that OAuth should not be aware of.

On Fri, Dec 4, 2009 at 10:46 AM, Eran Hammer-Lahav <eran@hueniverse.com> wro= te:
We need to group them by class so that they can be applied in a consistent = way.

This needs to work without having to write a spec to go from HMAC-SHA1 to H= MAC-SHA256. While it is intuitive for some, it is not for others... I can e= xtrapolate HMAC-SHA256 from the definition of HMAC-SHA1, but I have no clue= what ECC implies and how it should work based on the defined methods (mayb= e it doesn't).

Right now we have three classes:

HMAC, RSA, and Plain. Plain does not take any parameters. HMAC and RSA take= a hash algorithm name as parameter.

If we are to generalize these to MAC (and possibly RSA to PK-something, if = we decide not to drop it), I need to be able to write a spec that can be ap= plied consistently.

We have two ways to accomplish a baseline interop. One is to pick a small n= umber of algorithms like 1.0 did and leave the rest to be defined by extens= ions. The second is to pick a small number of well-defined classes of algor= ithm which can be applies in a consistent way, and either define a registry= for algorithm names or reuse one.

EHL

> -----Original Message-----
> From: Brian Eaton [mailto:beaton@= google.com]
> Sent: Friday, December 04, 2009 10:38 AM
> To: Eran Hammer-Lahav
> Cc: Breno; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Signature crypto
>
> I think OAuth 1.0 got this right. =A0Just specify the signature algori= thm. =A0That can
> cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, RSA-SHA256, and
> whatever other fancy magic someone comes up with next year.
>
> Cheers,
> Brian
>
> On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav
> <eran@hueniverse.com>= wrote:
> > It's not really.
> >
> >
> >
> > We are talking about:
> >
> >
> >
> > 1. HMAC-specific:
> >
> >
> >
> > The server sends:
> >
> >
> >
> > methods=3D"HMAC:sha-1,sha-256"
> >
> >
> >
> > The client replies:
> >
> >
> >
> > method=3D"HMAC:sha-256"
> >
> >
> >
> > 2. MAC-generic:
> >
> >
> >
> > The server sends:
> >
> >
> >
> > methods=3D"MAC:hmac-sha1,hmac-sha256"
> >
> >
> >
> > The client replies:
> >
> >
> >
> > method=3D"MAC:hmac-sha256"
> >
> >
> >
> > Pick!
> >
> >
> >
> > EHL
> >
> >
> >
> > From: Breno [mailto:breno.demedeiros@gmail.com]
> > Sent: Friday, December 04, 2009 10:23 AM
> >
> > To: Eran Hammer-Lahav
> > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
> > Subject: Re: [OAUTH-WG] Signature crypto
> >
> >
> >
> > There is no reason to make HMAC + hash a separate thing.
> >
> >
> >
> > It would make sense to define a way to specify a MAC, and to spec= ify
> > HMAC with SHA-1 you need only say HMAC-SHA1 as the algorithm name= .
> >
> >
> >
> > This is pretty conventional.
> >
> > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav
> > <eran@hueniverse.com>
> > wrote:
> >
> > I was not suggesting to explicitly mention them, just allow them.=
> >
> >
> >
> > Currently, I am proposing a HMAC option with the hash algorithm a= s a
> > parameter. This would mean changing it to a MAC option with the M= AC
> > type and hash algorithm as parameters.
> >
> >
> >
> > It adds a bit more complexity but nothing significant. However, i= f
> > there are no compelling reasons to do so (no actual use cases or<= br> > > requirements), I am more inclined to stick with HMAC and allow ot= hers
> > to extend it by adding a new CMAC (etc.) method.
> >
> >
> >
> > EHL
> >
> >
> >
> > From: Breno [mailto:breno.demedeiros@gmail.com]
> > Sent: Friday, December 04, 2009 10:17 AM
> > To: Eran Hammer-Lahav
> > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
> >
> > Subject: Re: [OAUTH-WG] Signature crypto
> >
> >
> >
> > While there are technical merits, both from security and performa= nce
> > standpoints, to the alternative MAC proposals, there is not exten= sive
> > library support for those, and AFAIK they have little usage in th= e Internet.
> > I am not sure if it makes sense for OAuth to be on the leading ed= ge in
> > terms of MAC algorithm adoption.
> >
> > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav
> > <eran@hueniverse.com>
> > wrote:
> >
> > Is there actual demand to make the HMAC method more generic to al= low
> > other kinds of MAC?
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com]
> >> Sent: Thursday, November 26, 2009 7:43 PM
> >> To: Eran Hammer-Lahav; Stephen Farrell
> >> Cc: OAuth WG (oauth@ietf.or= g)
> >
> >> Subject: RE: [OAUTH-WG] Signature crypto
> >>
> >> >> Sounds reasonable if all you need to negotiate are h= ash algorithm
> >> >> names.
> >> >> Is that the case?
> >>
> >> > Yes.
> >>
> >> Not quite.
> >> OAuth (at least the authentication part) mainly needs a MAC > >> algorithm, not a hash algorithm.
> >> HMAC is one popular MAC algorithm that is build from a hash a= lgorithm.
> >> However, there are other MAC algorithms - based on block ciph= ers for
> >> instance (eg CMAC-AES).
> >> The hash registry http://www.iana.org/assignments/hash= -function-text-
> >> names/ is not really going to help.
> >>
> >> P.S. The body-signing OAuth extension is the one place that u= ses a
> >> hash (not a MAC) directly.
> >>
> >> James Manger
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > --
> > Breno de Medeiros
> >
> >
> > --
> > Breno de Medeiros
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >



--
Breno de Me= deiros

--001636b2b0cd28f73e0479eb8d4c-- From stephen.farrell@cs.tcd.ie Fri Dec 4 10:55:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EDD13A684F for ; Fri, 4 Dec 2009 10:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfns-q+y-ZJo for ; Fri, 4 Dec 2009 10:55:09 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 7A6713A67D8 for ; Fri, 4 Dec 2009 10:55:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 7C9F536006D; Fri, 4 Dec 2009 18:54:56 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHRFYaKIEJ3d; Fri, 4 Dec 2009 18:54:52 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 0165536006C; Fri, 4 Dec 2009 18:54:52 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id E71437C353; Fri, 4 Dec 2009 18:54:51 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjxSvPB9t7HV; Fri, 4 Dec 2009 18:54:42 +0000 (GMT) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail01.newbay.com (Postfix) with ESMTP id F2DEE7C340; Fri, 4 Dec 2009 18:54:41 +0000 (GMT) References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: <5D75A64A-798D-4BDA-8ECD-10B3DA0AF78B@cs.tcd.ie> From: Stephen Farrell To: Breno In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2-325317196 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 4 Dec 2009 18:54:31 +0000 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 18:55:11 -0000 --Apple-Mail-2-325317196 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 4 Dec 2009, at 18:46, Breno wrote: > +1 Me too. S. > > On Fri, Dec 4, 2009 at 10:37 AM, Brian Eaton =20 > wrote: > I think OAuth 1.0 got this right. Just specify the signature > algorithm. That can cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, > RSA-SHA256, and whatever other fancy magic someone comes up with next > year. > > Cheers, > Brian > > On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav = > wrote: > > It=E2=80=99s not really. > > > > > > > > We are talking about: > > > > > > > > 1. HMAC-specific: > > > > > > > > The server sends: > > > > > > > > methods=3D=E2=80=9DHMAC:sha-1,sha-256=E2=80=9D > > > > > > > > The client replies: > > > > > > > > method=3D=E2=80=9DHMAC:sha-256=E2=80=9D > > > > > > > > 2. MAC-generic: > > > > > > > > The server sends: > > > > > > > > methods=3D=E2=80=9DMAC:hmac-sha1,hmac-sha256=E2=80=9D > > > > > > > > The client replies: > > > > > > > > method=3D=E2=80=9DMAC:hmac-sha256=E2=80=9D > > > > > > > > Pick! > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:23 AM > > > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > There is no reason to make HMAC + hash a separate thing. > > > > > > > > It would make sense to define a way to specify a MAC, and to =20 > specify HMAC > > with SHA-1 you need only say HMAC-SHA1 as the algorithm name. > > > > > > > > This is pretty conventional. > > > > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav = > > > wrote: > > > > I was not suggesting to explicitly mention them, just allow them. > > > > > > > > Currently, I am proposing a HMAC option with the hash algorithm as a > > parameter. This would mean changing it to a MAC option with the =20 > MAC type and > > hash algorithm as parameters. > > > > > > > > It adds a bit more complexity but nothing significant. However, if =20= > there are > > no compelling reasons to do so (no actual use cases or =20 > requirements), I am > > more inclined to stick with HMAC and allow others to extend it by =20= > adding a > > new CMAC (etc.) method. > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:17 AM > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > While there are technical merits, both from security and performance > > standpoints, to the alternative MAC proposals, there is not =20 > extensive > > library support for those, and AFAIK they have little usage in the =20= > Internet. > > I am not sure if it makes sense for OAuth to be on the leading =20 > edge in terms > > of MAC algorithm adoption. > > > > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav = > > > wrote: > > > > Is there actual demand to make the HMAC method more generic to =20 > allow other > > kinds of MAC? > > > > EHL > > > >> -----Original Message----- > >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > >> Sent: Thursday, November 26, 2009 7:43 PM > >> To: Eran Hammer-Lahav; Stephen Farrell > >> Cc: OAuth WG (oauth@ietf.org) > > > >> Subject: RE: [OAUTH-WG] Signature crypto > >> > >> >> Sounds reasonable if all you need to negotiate are hash =20 > algorithm > >> >> names. > >> >> Is that the case? > >> > >> > Yes. > >> > >> Not quite. > >> OAuth (at least the authentication part) mainly needs a MAC =20 > algorithm, not > >> a > >> hash algorithm. > >> HMAC is one popular MAC algorithm that is build from a hash =20 > algorithm. > >> However, there are other MAC algorithms =E2=80=94 based on block = ciphers =20 > for > >> instance (eg CMAC-AES). > >> The hash registry = http://www.iana.org/assignments/hash-function-text- > >> names/ is not really going to help. > >> > >> P.S. The body-signing OAuth extension is the one place that uses =20= > a hash > >> (not > >> a MAC) directly. > >> > >> James Manger > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Breno de Medeiros > > > > > > -- > > Breno de Medeiros > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > --=20 > Breno de Medeiros > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2-325317196 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 4 Dec 2009, at 18:46, = Breno <breno.demedeiros@gmail.com&= gt; wrote:

+1
Me = too. 
S.

On Fri, Dec 4, 2009 at 10:37 AM, Brian Eaton <beaton@google.com> = wrote:
I think OAuth 1.0 got this right.  Just specify the signature
algorithm.  That can cover HMAC-SHA1, HMAC-SHA256, ECC, = RSA-SHA1,
RSA-SHA256, and whatever other fancy magic someone comes up with = next
year.

Cheers,
Brian

On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav <eran@hueniverse.com> = wrote:
> It=E2=80=99s not really.
>
>
>
> We are talking about:
>
>
>
> 1. HMAC-specific:
>
>
>
> The server sends:
>
>
>
> methods=3D=E2=80=9DHMAC:sha-1,sha-256=E2=80=9D
>
>
>
> The client replies:
>
>
>
> method=3D=E2=80=9DHMAC:sha-256=E2=80=9D
>
>
>
> 2. MAC-generic:
>
>
>
> The server sends:
>
>
>
> methods=3D=E2=80=9DMAC:hmac-sha1,hmac-sha256=E2=80=9D
>
>
>
> The client replies:
>
>
>
> method=3D=E2=80=9DMAC:hmac-sha256=E2=80=9D
>
>
>
> Pick!
>
>
>
> EHL
>
>
>
> From: Breno [mailto:breno.demedeiros@gmail.com<= /a>]
> Sent: Friday, December 04, 2009 10:23 AM
>
> To: Eran Hammer-Lahav
> Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Signature crypto
>
>
>
> There is no reason to make HMAC + hash a separate thing.
>
>
>
> It would make sense to define a way to specify a MAC, and to = specify HMAC
> with SHA-1 you need only say HMAC-SHA1 as the algorithm name.
>
>
>
> This is pretty conventional.
>
> On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>
> I was not suggesting to explicitly mention them, just allow = them.
>
>
>
> Currently, I am proposing a HMAC option with the hash algorithm as = a
> parameter. This would mean changing it to a MAC option with the MAC = type and
> hash algorithm as parameters.
>
>
>
> It adds a bit more complexity but nothing significant. However, if = there are
> no compelling reasons to do so (no actual use cases or = requirements), I am
> more inclined to stick with HMAC and allow others to extend it by = adding a
> new CMAC (etc.) method.
>
>
>
> EHL
>
>
>
> From: Breno [mailto:breno.demedeiros@gmail.com<= /a>]
> Sent: Friday, December 04, 2009 10:17 AM
> To: Eran Hammer-Lahav
> Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
>
> Subject: Re: [OAUTH-WG] Signature crypto
>
>
>
> While there are technical merits, both from security and = performance
> standpoints, to the alternative MAC proposals, there is not = extensive
> library support for those, and AFAIK they have little usage in the = Internet.
> I am not sure if it makes sense for OAuth to be on the leading edge = in terms
> of MAC algorithm adoption.
>
> On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>
> Is there actual demand to make the HMAC method more generic to = allow other
> kinds of MAC?
>
> EHL
>
>> -----Original Message-----
>> From: Manger, James H [mailto:James.H.Manger@team.telstr= a.com]
>> Sent: Thursday, November 26, 2009 7:43 PM
>> To: Eran Hammer-Lahav; Stephen Farrell
>> Cc: OAuth WG (oauth@ietf.org)
>
>> Subject: RE: [OAUTH-WG] Signature crypto
>>
>> >> Sounds reasonable if all you need to negotiate are = hash algorithm
>> >> names.
>> >> Is that the case?
>>
>> > Yes.
>>
>> Not quite.
>> OAuth (at least the authentication part) mainly needs a MAC = algorithm, not
>> a
>> hash algorithm.
>> HMAC is one popular MAC algorithm that is build from a hash = algorithm.
>> However, there are other MAC algorithms =E2=80=94 based on = block ciphers for
>> instance (eg CMAC-AES).
>> The hash registry http://www.ia= na.org/assignments/hash-function-text-
>> names/ is not really going to help.
>>
>> P.S. The body-signing OAuth extension is the one place that = uses a hash
>> (not
>> a MAC) directly.
>>
>> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/= mailman/listinfo/oauth
>
>
> --
> Breno de Medeiros
>
>
> --
> Breno de Medeiros
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/= mailman/listinfo/oauth
>
>



--
Breno de = Medeiros

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
= --Apple-Mail-2-325317196-- From eran@hueniverse.com Fri Dec 4 11:11:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C303A685B for ; Fri, 4 Dec 2009 11:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSnWTMxZYM17 for ; Fri, 4 Dec 2009 11:11:15 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7E58A3A68B1 for ; Fri, 4 Dec 2009 11:11:14 -0800 (PST) Received: (qmail 23108 invoked from network); 4 Dec 2009 19:10:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 19:10:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 4 Dec 2009 12:10:03 -0700 From: Eran Hammer-Lahav To: Breno Date: Fri, 4 Dec 2009 12:10:20 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1ElpieItUvq0+SA269yM4WjFgGAAAl7jg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723437852936BCP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:11:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723437852936BCP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not exactly. MAC and RSA require a different kind of shared secret and are = validated differently. I am trying to avoid the need to publish a specification every time you wan= t to add a new MAC-based algorithm. I am not trying to actually pick and ch= oose specific ones. OAuth can be crypto agnostic. I am not suggesting otherwise. I am simply lo= oking for the easiest way to support common extensions such as HMAC with ne= w hash functions. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 10:48 AM To: Eran Hammer-Lahav Cc: Brian Eaton; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto The difference between HMAC and RSA is artificial, I agree with Brian. All integrity/authenticity mechanisms take a key and a text. Everything els= e is defined by the algorithm itself. HMAC-SHA1, HMAC-SHA256, and RSA-SHA1 are completely different mechanisms. T= he fact that RSA-SHA1 and HMAC-SHA1 share a hash algorithm is an implementa= tion detail that OAuth should not be aware of. On Fri, Dec 4, 2009 at 10:46 AM, Eran Hammer-Lahav > wrote: We need to group them by class so that they can be applied in a consistent = way. This needs to work without having to write a spec to go from HMAC-SHA1 to H= MAC-SHA256. While it is intuitive for some, it is not for others... I can e= xtrapolate HMAC-SHA256 from the definition of HMAC-SHA1, but I have no clue= what ECC implies and how it should work based on the defined methods (mayb= e it doesn't). Right now we have three classes: HMAC, RSA, and Plain. Plain does not take any parameters. HMAC and RSA take= a hash algorithm name as parameter. If we are to generalize these to MAC (and possibly RSA to PK-something, if = we decide not to drop it), I need to be able to write a spec that can be ap= plied consistently. We have two ways to accomplish a baseline interop. One is to pick a small n= umber of algorithms like 1.0 did and leave the rest to be defined by extens= ions. The second is to pick a small number of well-defined classes of algor= ithm which can be applies in a consistent way, and either define a registry= for algorithm names or reuse one. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, December 04, 2009 10:38 AM > To: Eran Hammer-Lahav > Cc: Breno; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto > > I think OAuth 1.0 got this right. Just specify the signature algorithm. = That can > cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, RSA-SHA256, and > whatever other fancy magic someone comes up with next year. > > Cheers, > Brian > > On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav > > wrote: > > It's not really. > > > > > > > > We are talking about: > > > > > > > > 1. HMAC-specific: > > > > > > > > The server sends: > > > > > > > > methods=3D"HMAC:sha-1,sha-256" > > > > > > > > The client replies: > > > > > > > > method=3D"HMAC:sha-256" > > > > > > > > 2. MAC-generic: > > > > > > > > The server sends: > > > > > > > > methods=3D"MAC:hmac-sha1,hmac-sha256" > > > > > > > > The client replies: > > > > > > > > method=3D"MAC:hmac-sha256" > > > > > > > > Pick! > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:23 AM > > > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > There is no reason to make HMAC + hash a separate thing. > > > > > > > > It would make sense to define a way to specify a MAC, and to specify > > HMAC with SHA-1 you need only say HMAC-SHA1 as the algorithm name. > > > > > > > > This is pretty conventional. > > > > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav > > > > > wrote: > > > > I was not suggesting to explicitly mention them, just allow them. > > > > > > > > Currently, I am proposing a HMAC option with the hash algorithm as a > > parameter. This would mean changing it to a MAC option with the MAC > > type and hash algorithm as parameters. > > > > > > > > It adds a bit more complexity but nothing significant. However, if > > there are no compelling reasons to do so (no actual use cases or > > requirements), I am more inclined to stick with HMAC and allow others > > to extend it by adding a new CMAC (etc.) method. > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:17 AM > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > While there are technical merits, both from security and performance > > standpoints, to the alternative MAC proposals, there is not extensive > > library support for those, and AFAIK they have little usage in the Inte= rnet. > > I am not sure if it makes sense for OAuth to be on the leading edge in > > terms of MAC algorithm adoption. > > > > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > > > > > wrote: > > > > Is there actual demand to make the HMAC method more generic to allow > > other kinds of MAC? > > > > EHL > > > >> -----Original Message----- > >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > >> Sent: Thursday, November 26, 2009 7:43 PM > >> To: Eran Hammer-Lahav; Stephen Farrell > >> Cc: OAuth WG (oauth@ietf.org) > > > >> Subject: RE: [OAUTH-WG] Signature crypto > >> > >> >> Sounds reasonable if all you need to negotiate are hash algorithm > >> >> names. > >> >> Is that the case? > >> > >> > Yes. > >> > >> Not quite. > >> OAuth (at least the authentication part) mainly needs a MAC > >> algorithm, not a hash algorithm. > >> HMAC is one popular MAC algorithm that is build from a hash algorithm. > >> However, there are other MAC algorithms - based on block ciphers for > >> instance (eg CMAC-AES). > >> The hash registry http://www.iana.org/assignments/hash-function-text- > >> names/ is not really going to help. > >> > >> P.S. The body-signing OAuth extension is the one place that uses a > >> hash (not a MAC) directly. > >> > >> James Manger > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Breno de Medeiros > > > > > > -- > > Breno de Medeiros > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723437852936BCP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not exact= ly. MAC and RSA require a different kind of shared secret and are validated= differently.

 <= /o:p>

I am trying to avoid the need t= o publish a specification every time you want to add a new MAC-based algori= thm. I am not trying to actually pick and choose specific ones.<= /span>

 

OAuth can be crypto agnostic. I am not suggesting other= wise. I am simply looking for the easiest way to support common extensions = such as HMAC with new hash functions.

 

EHL

 

=

From: Breno [mailto:breno.demedeiro= s@gmail.com]
Sent: Friday, December 04, 2009 10:48 AM
To:<= /b> Eran Hammer-Lahav
Cc: Brian Eaton; OAuth WG (oauth@ietf.org)<= br>Subject: Re: [OAUTH-WG] Signature crypto

 

The= difference between HMAC and RSA is artificial, I agree with Brian.

 

All integrity/authenticity mechanisms take a key and a text. E= verything else is defined by the algorithm itself.

 

HMAC-SHA1, HMAC-SHA256, and RSA-SHA1 are com= pletely different mechanisms. The fact that RSA-SHA1 and HMAC-SHA1 share a = hash algorithm is an implementation detail that OAuth should not be aware o= f.

On Fri, Dec 4, 2009 at 10:46 AM,= Eran Hammer-Lahav <eran@hueniver= se.com> wrote:

We need to group t= hem by class so that they can be applied in a consistent way.

This n= eeds to work without having to write a spec to go from HMAC-SHA1 to HMAC-SH= A256. While it is intuitive for some, it is not for others... I can extrapo= late HMAC-SHA256 from the definition of HMAC-SHA1, but I have no clue what = ECC implies and how it should work based on the defined methods (maybe it d= oesn't).

Right now we have three classes:

HMAC, RSA, and Plai= n. Plain does not take any parameters. HMAC and RSA take a hash algorithm n= ame as parameter.

If we are to generalize these to MAC (and possibly= RSA to PK-something, if we decide not to drop it), I need to be able to wr= ite a spec that can be applied consistently.

We have two ways to acc= omplish a baseline interop. One is to pick a small number of algorithms lik= e 1.0 did and leave the rest to be defined by extensions. The second is to = pick a small number of well-defined classes of algorithm which can be appli= es in a consistent way, and either define a registry for algorithm names or= reuse one.

EHL

<= div>


> -----Original Message-----
> From: = Brian Eaton [mailto:beaton@google.com<= /a>]
> Sent: Friday, December 04, 2009 10:38 AM
> To: Eran Hamm= er-Lahav

> Cc: Breno;= OAuth WG (oauth@ietf.org)
> Su= bject: Re: [OAUTH-WG] Signature crypto
>
> I think OAuth 1.0 go= t this right.  Just specify the signature algorithm.  That can> cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, RSA-SHA256, and
> = whatever other fancy magic someone comes up with next year.
>
>= Cheers,
> Brian
>
> On Fri, Dec 4, 2009 at 10:28 AM, Era= n Hammer-Lahav
> <eran@huen= iverse.com> wrote:
> > It's not really.
> >
>= ; >
> >
> > We are talking about:
> >
>= >
> >
> > 1. HMAC-specific:
> >
> >=
> >
> > The server sends:
> >
> >
&= gt; >
> > methods=3D"HMAC:sha-1,sha-256"
> >=
> >
> >
> > The client replies:
> >> >
> >
> > method=3D"HMAC:sha-256"
&= gt; >
> >
> >
> > 2. MAC-generic:
> >= ;
> >
> >
> > The server sends:
> >
= > >
> >
> > methods=3D"MAC:hmac-sha1,hmac-sha2= 56"
> >
> >
> >
> > The client rep= lies:
> >
> >
> >
> > method=3D"MA= C:hmac-sha256"
> >
> >
> >
> > Pic= k!
> >
> >
> >
> > EHL
> >
= > >
> >
> > From: Breno [mailto:breno.demedeiros@gmail.com]
> > Sen= t: Friday, December 04, 2009 10:23 AM
> >
> > To: Eran Ha= mmer-Lahav
> > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
> > Subject: Re= : [OAUTH-WG] Signature crypto
> >
> >
> >
>= ; > There is no reason to make HMAC + hash a separate thing.
> >= ;
> >
> >
> > It would make sense to define a wa= y to specify a MAC, and to specify
> > HMAC with SHA-1 you need on= ly say HMAC-SHA1 as the algorithm name.
> >
> >
> &= gt;
> > This is pretty conventional.
> >
> > On = Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav
> > <eran@hueniverse.com>
> > wrote= :
> >
> > I was not suggesting to explicitly mention them= , just allow them.
> >
> >
> >
> > Curr= ently, I am proposing a HMAC option with the hash algorithm as a
> &g= t; parameter. This would mean changing it to a MAC option with the MAC
&= gt; > type and hash algorithm as parameters.
> >
> >> >
> > It adds a bit more complexity but nothing signific= ant. However, if
> > there are no compelling reasons to do so (no = actual use cases or
> > requirements), I am more inclined to stick= with HMAC and allow others
> > to extend it by adding a new CMAC = (etc.) method.
> >
> >
> >
> > EHL
&= gt; >
> >
> >
> > From: Breno [mailto:breno.demedeiros@gmail.com]
&= gt; > Sent: Friday, December 04, 2009 10:17 AM
> > To: Eran Ham= mer-Lahav
> > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org)
> >
> >= Subject: Re: [OAUTH-WG] Signature crypto
> >
> >
>= >
> > While there are technical merits, both from security and= performance
> > standpoints, to the alternative MAC proposals, th= ere is not extensive
> > library support for those, and AFAIK they= have little usage in the Internet.
> > I am not sure if it makes = sense for OAuth to be on the leading edge in
> > terms of MAC algo= rithm adoption.
> >
> > On Fri, Dec 4, 2009 at 10:07 AM, = Eran Hammer-Lahav
> > <e= ran@hueniverse.com>
> > wrote:
> >
> > Is= there actual demand to make the HMAC method more generic to allow
> = > other kinds of MAC?
> >
> > EHL
> >
>= >> -----Original Message-----
> >> From: Manger, James H= [mailto:James.H.Manger@= team.telstra.com]
> >> Sent: Thursday, November 26, 2009 7:= 43 PM
> >> To: Eran Hammer-Lahav; Stephen Farrell
> >&= gt; Cc: OAuth WG (oauth@ietf.org)
= > >
> >> Subject: RE: [OAUTH-WG] Signature crypto
>= >>
> >> >> Sounds reasonable if all you need to ne= gotiate are hash algorithm
> >> >> names.
> >>= ; >> Is that the case?
> >>
> >> > Yes.> >>
> >> Not quite.
> >> OAuth (at least= the authentication part) mainly needs a MAC
> >> algorithm, no= t a hash algorithm.
> >> HMAC is one popular MAC algorithm that= is build from a hash algorithm.
> >> However, there are other = MAC algorithms - based on block ciphers for
> >> instance (eg C= MAC-AES).
> >> The hash registry http://www.iana.org/ass= ignments/hash-function-text-
> >> names/ is not really goin= g to help.
> >>
> >> P.S. The body-signing OAuth ex= tension is the one place that uses a
> >> hash (not a MAC) dire= ctly.
> >>
> >> James Manger
> > _________= ______________________________________
> > OAuth mailing list
&= gt; > OAuth@ietf.org
> > = h= ttps://www.ietf.org/mailman/listinfo/oauth
> >
> >> > --
> > Breno de Medeiros
> >
> >
&= gt; > --
> > Breno de Medeiros
> >
> > ______= _________________________________________
> > OAuth mailing list> > OAuth@ietf.org
> &g= t; https://www.ietf.org/mailman/listinfo/oauth
> >
> >=




--
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E723437852936BCP3PW5EX1MB01E_-- From beaton@google.com Fri Dec 4 11:13:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C933A685B for ; Fri, 4 Dec 2009 11:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVVEoERkJQ1k for ; Fri, 4 Dec 2009 11:12:58 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1FA093A63EB for ; Fri, 4 Dec 2009 11:12:57 -0800 (PST) Received: from spaceape13.eur.corp.google.com (spaceape13.eur.corp.google.com [172.28.16.147]) by smtp-out.google.com with ESMTP id nB4JClYi000507 for ; Fri, 4 Dec 2009 19:12:47 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259953967; bh=S8UUbbuk1uqVi6unVoHp/oI+yuc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Yh/JhEk8yfUr6O/pQkVH2AoJILhJPIlFOblDXh4Zjhg0GLCgFsQ/3qtsmtNlBsdIS hWFHMdxF2nNcGSJJ/oHKA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=N4j54txcKXFFfgNNJV60JWms8JDHNUj03syU/b0Y1tQQLppRgpp+PcsLnENoYu/5P BqtgZsPlIbLTDxiRYsKpw== Received: from pxi26 (pxi26.prod.google.com [10.243.27.26]) by spaceape13.eur.corp.google.com with ESMTP id nB4JCQUf007611 for ; Fri, 4 Dec 2009 11:12:44 -0800 Received: by pxi26 with SMTP id 26so611824pxi.21 for ; Fri, 04 Dec 2009 11:12:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.187.8 with SMTP id k8mr237447rvf.98.1259953963230; Fri, 04 Dec 2009 11:12:43 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 11:12:43 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:13:02 -0000 On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav wrote: > I am trying to avoid the need to publish a specification every time you want > to add a new MAC-based algorithm. People are going to end up needing to write new code every time they want to add a new MAC-based algorithm. Cheers, Brian From breno.demedeiros@gmail.com Fri Dec 4 11:20:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182193A686C for ; Fri, 4 Dec 2009 11:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgZFt8D1a1+f for ; Fri, 4 Dec 2009 11:20:35 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 1D47D3A67D8 for ; Fri, 4 Dec 2009 11:20:35 -0800 (PST) Received: by gxk28 with SMTP id 28so2485034gxk.9 for ; Fri, 04 Dec 2009 11:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=RfVJYPW+qMPVOWcspMhJISoiZu1Bf9dpdCoP/BW/3l0=; b=S4gkQooSnhOc5eiYwFZbl/Bz5Yv8uZp5EtguOpRKYLZ9oaRLd+ly7+ltByIrs2sbjO gxJQVYf2veRoK/13nviWKhqk6unbceVPUsKieYT+EB4eQOckD1vtC1QLFe3wiT4N56f+ xFi24lQ+xyDhpCu2EMhCIny9rKxHylZUrjBf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=H45GKaY+F9yOd07tIZSOEi75W3vIZ/hWoqVwlOb900lvbJvJ+yzrY0gosOSlGytpAQ BahDg2SdR+Ybq+TtP8Uk5dZx+qY6CNit4YPKX1xJaX7pOjdcFAWmBNK7FVcQC0yUTTad eLyhSDo/NFChTpmMWU3qIniM8mtEj6A2kxwNQ= MIME-Version: 1.0 Received: by 10.101.29.9 with SMTP id g9mr4562684anj.123.1259954421661; Fri, 04 Dec 2009 11:20:21 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 11:20:21 -0800 Message-ID: From: Breno To: Brian Eaton Content-Type: multipart/alternative; boundary=001636b2b0cdbc83970479ebff99 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:20:36 -0000 --001636b2b0cdbc83970479ebff99 Content-Type: text/plain; charset=ISO-8859-1 There is no need to publish a new spec for a new MAC algorithm. MAC algorithms typically go through certification (e.g., NIST) and have detailed specs, including test vectors for interoperability. For OAuth, if you want to explicitly support a new MAC algorithm you will not need to change the transport and you just have to point to the particular spec that defines the MAC algorithm. On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton wrote: > On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav > wrote: > > I am trying to avoid the need to publish a specification every time you > want > > to add a new MAC-based algorithm. > > People are going to end up needing to write new code every time they > want to add a new MAC-based algorithm. > > Cheers, > Brian > -- Breno de Medeiros --001636b2b0cdbc83970479ebff99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is no need to publish a new spec for a new MAC algorithm. MAC algorit= hms typically go through certification (e.g., NIST) and have detailed specs= , including test vectors for interoperability.

For OAuth= , if you want to explicitly support a new MAC algorithm you will not need t= o change the transport and you just have to point to the particular spec th= at defines the MAC algorithm.

On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton= <beaton@google.c= om> wrote:
On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I am trying to avoid the need to publish a specification every time yo= u want
> to add a new MAC-based algorithm.

People are going to end up needing to write new code every time they<= br>
want to add a new MAC-based algorithm.

Cheers,
Brian



--
Breno de Medeiro= s

--001636b2b0cdbc83970479ebff99-- From eran@hueniverse.com Fri Dec 4 11:24:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8137F3A67B0 for ; Fri, 4 Dec 2009 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gE2xdebe+Dom for ; Fri, 4 Dec 2009 11:24:30 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9AB083A63EB for ; Fri, 4 Dec 2009 11:24:30 -0800 (PST) Received: (qmail 7739 invoked from network); 4 Dec 2009 19:24:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 19:24:22 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 12:24:20 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 4 Dec 2009 12:24:37 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1FcV/6dJS6OFHRw6IzNJVZBD9+AAALKSQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852936D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:24:31 -0000 That's beside the point. You are talking about implementation and I'm talki= ng about specification. Are you expecting them to write a new RFC to add support for HMAC-1024? Tha= t's the implications of what you are suggesting. Instead, I am trying to de= fine a few (1 or 2) classes of algorithms, provide well-defined process of = them, and provide an easy registration process for new algorithms which fit= the class. A MAC class would be defined as applying any MAC algorithm which can be des= cribed by digest=3Dmac(key,text) where text is the signature base string, k= ey is the symmetric shared secret associated with the token, and digest is = the value sent to the server for authentication (after properly encoded). With this definition, you can extend the protocol by simply sending an emai= l to a designated list, get quick feedback, and register a new algorithm th= at fits this template. However, if you want to use a new algorithm that req= uires, say, asymmetric shared secret or a different normalization of the HT= TP request (something different from the signature base string), then you n= eed to write an RFC (or any other Open Standard) and go through a longer pr= ocess. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, December 04, 2009 11:13 AM > To: Eran Hammer-Lahav > Cc: Breno; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto >=20 > On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav > wrote: > > I am trying to avoid the need to publish a specification every time > > you want to add a new MAC-based algorithm. >=20 > People are going to end up needing to write new code every time they want > to add a new MAC-based algorithm. >=20 > Cheers, > Brian From eran@hueniverse.com Fri Dec 4 11:25:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07B83A67B0 for ; Fri, 4 Dec 2009 11:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.96 X-Spam-Level: X-Spam-Status: No, score=-2.96 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTrJJQ0Vsmfr for ; Fri, 4 Dec 2009 11:25:33 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BEC223A63EB for ; Fri, 4 Dec 2009 11:25:33 -0800 (PST) Received: (qmail 12000 invoked from network); 4 Dec 2009 19:25:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 19:25:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 12:25:23 -0700 From: Eran Hammer-Lahav To: Breno , Brian Eaton Date: Fri, 4 Dec 2009 12:25:41 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1FtROUoaBdtbWQqubEzFOF/ebagAAKLEQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723437852936D7P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:25:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723437852936D7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Point where? I didn't mean new spec for the algorithm, just for how it is used with the = OAuth authentication scheme. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 11:20 AM To: Brian Eaton Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto There is no need to publish a new spec for a new MAC algorithm. MAC algorit= hms typically go through certification (e.g., NIST) and have detailed specs= , including test vectors for interoperability. For OAuth, if you want to explicitly support a new MAC algorithm you will n= ot need to change the transport and you just have to point to the particula= r spec that defines the MAC algorithm. On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton > wrote: On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav > wrote: > I am trying to avoid the need to publish a specification every time you w= ant > to add a new MAC-based algorithm. People are going to end up needing to write new code every time they want to add a new MAC-based algorithm. Cheers, Brian -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E723437852936D7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Point whe= re?

 

I didn’t mean new spec for the algo= rithm, just for how it is used with the OAuth authentication scheme.

 

EHL

 

= From:= Breno [mailto:breno.demedeiros@gmail.com]
Sent: Friday, Decembe= r 04, 2009 11:20 AM
To: Brian Eaton
Cc: Eran Hammer-Lah= av; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Signature c= rypto

 

There is no need to publish a new spec for a new= MAC algorithm. MAC algorithms typically go through certification (e.g., NI= ST) and have detailed specs, including test vectors for interoperability.

 

For OAuth, if you want to e= xplicitly support a new MAC algorithm you will not need to change the trans= port and you just have to point to the particular spec that defines the MAC= algorithm.

On Fri, Dec 4, 2009 at = 11:12 AM, Brian Eaton <beaton@googl= e.com> wrote:

On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
&= gt; I am trying to avoid the need to publish a specification every time you= want
> to add a new MAC-based algorithm.

People are going to end up needing to write new code every ti= me they

want to add a new MAC-based algorithm.

Cheers,
Brian




--
Breno de Medeiros

= = --_000_90C41DD21FB7C64BB94121FBBC2E723437852936D7P3PW5EX1MB01E_-- From email@pbryan.net Fri Dec 4 11:30:01 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E3B3A67B0 for ; Fri, 4 Dec 2009 11:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaGh7WBbrDOu for ; Fri, 4 Dec 2009 11:30:00 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 8EAE53A63EB for ; Fri, 4 Dec 2009 11:30:00 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 2888DEA021; Fri, 4 Dec 2009 19:29:51 +0000 (UTC) From: "Paul C. Bryan" To: Brian Eaton In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785209782@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B0D5EE1.9000309@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852097FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124A7241F7@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Dec 2009 11:29:35 -0800 Message-ID: <1259954975.6142.566.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:30:02 -0000 +1 On Fri, 2009-12-04 at 10:37 -0800, Brian Eaton wrote: > I think OAuth 1.0 got this right. Just specify the signature > algorithm. That can cover HMAC-SHA1, HMAC-SHA256, ECC, RSA-SHA1, > RSA-SHA256, and whatever other fancy magic someone comes up with next > year. > > Cheers, > Brian > > On Fri, Dec 4, 2009 at 10:28 AM, Eran Hammer-Lahav wrote: > > It’s not really. > > > > > > > > We are talking about: > > > > > > > > 1. HMAC-specific: > > > > > > > > The server sends: > > > > > > > > methods=”HMAC:sha-1,sha-256” > > > > > > > > The client replies: > > > > > > > > method=”HMAC:sha-256” > > > > > > > > 2. MAC-generic: > > > > > > > > The server sends: > > > > > > > > methods=”MAC:hmac-sha1,hmac-sha256” > > > > > > > > The client replies: > > > > > > > > method=”MAC:hmac-sha256” > > > > > > > > Pick! > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:23 AM > > > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > There is no reason to make HMAC + hash a separate thing. > > > > > > > > It would make sense to define a way to specify a MAC, and to specify HMAC > > with SHA-1 you need only say HMAC-SHA1 as the algorithm name. > > > > > > > > This is pretty conventional. > > > > On Fri, Dec 4, 2009 at 10:21 AM, Eran Hammer-Lahav > > wrote: > > > > I was not suggesting to explicitly mention them, just allow them. > > > > > > > > Currently, I am proposing a HMAC option with the hash algorithm as a > > parameter. This would mean changing it to a MAC option with the MAC type and > > hash algorithm as parameters. > > > > > > > > It adds a bit more complexity but nothing significant. However, if there are > > no compelling reasons to do so (no actual use cases or requirements), I am > > more inclined to stick with HMAC and allow others to extend it by adding a > > new CMAC (etc.) method. > > > > > > > > EHL > > > > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > > Sent: Friday, December 04, 2009 10:17 AM > > To: Eran Hammer-Lahav > > Cc: Manger, James H; Stephen Farrell; OAuth WG (oauth@ietf.org) > > > > Subject: Re: [OAUTH-WG] Signature crypto > > > > > > > > While there are technical merits, both from security and performance > > standpoints, to the alternative MAC proposals, there is not extensive > > library support for those, and AFAIK they have little usage in the Internet. > > I am not sure if it makes sense for OAuth to be on the leading edge in terms > > of MAC algorithm adoption. > > > > On Fri, Dec 4, 2009 at 10:07 AM, Eran Hammer-Lahav > > wrote: > > > > Is there actual demand to make the HMAC method more generic to allow other > > kinds of MAC? > > > > EHL > > > >> -----Original Message----- > >> From: Manger, James H [mailto:James.H.Manger@team.telstra.com] > >> Sent: Thursday, November 26, 2009 7:43 PM > >> To: Eran Hammer-Lahav; Stephen Farrell > >> Cc: OAuth WG (oauth@ietf.org) > > > >> Subject: RE: [OAUTH-WG] Signature crypto > >> > >> >> Sounds reasonable if all you need to negotiate are hash algorithm > >> >> names. > >> >> Is that the case? > >> > >> > Yes. > >> > >> Not quite. > >> OAuth (at least the authentication part) mainly needs a MAC algorithm, not > >> a > >> hash algorithm. > >> HMAC is one popular MAC algorithm that is build from a hash algorithm. > >> However, there are other MAC algorithms — based on block ciphers for > >> instance (eg CMAC-AES). > >> The hash registry http://www.iana.org/assignments/hash-function-text- > >> names/ is not really going to help. > >> > >> P.S. The body-signing OAuth extension is the one place that uses a hash > >> (not > >> a MAC) directly. > >> > >> James Manger > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > > Breno de Medeiros > > > > > > -- > > Breno de Medeiros > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stephen.farrell@cs.tcd.ie Fri Dec 4 11:44:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 302873A67FD for ; Fri, 4 Dec 2009 11:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLR9RHpb+lvS for ; Fri, 4 Dec 2009 11:44:30 -0800 (PST) Received: from cs.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 0E7A13A672E for ; Fri, 4 Dec 2009 11:44:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7D5E73E408B; Fri, 4 Dec 2009 19:44:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:mime-version:user-agent :reply-to:from:subject:date:references:in-reply-to:message-id :received:received:received:x-virus-scanned; s=cs; t=1259955859; bh=Pn2ymrqm4Nfa0QYhyfOdEZg1qYm/GymabikRJVnN4I4=; b=DalFNpDy9Evz MEfXLLglSAJjLIPxJVO2P055SvvENzpyYnZt7+GQi5tHPh6t0EL2lyklKPIfwAp3 WSS44VcufXDay82ZPcGTTlLBseAsST7bA1flFPJvDczb/kUtJYic78gEy3/U1dMG s4gRi+ZuDDA/5/CRmgrc39HYQOiDFQqnFUUHL2U4S04ohmx6GXoeUos2IIw3o32G Ps6ZjlygU85sl8B1pfCQL93CQED0x8Qw/V/3IEVvIXQu8YaNVV/nQ2atXX3dh9Qu vNmnXS8xnyiMDaUPZDJoFnpZMPSo5ZB01DsdYaZR6cqX51vBYEvIgvqPbQjnAz+J fqs5wrhuNw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from cs.tcd.ie ([127.0.0.1]) by localhost (hermes.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id DteGtAYJVZHx; Fri, 4 Dec 2009 19:44:19 +0000 (GMT) Received: from webmail.scss.tcd.ie (localhost [127.0.0.1]) by smtp.scss.tcd.ie (Postfix) with ESMTP id 8F1753E4084; Fri, 4 Dec 2009 19:44:19 +0000 (GMT) Received: from 87.232.102.234 (SquirrelMail authenticated user sfarrel6) by webmail.scss.tcd.ie with HTTP; Fri, 4 Dec 2009 19:44:19 -0000 (GMT) Message-ID: In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852936D4@P3PW5EX1MB01.EX1.SECURESER VER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293671@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293683@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 19:44:19 -0000 (GMT) From: stephen.farrell@cs.tcd.ie To: "Eran Hammer-Lahav" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 04 Dec 2009 11:45:43 -0800 Cc: "OAuth WG " "@cs.tcd.ie Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stephen.farrell@cs.tcd.ie List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:44:31 -0000 I think the +1's for HMAC-SHA1 etc should be followed here. Attempting to reflect the internals of a signature or MACing scheme in this protocol would be a mistake. > Are you expecting them to write a new RFC to add support for HMAC-1024? Yes. (Not that such a beast would make much sense.) > That's the implications of what you are suggesting. Instead, I am trying > to define a few (1 or 2) classes of algorithms, provide well-defined > process of them, and provide an easy registration process for new > algorithms which fit the class. No thanks. I'd rather not see HMAC-snakeoil widely deployed. > ...asymmetric shared secret ... Excellent example. That's precisely why we want an RFC and a proper review process. S. From breno.demedeiros@gmail.com Fri Dec 4 11:46:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77ED93A67D8 for ; Fri, 4 Dec 2009 11:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS6cOPTgX9rv for ; Fri, 4 Dec 2009 11:46:33 -0800 (PST) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 5133D3A6A4D for ; Fri, 4 Dec 2009 11:46:33 -0800 (PST) Received: by ywh1 with SMTP id 1so3106550ywh.18 for ; Fri, 04 Dec 2009 11:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LSLUWxaf+IR9muXsr7vIbLPshHBYHud7kmj+XLOR6iA=; b=ezw8s5mut5JvEcdJHLRJz+yly/FsA6If+OH/zT2IuoZxOvi0CIa9CHZmQVzIbAnNiB 3g+fIifLA+1H3acQQB6I8xXpC38xPAl0TK/9gaAtJ8SETXUeS4TVlrqs1o3ennx9dRvd BBS2Ji98LnV6PTfwYJmECcJkEtoVIxMPY/IhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ftaJlcDcZxsxwG1bqjRRsFtdH5jJcUVRqSxSjqE+X7jOD30EcRPi1B0kw5F8PaGtvz DthuuSdtkRA/OvqR9a0K0YHr1Mnqm3bfdfBISHM/9B9NqI1foZ48MdKzur7jGoP2/faz oo3z5qSRCwPQGk6OLLiKvlUso4J0jyN52mNL0= MIME-Version: 1.0 Received: by 10.101.62.11 with SMTP id p11mr4610071ank.21.1259955981793; Fri, 04 Dec 2009 11:46:21 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 11:46:21 -0800 Message-ID: From: Breno To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=001636eee42dba39c00479ec5c9f Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 19:46:34 -0000 --001636eee42dba39c00479ec5c9f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am not sure I buy this. For instance, RSA-SHA1 is _not_ a signature scheme, PKCS#11 does establish a signature scheme based on RSA + SHA-1. So to delve beyond the level of abstraction of 'authentication mechanism name' you need to point to a separate spec for both signing and verification. I am not sure how much one needs to do beyond defining the byte representation of what needs to be signed. Some MACs require random pads in addition to keys. Those won't fit into thi= s abstraction but I don't think we need absolute generality here. On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav wro= te: > Point where? > > > > I didn=92t mean new spec for the algorithm, just for how it is used with = the > OAuth authentication scheme. > > > > EHL > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Friday, December 04, 2009 11:20 AM > *To:* Brian Eaton > *Cc:* Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] Signature crypto > > > > There is no need to publish a new spec for a new MAC algorithm. MAC > algorithms typically go through certification (e.g., NIST) and have detai= led > specs, including test vectors for interoperability. > > > > For OAuth, if you want to explicitly support a new MAC algorithm you will > not need to change the transport and you just have to point to the > particular spec that defines the MAC algorithm. > > On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton wrote: > > On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav > wrote: > > I am trying to avoid the need to publish a specification every time you > want > > to add a new MAC-based algorithm. > > People are going to end up needing to write new code every time they > > want to add a new MAC-based algorithm. > > Cheers, > Brian > > > > > -- > Breno de Medeiros > --=20 Breno de Medeiros --001636eee42dba39c00479ec5c9f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am not sure I buy this. For instance, RSA-SHA1 is _not_ a signature schem= e, PKCS#11 does establish a signature scheme based on RSA + SHA-1.

=
So to delve beyond the level of abstraction of 'authenticati= on mechanism name' you need to point to a separate spec for both signin= g and verification.

I am not sure how much one needs to do beyond defining = the byte representation of what needs to be signed.

Some MACs require random pads in addition to keys. Those won't fit in= to this abstraction but I don't think we need absolute generality here.=

On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer= -Lahav <eran@hu= eniverse.com> wrote:

Point where?

<= p class=3D"MsoNormal">=A0

I didn=92t mean new spec for= the algorithm, just for how it is used with the OAuth authentication schem= e.

=A0

EHL

=A0

Fr= om: Breno [mailto:breno.demedeiros@gmail.c= om]
Sent: Friday, December 04, 2009 11:20 AM
To: Brian EatonCc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)


S= ubject: Re: [OAUTH-WG] Signature crypto

=A0

The= re is no need to publish a new spec for a new MAC algorithm. MAC algorithms= typically go through certification (e.g., NIST) and have detailed specs, i= ncluding test vectors for interoperability.

=A0

=

For OAuth, if yo= u want to explicitly support a new MAC algorithm you will not need to chang= e the transport and you just have to point to the particular spec that defi= nes the MAC algorithm.

On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton &l= t;beaton@google.com<= /a>> wrote:

On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: > I am trying to avoid the need to publish a specification every time yo= u want
> to add a new MAC-based algorithm.

People are going to end up needing to write new code every time they<= /p>

want to add a ne= w MAC-based algorithm.

Cheers,
Brian




--
Breno de Medeiros




--
Breno de= Medeiros

--001636eee42dba39c00479ec5c9f-- From eran@hueniverse.com Fri Dec 4 12:35:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25FBE3A69D3 for ; Fri, 4 Dec 2009 12:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.956 X-Spam-Level: X-Spam-Status: No, score=-2.956 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2xbwRrdZbDN for ; Fri, 4 Dec 2009 12:35:12 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id CBCE03A68FD for ; Fri, 4 Dec 2009 12:35:12 -0800 (PST) Received: (qmail 11829 invoked from network); 4 Dec 2009 20:35:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 20:35:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 13:35:03 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Fri, 4 Dec 2009 13:35:21 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1GnWoZAY5dSS+QcK0eFBSsffPuwAA/MdQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293745@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785293745P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 20:35:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785293745P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have been to some extent talking part each other. Breno and I spend some= time talking about this off line and reached a better understanding of our= positions. We have been approaching this from the wrong direction. The server should not be broadcasting what types of algorithms it supports.= Instead it should be listing what kind of *tokens* it supports. Since a to= ken secret issued for use with HMAC-SHA1 should/may be different from that = used with HMAC-SHA512, it is the token class that determines what it can be= used with. The server should indicate the kinds of tokens supported for a given resour= ce/realm. When obtaining such tokens, the client will be provided with a ne= w attribute indicating the token type (which will dictate how it should use= it to sign/etc. the canonicalized request.). The server should indicate in the WWW-Authenticate header which canonicaliz= ations it supports (with bearer token being a special case). The authentication scheme should specify how to take the raw signature and = encode it into the Authentication header. This means *are* going to pick a few token types to standardize which will = include the crypto used, and allow extensions by publishing an RFC + regist= ration. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 11:46 AM To: Eran Hammer-Lahav Cc: Brian Eaton; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto I am not sure I buy this. For instance, RSA-SHA1 is _not_ a signature schem= e, PKCS#11 does establish a signature scheme based on RSA + SHA-1. So to delve beyond the level of abstraction of 'authentication mechanism na= me' you need to point to a separate spec for both signing and verification. I am not sure how much one needs to do beyond defining the byte representat= ion of what needs to be signed. Some MACs require random pads in addition to keys. Those won't fit into thi= s abstraction but I don't think we need absolute generality here. On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav > wrote: Point where? I didn't mean new spec for the algorithm, just for how it is used with the = OAuth authentication scheme. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 11:20 AM To: Brian Eaton Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto There is no need to publish a new spec for a new MAC algorithm. MAC algorit= hms typically go through certification (e.g., NIST) and have detailed specs= , including test vectors for interoperability. For OAuth, if you want to explicitly support a new MAC algorithm you will n= ot need to change the transport and you just have to point to the particula= r spec that defines the MAC algorithm. On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton > wrote: On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav > wrote: > I am trying to avoid the need to publish a specification every time you w= ant > to add a new MAC-based algorithm. People are going to end up needing to write new code every time they want to add a new MAC-based algorithm. Cheers, Brian -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E72343785293745P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have b= een to some extent talking part each other. Breno and I spend some time tal= king about this off line and reached a better understanding of our position= s.

 

We have been approaching this from the wro= ng direction.

 <= /o:p>

The server should not be broadc= asting what types of algorithms it supports. Instead it should be listing w= hat kind of *tokens* it supports. Since a token secret issued for us= e with HMAC-SHA1 should/may be different from that used with HMAC-SHA512, i= t is the token class that determines what it can be used with.

 

The server should indicate the kinds of tokens supporte= d for a given resource/realm. When obtaining such tokens, the client will b= e provided with a new attribute indicating the token type (which will dicta= te how it should use it to sign/etc. the canonicalized request.).

 

The server should indicate in the WWW-Authenticate hea= der which canonicalizations it supports (with bearer token being a special = case).

 

The authentication scheme should speci= fy how to take the raw signature and encode it into the Authentication head= er.

 

This means *are* going to pick a f= ew token types to standardize which will include the crypto used, and allow= extensions by publishing an RFC + registration.

 

EHL

 <= /span>

 

 

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = Breno [mailto:breno.demedeiros@gmail.com]
Sent: Friday, December= 04, 2009 11:46 AM
To: Eran Hammer-Lahav
Cc: Brian Eato= n; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Signature cr= ypto

 

I am not sure I buy this. For instance, RSA-SHA1 = is _not_ a signature scheme, PKCS#11 does establish a signature scheme base= d on RSA + SHA-1.

 =

So to delve beyond the level of abstrac= tion of 'authentication mechanism name' you need to point to a separate spe= c for both signing and verification.

 

I am not sure = how much one needs to do beyond defining the byte representation of what ne= eds to be signed.

 =

So= me MACs require random pads in addition to keys. Those won't fit into this = abstraction but I don't think we need absolute generality here.<= /p>

On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-L= ahav <eran@hueniverse.com>= wrote:

Point where?

 

I didn’t mean new spec for the algorit= hm, just for how it is used with the OAuth authentication scheme.

 

EH= L

 

From: Breno = [mailto:bre= no.demedeiros@gmail.com]
Sent: Friday, December 04, 2009 11:= 20 AM
To: Brian Eaton
Cc: Eran Hammer-Lahav; OAuth WG (= oauth@ietf.org)


Subject: Re: [OAUTH-= WG] Signature crypto

 

There is no need to publish a new spec for a new MAC algorithm= . MAC algorithms typically go through certification (e.g., NIST) and have d= etailed specs, including test vectors for interoperability.

<= div>

 

For OAuth, if you wan= t to explicitly support a new MAC algorithm you will not need to change the= transport and you just have to point to the particular spec that defines t= he MAC algorithm.

On Fri, Dec 4, 2009 at 11:12 AM= , Brian Eaton <be= aton@google.com> wrote:

On Fri, Dec 4, 2009 at 1= 1:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I am trying to avoi= d the need to publish a specification every time you want
> to add a = new MAC-based algorithm.

People are going to end= up needing to write new code every time they

want to= add a new MAC-based algorithm.

Cheers,
Brian




--
Breno de Medeiros




--
Breno de Medeiros

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785293745P3PW5EX1MB01E_-- From eran@hueniverse.com Fri Dec 4 12:36:36 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25E03A68FD for ; Fri, 4 Dec 2009 12:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tzQwZ2SuFBA for ; Fri, 4 Dec 2009 12:36:30 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E45CB3A6910 for ; Fri, 4 Dec 2009 12:36:29 -0800 (PST) Received: (qmail 12615 invoked from network); 4 Dec 2009 20:36:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 20:36:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 13:36:21 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Fri, 4 Dec 2009 13:36:38 -0700 Thread-Topic: [OAUTH-WG] Signature crypto Thread-Index: Acp1GnWoZAY5dSS+QcK0eFBSsffPuwAA/MdQAAC8B7A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293747@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293745@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293745@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785293747P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 20:36:36 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785293747P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And if it is not clear, this is very different from 1.0 in which the signat= ure method includes what is being signed as well as how to normalize the ou= tput into the authenticated request. This separates the how to sign with wh= at to sign and gives each a name. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, December 04, 2009 12:35 PM To: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto We have been to some extent talking part each other. Breno and I spend some= time talking about this off line and reached a better understanding of our= positions. We have been approaching this from the wrong direction. The server should not be broadcasting what types of algorithms it supports.= Instead it should be listing what kind of *tokens* it supports. Since a to= ken secret issued for use with HMAC-SHA1 should/may be different from that = used with HMAC-SHA512, it is the token class that determines what it can be= used with. The server should indicate the kinds of tokens supported for a given resour= ce/realm. When obtaining such tokens, the client will be provided with a ne= w attribute indicating the token type (which will dictate how it should use= it to sign/etc. the canonicalized request.). The server should indicate in the WWW-Authenticate header which canonicaliz= ations it supports (with bearer token being a special case). The authentication scheme should specify how to take the raw signature and = encode it into the Authentication header. This means *are* going to pick a few token types to standardize which will = include the crypto used, and allow extensions by publishing an RFC + regist= ration. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 11:46 AM To: Eran Hammer-Lahav Cc: Brian Eaton; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto I am not sure I buy this. For instance, RSA-SHA1 is _not_ a signature schem= e, PKCS#11 does establish a signature scheme based on RSA + SHA-1. So to delve beyond the level of abstraction of 'authentication mechanism na= me' you need to point to a separate spec for both signing and verification. I am not sure how much one needs to do beyond defining the byte representat= ion of what needs to be signed. Some MACs require random pads in addition to keys. Those won't fit into thi= s abstraction but I don't think we need absolute generality here. On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav > wrote: Point where? I didn't mean new spec for the algorithm, just for how it is used with the = OAuth authentication scheme. EHL From: Breno [mailto:breno.demedeiros@gmail.com] Sent: Friday, December 04, 2009 11:20 AM To: Brian Eaton Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Signature crypto There is no need to publish a new spec for a new MAC algorithm. MAC algorit= hms typically go through certification (e.g., NIST) and have detailed specs= , including test vectors for interoperability. For OAuth, if you want to explicitly support a new MAC algorithm you will n= ot need to change the transport and you just have to point to the particula= r spec that defines the MAC algorithm. On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton > wrote: On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav > wrote: > I am trying to avoid the need to publish a specification every time you w= ant > to add a new MAC-based algorithm. People are going to end up needing to write new code every time they want to add a new MAC-based algorithm. Cheers, Brian -- Breno de Medeiros -- Breno de Medeiros --_000_90C41DD21FB7C64BB94121FBBC2E72343785293747P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And if it= is not clear, this is very different from 1.0 in which the signature metho= d includes what is being signed as well as how to normalize the output into= the authenticated request. This separates the how to sign with what to sig= n and gives each a name.

<= o:p> 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounce= s@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Friday, D= ecember 04, 2009 12:35 PM
To: OAuth WG (oauth@ietf.org)
Sub= ject: Re: [OAUTH-WG] Signature crypto

=

 

We h= ave been to some extent talking part each other. Breno and I spend some tim= e talking about this off line and reached a better understanding of our pos= itions.

 <= /span>

We have been approaching this from th= e wrong direction.

&n= bsp;

The server should not be b= roadcasting what types of algorithms it supports. Instead it should be list= ing what kind of *tokens* it supports. Since a token secret issued f= or use with HMAC-SHA1 should/may be different from that used with HMAC-SHA5= 12, it is the token class that determines what it can be used with.

 

The server should indicate the kinds of tokens suppo= rted for a given resource/realm. When obtaining such tokens, the client wil= l be provided with a new attribute indicating the token type (which will di= ctate how it should use it to sign/etc. the canonicalized request.).

 

The server should indicate in the WWW-Authenticate = header which canonicalizations it supports (with bearer token being a speci= al case).

 

The authentication scheme should sp= ecify how to take the raw signature and encode it into the Authentication h= eader.

 

This means *are* going to pick = a few token types to standardize which will include the crypto used, and al= low extensions by publishing an RFC + registration.

 

= EHL

 

 

 

 

From: Breno [mailto:breno.demedeiros@gmail.com]
Sent: Friday, Decemb= er 04, 2009 11:46 AM
To: Eran Hammer-Lahav
Cc: Brian Ea= ton; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Signature = crypto

 

I am not sure I buy this. For instance, RSA-SHA= 1 is _not_ a signature scheme, PKCS#11 does establish a signature scheme ba= sed on RSA + SHA-1.

 

So to delve beyond the level of abstr= action of 'authentication mechanism name' you need to point to a separate s= pec for both signing and verification.

 

I am not sur= e how much one needs to do beyond defining the byte representation of what = needs to be signed.

&nbs= p;

= Some MACs require random pads in addition to keys. Those won't fit into thi= s abstraction but I don't think we need absolute generality here.

On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer= -Lahav <eran@hueniverse.com&g= t; wrote:

Point where?

 

I didn’t mean new spec for the al= gorithm, just for how it is used with the OAuth authentication scheme.

&nbs= p;

EHL

 

From: B= reno [mailto:breno.demedeiros@gmail.com]
Sent: Friday, December 04, 200= 9 11:20 AM
To: Brian Eaton
Cc: Eran Hammer-Lahav; OAuth= WG (oauth@ietf.org= )


Subject: Re: [O= AUTH-WG] Signature crypto

 

There is no need to publish a new spec for a new MAC algo= rithm. MAC algorithms typically go through certification (e.g., NIST) and h= ave detailed specs, including test vectors for interoperability.=

 

For OAuth, if yo= u want to explicitly support a new MAC algorithm you will not need to chang= e the transport and you just have to point to the particular spec that defi= nes the MAC algorithm.

On Fri, Dec 4, 2009 at 11:= 12 AM, Brian Eaton <beaton@google.com> wrote:

On Fri, Dec 4, 2009= at 11:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I am trying to= avoid the need to publish a specification every time you want
> to a= dd a new MAC-based algorithm.

People are going t= o end up needing to write new code every time they

want= to add a new MAC-based algorithm.

Cheers,
Brian




--
Breno de Medeiros

<= /div>



--
Breno de Medeiros

=
= --_000_90C41DD21FB7C64BB94121FBBC2E72343785293747P3PW5EX1MB01E_-- From beaton@google.com Fri Dec 4 13:51:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA0B3A68AE for ; Fri, 4 Dec 2009 13:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRTQqqXngq6V for ; Fri, 4 Dec 2009 13:51:50 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 076EB3A6891 for ; Fri, 4 Dec 2009 13:51:50 -0800 (PST) Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id nB4LpeHi006173 for ; Fri, 4 Dec 2009 13:51:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259963500; bh=GWPXxQ+7cqfgThvlqlXW2AHNCIg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=PlDpQPw/T/rbIZXOuCvsL/+PNMzpi3sD0bkkeXUk/6dKilW+V5FTLMpAwe9e9WEOC nNnXemzf8VDgLVotPMMMA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=jrMyjIy6r8yaiiZ4B5j3RjY82l7/zG4tW3z3VbWFq6lsHeSWorwU3BOrS4MQ/1CXv cLFb8ZA+DJSR3ooyQeqjg== Received: from pwi19 (pwi19.prod.google.com [10.241.219.19]) by zps77.corp.google.com with ESMTP id nB4LpUYM014414 for ; Fri, 4 Dec 2009 13:51:38 -0800 Received: by pwi19 with SMTP id 19so424322pwi.35 for ; Fri, 04 Dec 2009 13:51:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.202.20 with SMTP id z20mr213780rvf.28.1259963498285; Fri, 04 Dec 2009 13:51:38 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 13:51:38 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 21:51:51 -0000 On Thu, Dec 3, 2009 at 12:01 AM, Eran Hammer-Lahav wrote: > While access to the raw HTTP request body is often hard to obtain (due to use of streams, protocol layers, etc.) for the purpose of generating a body hash, > is it reasonable to expect the client and server to have access to the raw body when sending a form-encoded body request? No. There are common platforms where getting access to the raw HTTP request body requires major surgery. For example: HTTP proxies typically stream bodies, asking them to hold it all in memory doesn't scale. Another example: application frameworks typically handle things like request normalization and validation early on in request processing. By the time you get to the point of doing authentication and authorization on requests, the raw bytes of the body are gone. The OAuth body signing extension was arranged in such a way that server-side validation of the request body was optional, you can validate the rest of the request even if you don't have access to the body. That's pretty important. Cheers, Brian From eran@hueniverse.com Fri Dec 4 14:01:17 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0193A6891 for ; Fri, 4 Dec 2009 14:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt6rCMB9xYpW for ; Fri, 4 Dec 2009 14:01:16 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 216F83A63C9 for ; Fri, 4 Dec 2009 14:01:15 -0800 (PST) Received: (qmail 19290 invoked from network); 4 Dec 2009 22:01:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 22:01:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 4 Dec 2009 15:00:55 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 4 Dec 2009 15:01:13 -0700 Thread-Topic: [OAUTH-WG] Access to raw HTTP request body Thread-Index: Acp1K/kR84GO/mV5QkKgBZisgA/8wAAAJMuA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852937B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:01:17 -0000 You might be missing my question. I am asking specifically about form-encod= ed bodies. If it is not clear what I am getting at: I would like to have a single way = to sign the request body based on the body hash proposal. I want to apply t= his to form-encoded bodies as well and drop the need to parse and normalize= form-encoded bodies. So my question is, while I know it is often hard to get access to the raw b= ody, in cases when it is *form-encoded* is it still hard or is the client/s= erver able to access it given it is a simple (single) string. Even if you c= an't get access to the *actual* body, you should be able to figure it out f= rom other data. Is this a reasonable expectation? Why is this important? Because if we can do this, we can drop all the param= eter decoding/sorting/encoding/etc. dance and just take the raw HTTP reques= t URI, the request method, host, and port, and a hash of the body. Put them= together CRLF separated and sign it. So please tell me we can do that... :-) EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, December 04, 2009 1:52 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Access to raw HTTP request body >=20 > On Thu, Dec 3, 2009 at 12:01 AM, Eran Hammer-Lahav > wrote: > > While access to the raw HTTP request body is often hard to obtain (due > > to use of streams, protocol layers, etc.) for the purpose of generating= a > body hash, is it reasonable to expect the client and server to have acces= s to > the raw body when sending a form-encoded body request? >=20 > No. There are common platforms where getting access to the raw HTTP > request body requires major surgery. >=20 > For example: HTTP proxies typically stream bodies, asking them to hold it= all > in memory doesn't scale. >=20 > Another example: application frameworks typically handle things like requ= est > normalization and validation early on in request processing. > By the time you get to the point of doing authentication and authorizatio= n on > requests, the raw bytes of the body are gone. >=20 > The OAuth body signing extension was arranged in such a way that server- > side validation of the request body was optional, you can validate the re= st of > the request even if you don't have access to the body. That's pretty > important. >=20 > Cheers, > Brian From eran@hueniverse.com Fri Dec 4 14:34:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1523A6927 for ; Fri, 4 Dec 2009 14:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.946 X-Spam-Level: X-Spam-Status: No, score=-2.946 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4Ce15Yx47Jm for ; Fri, 4 Dec 2009 14:34:09 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8496C3A6359 for ; Fri, 4 Dec 2009 14:34:09 -0800 (PST) Received: (qmail 1514 invoked from network); 4 Dec 2009 22:33:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 22:33:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 15:33:57 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Fri, 4 Dec 2009 15:34:16 -0700 Thread-Topic: Core Token Classes Thread-Index: Acp1Melx87+ToVYvQg6hhsgZ58KtLA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852937D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Core Token Classes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:34:10 -0000 The proposed authentication scheme switches to use token classes instead of= signature methods. Instead of the server supporting certain kinds of signa= ture methods, the server supports certain kind of token classes. When clien= ts obtain tokens from the server, they are told what the class of the token= is, and what realm it is for (we still need to work out realm scoping deta= ils). Discovery (of some sort) will connect the two parts and tell the client how= to get a token of a certain class from the server. This brings us to the core token classes to be included in the Token scheme= specification. Others will require an RFC (or Open Standard) and a registr= ation. I am proposing the following core set: -- hmac-sha-1 Token is issued with a symmetric secret appropriate for use with the HMAC-S= HA-1 algorithm over a normalized representation of the HTTP request. -- hmac-sha-256 Token is issued with a symmetric secret appropriate for use with the HMAC-S= HA-256 algorithm over a normalized representation of the HTTP request. -- rsassa-pkcs1-v1.5-sha-256 Token is associated with PK appropriate for use with the RSASSA-PKCS1-v1.5 = method using the SHA-256 hash algorithm over a normalized representation of= the HTTP request. The client will have access to the private key while the= server will have access to the public key. -- basic-hmac-sha-1 A special case token which allows using Basic Authentication credentials (u= sername and password) as an hmac-sha-1 class token. The password will be us= ed as the symmetric shared secret. This token class is assigned a special n= ame to reflect the source of the credentials and make it trivial to deploy = as a direct replacement for Basic Auth. -- bearer-opaque A secret-less token class using an opaque string. The 'opaque' label is use= d to indicate that this is a server-issued token with a structure unknown t= o the client. I expect other bearer token classes to be defined later to al= low the client or other entities to self-issue a token (for example, a SWT = token can be called bearer-swt). Comments? EHL From beaton@google.com Fri Dec 4 14:35:50 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEC33A68AE for ; Fri, 4 Dec 2009 14:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJQeY366c5GO for ; Fri, 4 Dec 2009 14:35:49 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 6FF823A6862 for ; Fri, 4 Dec 2009 14:35:49 -0800 (PST) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id nB4MZepq028309 for ; Fri, 4 Dec 2009 14:35:40 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259966140; bh=u1YoFjw9Kw1ZK/tSy93wEWF+KWM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Dhta+rKNJW7EW8iGn9TRiKp8mdiWsRtY0K6if+7ySEqENthDUwN174o+SCkSN1Wgq acm9HpPjXY85tF1s/Lynw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=fLTeFfo+H32BdKEQ3UuQ9cnA/XU7eecGZ+6MsLfNYyn84jM8cSL13JIqw1iVNIZl0 Chh4hmIkxiHj0SciycYJQ== Received: from pwi18 (pwi18.prod.google.com [10.241.219.18]) by zps38.corp.google.com with ESMTP id nB4MZONA009914 for ; Fri, 4 Dec 2009 14:35:38 -0800 Received: by pwi18 with SMTP id 18so1369276pwi.4 for ; Fri, 04 Dec 2009 14:35:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.141.18 with SMTP id o18mr253699rvd.269.1259964435963; Fri, 04 Dec 2009 14:07:15 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852937B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 14:07:15 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:35:50 -0000 On Fri, Dec 4, 2009 at 2:01 PM, Eran Hammer-Lahav wrote: > You might be missing my question. I am asking specifically about form-encoded bodies. Yep, I follow. There are some differences between getting access to form-encoded vs non-form-encoded request bodies, but I think in practice it's difficult no matter what. There are a significant number of organizations that don't offer any OAuth protected form-encoded APIs, because their authentication code doesn't have access to any portion of the request body. > If it is not clear what I am getting at: I would like to have a single way to sign > the request body based on the body hash proposal. I want to apply this to > form-encoded bodies as well and drop the need to parse and normalize > form-encoded bodies. I love this idea, but we should understand that most organizations won't end up validating the body authentication. I suspect that's true for both form-encoded and non-form-encoded requests. The issue isn't really the encoding. It's where authentication plugs in to request processing. Cheers, Brian From eran@hueniverse.com Fri Dec 4 14:38:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E124D3A6A74 for ; Fri, 4 Dec 2009 14:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqmsJ+2LJOhJ for ; Fri, 4 Dec 2009 14:38:15 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E37863A6A72 for ; Fri, 4 Dec 2009 14:38:14 -0800 (PST) Received: (qmail 5995 invoked from network); 4 Dec 2009 22:38:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 22:38:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 4 Dec 2009 15:38:01 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 4 Dec 2009 15:38:18 -0700 Thread-Topic: [OAUTH-WG] Access to raw HTTP request body Thread-Index: Acp1Lid7ytTEgmCTSaCYzWu2llYERwAA+UOw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852937D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:38:16 -0000 You seem to validate my approach. If it is equally hard to peek into the bo= dy for form-encoded or otherwise, and the approach implementers are taking = is to simply not support any form-encoded parameters in their API, we might= as well remove this special case. Are there cases where form-encoded bodies change after set by the client (i= n a lower layer)? Or where the server might have access to the processed fo= rm-encoded parameters but not the original encoded body string? EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, December 04, 2009 2:07 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Access to raw HTTP request body >=20 > On Fri, Dec 4, 2009 at 2:01 PM, Eran Hammer-Lahav > wrote: > > You might be missing my question. I am asking specifically about form- > encoded bodies. >=20 > Yep, I follow. >=20 > There are some differences between getting access to form-encoded vs > non-form-encoded request bodies, but I think in practice it's difficult n= o > matter what. >=20 > There are a significant number of organizations that don't offer any OAut= h > protected form-encoded APIs, because their authentication code doesn't > have access to any portion of the request body. >=20 > > If it is not clear what I am getting at: I would like to have a single > > way to sign the request body based on the body hash proposal. I want > > to apply this to form-encoded bodies as well and drop the need to > > parse and normalize form-encoded bodies. >=20 > I love this idea, but we should understand that most organizations won't = end > up validating the body authentication. I suspect that's true for both fo= rm- > encoded and non-form-encoded requests. The issue isn't really the > encoding. It's where authentication plugs in to request processing. >=20 > Cheers, > Brian From beaton@google.com Fri Dec 4 14:54:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3283A6A6D for ; Fri, 4 Dec 2009 14:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK6jhC3J9JKJ for ; Fri, 4 Dec 2009 14:53:59 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 3859C3A6A0C for ; Fri, 4 Dec 2009 14:53:59 -0800 (PST) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id nB4MrmV1010126 for ; Fri, 4 Dec 2009 22:53:48 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1259967229; bh=WZwAil2dl4MuQjs9ZamrFUdHCtI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=S/+6CN+1FXBITlmslV+GgbqMfEQpRCXZpmrItNhOO2Ibr2P6kZUjsHEYZ5F7dAOx6 +Oru1/ZE4nmMLR4AvXgBQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=bEtpbEOwBQPMcJ0fM6kXEtm3EGIEiQRQqjPVmnYpjSNlFkNXR0C96QyFGdd2g4Z/g uR9TMJBqlgR7KDTrIZm5A== Received: from pwj15 (pwj15.prod.google.com [10.241.219.79]) by zps76.corp.google.com with ESMTP id nB4Mr0KY018185 for ; Fri, 4 Dec 2009 14:53:46 -0800 Received: by pwj15 with SMTP id 15so2544336pwj.3 for ; Fri, 04 Dec 2009 14:53:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.15.16 with SMTP id s16mr243575rvi.22.1259966913493; Fri, 04 Dec 2009 14:48:33 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852937D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Fri, 4 Dec 2009 14:48:32 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:54:00 -0000 On Fri, Dec 4, 2009 at 2:38 PM, Eran Hammer-Lahav wrote: > Are there cases where form-encoded bodies change after set by the client (in a lower layer)? I think it depends on the client. Most of the client code I've looked at assumes that authentication happens with (surprise surprise) bearer tokens. It's a real pain for client authors to move that code around. > Or where the server might have access to the processed form-encoded parameters but not the original encoded body string? This definitely happens, it's how the vanilla java servlet API works. I think the same is true of django. Cheers, Brian From eran@hueniverse.com Fri Dec 4 14:55:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0833A682E for ; Fri, 4 Dec 2009 14:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7D+IV2kICKR for ; Fri, 4 Dec 2009 14:55:47 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4EEC03A6829 for ; Fri, 4 Dec 2009 14:55:47 -0800 (PST) Received: (qmail 11752 invoked from network); 4 Dec 2009 22:55:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Dec 2009 22:55:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 4 Dec 2009 15:55:38 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Fri, 4 Dec 2009 15:55:56 -0700 Thread-Topic: [OAUTH-WG] Access to raw HTTP request body Thread-Index: Acp1M+uyNnDFLv8aSi+uoTK8vsi8zAAAJMDA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852937E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 22:55:48 -0000 Let me try this another way (this is not aimed at Brian specifically): Is my proposal of signing the form-encoded body as an opaque string instead= of parsing its content going to exclude *existing* use case supported by O= Auth 1.0? I am not asking for theories or guesses but actual deployment exp= erience to show this is not a good idea. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Friday, December 04, 2009 2:49 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Access to raw HTTP request body >=20 > On Fri, Dec 4, 2009 at 2:38 PM, Eran Hammer-Lahav > wrote: > > Are there cases where form-encoded bodies change after set by the clien= t > (in a lower layer)? >=20 > I think it depends on the client. Most of the client code I've looked at > assumes that authentication happens with (surprise surprise) bearer token= s. > It's a real pain for client authors to move that code around. >=20 > > Or where the server might have access to the processed form-encoded > parameters but not the original encoded body string? >=20 > This definitely happens, it's how the vanilla java servlet API works. > I think the same is true of django. >=20 > Cheers, > Brian From eran@hueniverse.com Fri Dec 4 16:26:13 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E76128C129 for ; Fri, 4 Dec 2009 16:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.937 X-Spam-Level: X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGmqTZT9BSyr for ; Fri, 4 Dec 2009 16:26:12 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5039428C126 for ; Fri, 4 Dec 2009 16:26:12 -0800 (PST) Received: (qmail 19282 invoked from network); 5 Dec 2009 00:26:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Dec 2009 00:26:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 4 Dec 2009 17:26:02 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Fri, 4 Dec 2009 17:26:21 -0700 Thread-Topic: Core Token Classes Thread-Index: Acp1Melx87+ToVYvQg6hhsgZ58KtLAAD5kZg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293803@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852937D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852937D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Core Token Classes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 00:26:13 -0000 Please ignore basic-hmac-sha-1. It was poorly conceived. I'll come back wit= h something better. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Friday, December 04, 2009 2:34 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Core Token Classes >=20 > The proposed authentication scheme switches to use token classes instead > of signature methods. Instead of the server supporting certain kinds of > signature methods, the server supports certain kind of token classes. Whe= n > clients obtain tokens from the server, they are told what the class of th= e > token is, and what realm it is for (we still need to work out realm scopi= ng > details). >=20 > Discovery (of some sort) will connect the two parts and tell the client h= ow to > get a token of a certain class from the server. >=20 > This brings us to the core token classes to be included in the Token sche= me > specification. Others will require an RFC (or Open Standard) and a > registration. >=20 > I am proposing the following core set: >=20 > -- hmac-sha-1 >=20 > Token is issued with a symmetric secret appropriate for use with the HMAC= - > SHA-1 algorithm over a normalized representation of the HTTP request. >=20 > -- hmac-sha-256 >=20 > Token is issued with a symmetric secret appropriate for use with the HMAC= - > SHA-256 algorithm over a normalized representation of the HTTP request. >=20 > -- rsassa-pkcs1-v1.5-sha-256 >=20 > Token is associated with PK appropriate for use with the RSASSA-PKCS1-v1.= 5 > method using the SHA-256 hash algorithm over a normalized representation > of the HTTP request. The client will have access to the private key while= the > server will have access to the public key. >=20 > -- basic-hmac-sha-1 >=20 > A special case token which allows using Basic Authentication credentials > (username and password) as an hmac-sha-1 class token. The password will > be used as the symmetric shared secret. This token class is assigned a sp= ecial > name to reflect the source of the credentials and make it trivial to depl= oy as a > direct replacement for Basic Auth. >=20 > -- bearer-opaque >=20 > A secret-less token class using an opaque string. The 'opaque' label is u= sed to > indicate that this is a server-issued token with a structure unknown to t= he > client. I expect other bearer token classes to be defined later to allow = the > client or other entities to self-issue a token (for example, a SWT token = can be > called bearer-swt). >=20 > Comments? >=20 > EHL >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Dec 4 21:29:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41F473A6405 for ; Fri, 4 Dec 2009 21:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52GCkbBHMy8i for ; Fri, 4 Dec 2009 21:29:31 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 31B193A62C1 for ; Fri, 4 Dec 2009 21:29:31 -0800 (PST) Received: (qmail 19761 invoked from network); 5 Dec 2009 05:29:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Dec 2009 05:29:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 4 Dec 2009 22:29:14 -0700 From: Eran Hammer-Lahav To: Greg Brail , Brian Eaton Date: Fri, 4 Dec 2009 22:29:32 -0700 Thread-Topic: [OAUTH-WG] Access to raw HTTP request body Thread-Index: Acp1NNLji+KW/gQiRP+DSLz6DATxIAAGb+mgAAdPTVA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293834@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF73C@usps.sonoa.local> In-Reply-To: <48AE706BD74FCC4297AD778805CA46F6184C5CF73C@usps.sonoa.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343785293834P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2009 05:29:37 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785293834P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am proposing to make anything to do with the body optional and at the dis= cretion of the server whether they want to require or validate it. And eith= er way, stop treating form-encoded bodies differently than any other. EHL From: Greg Brail [mailto:gbrail@sonoasystems.com] Sent: Friday, December 04, 2009 6:07 PM To: Brian Eaton; Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Access to raw HTTP request body In Java Servlet 2.5, if I'm reading section SRV3.1.1 of the spec correctly = the servlet has the opportunity to get the individual parameters (and thus = direct the servlet engine to parse the parameters automatically), or to rea= d the raw request body. There is no way to get both. So for servlets, at least, it seems to me that the answer is that in any pr= actical use case, access to the original POST body can't be counted upon. On a related note, I'll reiterate that accessing the raw request body can a= dd a layer of inefficiency to an HTTP proxy, such as our own, especially wh= en the body is large. Is there a possibility that we can require signing the POST body when the O= Auth protocol is used to ask for request and access tokens, but NOT require= such signing when authenticated requests are made later on? That way an im= plementer could choose to take the performance hit for the two methods in t= he OAuth protocol flow (at least in 1.0) that absolutely require that the P= OST body be signed, but not for everything else. I suppose that is the point of the body-signing extension, so forgive me if= I haven't read that one yet. greg -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Eaton Sent: Friday, December 04, 2009 5:49 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Access to raw HTTP request body On Fri, Dec 4, 2009 at 2:38 PM, Eran Hammer-Lahav > wrote: > Are there cases where form-encoded bodies change after set by the client = (in a lower layer)? I think it depends on the client. Most of the client code I've looked at assumes that authentication happens with (surprise surprise) bearer tokens. It's a real pain for client authors to move that code around. > Or where the server might have access to the processed form-encoded param= eters but not the original encoded body string? This definitely happens, it's how the vanilla java servlet API works. I think the same is true of django. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343785293834P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am prop= osing to make anything to do with the body optional and at the discretion o= f the server whether they want to require or validate it. And either way, s= top treating form-encoded bodies differently than any other.

 

EHL

 

From: Greg = Brail [mailto:gbrail@sonoasystems.com]
Sent: Friday, December 04= , 2009 6:07 PM
To: Brian Eaton; Eran Hammer-Lahav
Cc: O= Auth WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Access to raw HT= TP request body

=  

In Java Servlet 2.5, if I’m r= eading section SRV3.1.1 of the spec correctly the servlet has the opportuni= ty to get the individual parameters (and thus direct the servlet engine to = parse the parameters automatically), or to read the raw request body. There= is no way to get both.

 

So for servlets, at least, it seems to me t= hat the answer is that in any practical use case, access to the original PO= ST body can’t be counted upon.

=  

On a related note, I’ll = reiterate that accessing the raw request body can add a layer of inefficien= cy to an HTTP proxy, such as our own, especially when the body is large.

 

Is there a possibility that we can require signing the POST body when= the OAuth protocol is used to ask for request and access tokens, but NOT r= equire such signing when authenticated requests are made later on? That way= an implementer could choose to take the performance hit for the two method= s in the OAuth protocol flow (at least in 1.0) that absolutely require that= the POST body be signed, but not for everything else.

 

I suppose th= at is the point of the body-signing extension, so forgive me if I havenR= 17;t read that one yet.

 

       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  greg

 

-----Original Message-----
From: oauth-bounces@= ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Eaton
Sent: = Friday, December 04, 2009 5:49 PM
To: Eran Hammer-Lahav
Cc: OAuth WG = (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Access to raw HTTP request body=

 

On Fri, Dec 4, 2009 at 2:38 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

> Are there cases where form-encoded bodies cha= nge after set by the client (in a lower layer)?

 

I think it depends = on the client.  Most of the client code I've looked

at assumes that authentication happens with (surprise s= urprise) bearer

tokens.  It's a = real pain for client authors to move that code around.

 

> Or wher= e the server might have access to the processed form-encoded parameters but= not the original encoded body string?

 

This definitely happens, it'= s how the vanilla java servlet API works.

I think the same is true of django.

 

Cheers,

Brian

___________= ____________________________________

= OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/= mailman/listinfo/oauth

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785293834P3PW5EX1MB01E_-- From eran@hueniverse.com Sat Dec 5 23:29:48 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F833A67A6 for ; Sat, 5 Dec 2009 23:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbcJeRS51naz for ; Sat, 5 Dec 2009 23:29:47 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4117C3A6781 for ; Sat, 5 Dec 2009 23:29:47 -0800 (PST) Received: (qmail 11035 invoked from network); 6 Dec 2009 07:29:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Dec 2009 07:29:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 6 Dec 2009 00:29:36 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 6 Dec 2009 00:29:58 -0700 Thread-Topic: Including token class in authenticated requests Thread-Index: Acp2Renj29lo4PYbRmeMhNQZN/1VCQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Including token class in authenticated requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 07:29:48 -0000 In my proposed approach, the server informs the client which token classes = it supports at a given endpoint. The client knows the class of the token it= received using the information provided by the server when issuing the tok= en. The class of the token identified the cryptographic properties of the t= oken (e.g. hmac-sha-1, hmac-sha-256, rsassa-pkcs1-v1.5-sha-256, bearer-opaq= ue). The server includes in the challenge the list of supported token classes: WWW-Authenticate: Token realm=3D"generic", classes=3D"hmac-sha-1 hmac-sha-= 256" The question is, is it necessary for the client to inform the server back w= hich token class it is using? Whether the server issued the token, or suppo= rts token classes issued by another entity (the client, third party, etc.),= it is should be pretty easy for the server to know the properties of the t= oken, simply by looking up the token identifier. With the proposed 4 classes, the token is an opaque string which will requi= re the server to either look it up in a database or decrypt it for self-con= tained information. Either way, in the current model knowing the token clas= s is easy to do without having the client provide it. Future extensions def= ining new token classes (and I expect a few proposals before we are done wi= th this work) can easily accommodate the need to identify the token class f= rom the token identifier. While it is trivial for the client to include this information, and it must= have it either way since it picks the appropriate token based on the class= es supported by the server, it is still incorrect to require the client to = send wasteful information. On the other hand, this might be one of those op= timizations that are just not worth the hassle, and the client can waste 20= -40 bytes in each request sending the additional info. Comments? EHL From email@pbryan.net Sat Dec 5 23:42:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742113A6834 for ; Sat, 5 Dec 2009 23:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxTWoGU7C5D3 for ; Sat, 5 Dec 2009 23:42:26 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 7DAC33A67A6 for ; Sat, 5 Dec 2009 23:42:26 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 8DB166154; Sun, 6 Dec 2009 07:42:16 +0000 (UTC) From: "Paul C. Bryan" To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Sat, 05 Dec 2009 23:41:58 -0800 Message-ID: <1260085318.6142.590.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Including token class in authenticated requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 07:42:27 -0000 On Sun, 2009-12-06 at 00:29 -0700, Eran Hammer-Lahav wrote: > In my proposed approach, the server informs the client which token > classes it supports at a given endpoint. The client knows the class of > the token it received using the information provided by the server > when issuing the token. The class of the token identified the > cryptographic properties of the token (e.g. hmac-sha-1, hmac-sha-256, > rsassa-pkcs1-v1.5-sha-256, bearer-opaque). > > The server includes in the challenge the list of supported token > classes: > > WWW-Authenticate: Token realm="generic", classes="hmac-sha-1 > hmac-sha-256" Probably dumb bikeshedding question: why hmac-sha-1 and not hmac-sha1? > The question is, is it necessary for the client to inform the server > back which token class it is using? Whether the server issued the > token, or supports token classes issued by another entity (the client, > third party, etc.), it is should be pretty easy for the server to know > the properties of the token, simply by looking up the token > identifier. While not technically necessary, I think it may be useful. If the token is an opaque string (and should the server support multiple opaque token formats), it's probably better to be explicit how the token should be dealt with rather than leaving the server to its own devices to trying to find a matching type. Alternatively, as a workaround the opaque token itself could contain some kind of identifier to identify its type, allowing the server to quickly determine how to handle it. > With the proposed 4 classes, the token is an opaque string which will > require the server to either look it up in a database or decrypt it > for self-contained information. Either way, in the current model > knowing the token class is easy to do without having the client > provide it. Future extensions defining new token classes (and I expect > a few proposals before we are done with this work) can easily > accommodate the need to identify the token class from the token > identifier. > > While it is trivial for the client to include this information, and it > must have it either way since it picks the appropriate token based on > the classes supported by the server, it is still incorrect to require > the client to send wasteful information. On the other hand, this might > be one of those optimizations that are just not worth the hassle, and > the client can waste 20-40 bytes in each request sending the > additional info. In many deployments, it may be redundant, but I can see scenarios where ambiguity will incur cost on the server, making someone wish to have it explicitly identified when the token is provided. My 2¢. Paul > > Comments? > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sat Dec 5 23:55:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A890A3A6834 for ; Sat, 5 Dec 2009 23:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFKF2A1zYadz for ; Sat, 5 Dec 2009 23:55:42 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E72A33A67AA for ; Sat, 5 Dec 2009 23:55:41 -0800 (PST) Received: (qmail 16888 invoked from network); 6 Dec 2009 07:55:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Dec 2009 07:55:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 6 Dec 2009 00:55:32 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 6 Dec 2009 00:55:53 -0700 Thread-Topic: Request for proposals on bootstrapping usernames Thread-Index: Acp2SYkrFGVCCKOOQfehV9SD+uC8Lg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 07:55:42 -0000 The reason why I got interested in bringing this work to the IETF to begin = with was to try and use it to solve the problems with HTTP Basic auth. It i= s clear that at this point Digest is not likely to win wide adoption and th= e simplicity of Basic trumps most other considerations. I am looking for a = way to allow clients to use existing usernames and password, by defining a = token class that uses these credentials to bootstrap and provide clients wi= th a set of token credentials they already have. I was (easily) convinced that using passwords as HMAC keys is a bad idea be= cause it will require servers to store passwords in the clear which even Ba= sic does not require them. However, I think it is worth trying to find idea= s on how to use existing usernames with the new token scheme that will repl= ace Basic auth in the most common use cases. This is currently not an explicit item of the WG, but we are allowed to inc= lude such a token class in our '2-legged' proposal. Comments? EHL From eran@hueniverse.com Sun Dec 6 00:00:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35C63A6880 for ; Sun, 6 Dec 2009 00:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-NwKK+klCVr for ; Sun, 6 Dec 2009 00:00:09 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 477463A685D for ; Sun, 6 Dec 2009 00:00:09 -0800 (PST) Received: (qmail 13742 invoked from network); 6 Dec 2009 07:59:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Dec 2009 07:59:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 6 Dec 2009 00:59:58 -0700 From: Eran Hammer-Lahav To: "Paul C. Bryan" Date: Sun, 6 Dec 2009 01:00:21 -0700 Thread-Topic: [OAUTH-WG] Including token class in authenticated requests Thread-Index: Acp2R6OGU0us4QvQRjKGdN/WeXELYQAAi+Sg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529389A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1260085318.6142.590.camel@localhost> In-Reply-To: <1260085318.6142.590.camel@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Including token class in authenticated requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 08:00:10 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGF1bCBDLiBCcnlhbiBb bWFpbHRvOmVtYWlsQHBicnlhbi5uZXRdDQo+IFNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAwNSwg MjAwOSAxMTo0MiBQTQ0KDQo+ID4gCVdXVy1BdXRoZW50aWNhdGU6IFRva2VuIHJlYWxtPSJnZW5l cmljIiwgY2xhc3Nlcz0iaG1hYy1zaGEtMQ0KPiA+IGhtYWMtc2hhLTI1NiINCj4gDQo+IFByb2Jh Ymx5IGR1bWIgYmlrZXNoZWRkaW5nIHF1ZXN0aW9uOiB3aHkgaG1hYy1zaGEtMSBhbmQgbm90IGht YWMtc2hhMT8NCg0KSXTigJlzIHRoZSBwcm9wZXIgaGFzaCBmdW5jdGlvbiBuYW1lLiBZb3UnbGwg bm90aWNlIHRoYXQgdGhlIG5ldyBjbGFzcyBuYW1lcyBhcmUgbW9yZSBkZXNjcmlwdGl2ZSBhbmQg cmVmbGVjdCB3aGF0IHRoZXkgYXJlLCBhcyBvcHBvc2VkIHRvIG1ha2luZyBuYW1lcyB1cCAoZS5n LiBSU0EtU0hBMSkuDQogDQo+IEFsdGVybmF0aXZlbHksIGFzIGEgd29ya2Fyb3VuZCB0aGUgb3Bh cXVlIHRva2VuIGl0c2VsZiBjb3VsZCBjb250YWluIHNvbWUNCj4ga2luZCBvZiBpZGVudGlmaWVy IHRvIGlkZW50aWZ5IGl0cyB0eXBlLCBhbGxvd2luZyB0aGUgc2VydmVyIHRvIHF1aWNrbHkgZGV0 ZXJtaW5lDQo+IGhvdyB0byBoYW5kbGUgaXQuDQoNClRoYXQncyBteSBwb2ludC4gQnV0IGlmIGV2 ZXJ5IHNlcnZlciBpcyBnb2luZyB0byBkZWZpbmUgaXRzIG93biB3YXkgb2YgZW5jb2RpbmcgdGhp cyB2YWx1ZSwgaXQgbWVhbnMgd2UgY2FuIHNob3cgYSByZWFzb24gd2h5IGl0IHNob3VsZCBiZSBw cm92aWRlZCBpbiBhIHN0YW5kYXJkIHdheS4gQW5kIHRoYXQncyBteSBxdWVzdGlvbi4uLg0KDQpF SEwNCiANCg0K From hubertlvg@gmail.com Sun Dec 6 01:04:23 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FAEA3A6805 for ; Sun, 6 Dec 2009 01:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQFFviD2odXO for ; Sun, 6 Dec 2009 01:04:22 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 606B93A635F for ; Sun, 6 Dec 2009 01:04:22 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so203445eyd.51 for ; Sun, 06 Dec 2009 01:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GrbHVPNJT7jqqM1G0LLnhVRdlkKvypDdCKNLd/eeAqk=; b=LbZs5RMDOvNd1ElL56/Od+enTE2BN8ca1MgE2xkVXJTvrvQLMGuIF5FSe4CGZjLvJL Bptx+/1PzsROw8hjXbIcxECo2cZ92xcUHaCFZyKCQ7V2fmzoUg0MFWN6UspBR0FmmffQ mZluhu7MY1M/7VTfYSV29FNX9qc+9npGtZckY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RucSXHmfc2p21iATTKNm5DzkITRFZ+/LeIIEm8giYVGoXwAflWJnDTQv/itRMJ4tLS Zm5vrgXyLpIbcK9+EB+ZCRK1I5ofixv4tFXp5vlV6Aong/kp7xfkzz32E4/eDM11shLp NY7IPMgLfN0iNWgp7Ox5aU/ZhhhG7rPnTVzPs= MIME-Version: 1.0 Received: by 10.213.37.143 with SMTP id x15mr2672344ebd.68.1260090248058; Sun, 06 Dec 2009 01:04:08 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529389A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1260085318.6142.590.camel@localhost> <90C41DD21FB7C64BB94121FBBC2E7234378529389A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 6 Dec 2009 10:04:08 +0100 Message-ID: <6c0fd2bc0912060104t44d4f755yb00aef9c6c3a1d23@mail.gmail.com> From: Hubert Le Van Gong To: Eran Hammer-Lahav Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Including token class in authenticated requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 09:04:23 -0000 I don't think we can rely on every token format (present and future) to inc= lude the same standardized way of describing its kind. The client really ought to clearly indicate the kind of token it's using in the request, this is a common practice (e.g. WS-Trust for instance with the TokenType attribute). As Paul indicated it can help the server handle the request. Hubert On Sun, Dec 6, 2009 at 9:00 AM, Eran Hammer-Lahav wro= te: > > >> -----Original Message----- >> From: Paul C. Bryan [mailto:email@pbryan.net] >> Sent: Saturday, December 05, 2009 11:42 PM > >> > =A0 =A0 WWW-Authenticate: Token realm=3D"generic", classes=3D"hmac-sha= -1 >> > hmac-sha-256" >> >> Probably dumb bikeshedding question: why hmac-sha-1 and not hmac-sha1? > > It=92s the proper hash function name. You'll notice that the new class na= mes are more descriptive and reflect what they are, as opposed to making na= mes up (e.g. RSA-SHA1). > >> Alternatively, as a workaround the opaque token itself could contain som= e >> kind of identifier to identify its type, allowing the server to quickly = determine >> how to handle it. > > That's my point. But if every server is going to define its own way of en= coding this value, it means we can show a reason why it should be provided = in a standard way. And that's my question... > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From stephen.farrell@cs.tcd.ie Sun Dec 6 03:14:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39EF63A6832 for ; Sun, 6 Dec 2009 03:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuBB3UkKKfy1 for ; Sun, 6 Dec 2009 03:14:21 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 083C33A67E5 for ; Sun, 6 Dec 2009 03:14:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 00A58360097; Sun, 6 Dec 2009 11:14:10 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXIPxXaeODme; Sun, 6 Dec 2009 11:14:06 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 086EE360096; Sun, 6 Dec 2009 11:14:05 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id E0AA97C33B; Sun, 6 Dec 2009 11:14:05 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulVsbnJpu7jg; Sun, 6 Dec 2009 11:14:02 +0000 (GMT) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail01.newbay.com (Postfix) with ESMTP id E68DA7C332; Sun, 6 Dec 2009 11:14:01 +0000 (GMT) References: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> Message-Id: From: Stephen Farrell To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sun, 6 Dec 2009 11:13:57 +0000 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Including token class in authenticated requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 11:14:22 -0000 On 6 Dec 2009, at 07:29, Eran Hammer-Lahav wrote: > The class of the token identified the cryptographic properties of > the token (e.g. hmac-sha-1, hmac-sha-256, rsassa-pkcs1-v1.5-sha-256, > bearer-opaque). That's just confusing. The examples are mac/signature schemes. If you want token classes something else is needed. What is "token class" supposed to mean? S. > > The server includes in the challenge the list of supported token > classes: > > WWW-Authenticate: Token realm="generic", classes="hmac-sha-1 hmac- > sha-256" > > The question is, is it necessary for the client to inform the server > back which token class it is using? Whether the server issued the > token, or supports token classes issued by another entity (the > client, third party, etc.), it is should be pretty easy for the > server to know the properties of the token, simply by looking up the > token identifier. > > With the proposed 4 classes, the token is an opaque string which > will require the server to either look it up in a database or > decrypt it for self-contained information. Either way, in the > current model knowing the token class is easy to do without having > the client provide it. Future extensions defining new token classes > (and I expect a few proposals before we are done with this work) can > easily accommodate the need to identify the token class from the > token identifier. > > While it is trivial for the client to include this information, and > it must have it either way since it picks the appropriate token > based on the classes supported by the server, it is still incorrect > to require the client to send wasteful information. On the other > hand, this might be one of those optimizations that are just not > worth the hassle, and the client can waste 20-40 bytes in each > request sending the additional info. > > Comments? > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hubertlvg@gmail.com Sun Dec 6 03:32:22 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A603A683D for ; Sun, 6 Dec 2009 03:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GXHqUE7xZ9T for ; Sun, 6 Dec 2009 03:32:21 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 343AD3A6832 for ; Sun, 6 Dec 2009 03:32:21 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so216340eyd.51 for ; Sun, 06 Dec 2009 03:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dah5D4fdRa0+f/RMEs02pmzAL0hxJUykpzgxvH+fMGQ=; b=D57tULPSFgdfeSdKuV2z7Vc7czaOqgLNGLkA9NmQae0Pi2iOSpvA+m9AAXpJqU98dl NfEDTwNi8R3t3WzfRwziyiKxUsg/qiCdZiT7eylNDt/CpRewiTsao2NqwS1NJTP1Zzxf mIG6wyNQTW8LDPkbUYN70Uelx1V4arQ3lbBH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=r2EO2uXm7sQOVAVhlgvTCLiWF1yyc5pX0NXYPN7cJgBjERdhpOjLlcZT6uqeO4f4z6 b+ZKTTJAcwfkzUQrpFKV7IE+DX7Ho3oGaiLi4FfGjkZaY9p1nCLeQY9t5WnauJV03qff YdG4Vr7jJaJImWPh70I0NDgllWSASki5NGnOo= MIME-Version: 1.0 Received: by 10.213.37.143 with SMTP id x15mr2809500ebd.68.1260099128142; Sun, 06 Dec 2009 03:32:08 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 6 Dec 2009 12:32:08 +0100 Message-ID: <6c0fd2bc0912060332r15a67b85off0a78474820a07d@mail.gmail.com> From: Hubert Le Van Gong To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Including token class in authenticated requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 11:32:22 -0000 Yeah I kind of agree the name might be misleading. Separating the 2 properties (token type and crypto) would be preferable. Talking of token classes/types then we probably should reuse names that already exist like: username token, binary token (similar I think to the opaque one mentioned so far) and XML token. Hubert On Sun, Dec 6, 2009 at 12:13 PM, Stephen Farrell wrote: > > > On 6 Dec 2009, at 07:29, Eran Hammer-Lahav wrote: > >> The class of the token identified the cryptographic properties of the >> token (e.g. hmac-sha-1, hmac-sha-256, rsassa-pkcs1-v1.5-sha-256, >> bearer-opaque). > > That's just confusing. The examples are mac/signature schemes. If you wan= t > token classes something else is needed. What is "token class" supposed to > mean? > S. > >> >> The server includes in the challenge the list of supported token classes= : >> >> =A0 WWW-Authenticate: Token realm=3D"generic", classes=3D"hmac-sha-1 >> hmac-sha-256" >> >> The question is, is it necessary for the client to inform the server bac= k >> which token class it is using? Whether the server issued the token, or >> supports token classes issued by another entity (the client, third party= , >> etc.), it is should be pretty easy for the server to know the properties= of >> the token, simply by looking up the token identifier. >> >> With the proposed 4 classes, the token is an opaque string which will >> require the server to either look it up in a database or decrypt it for >> self-contained information. Either way, in the current model knowing the >> token class is easy to do without having the client provide it. Future >> extensions defining new token classes (and I expect a few proposals befo= re >> we are done with this work) can easily accommodate the need to identify = the >> token class from the token identifier. >> >> While it is trivial for the client to include this information, and it >> must have it either way since it picks the appropriate token based on th= e >> classes supported by the server, it is still incorrect to require the cl= ient >> to send wasteful information. On the other hand, this might be one of th= ose >> optimizations that are just not worth the hassle, and the client can was= te >> 20-40 bytes in each request sending the additional info. >> >> Comments? >> >> EHL >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From esjewett@gmail.com Sun Dec 6 10:19:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF953A691A for ; Sun, 6 Dec 2009 10:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDSLRv01tZBe for ; Sun, 6 Dec 2009 10:19:09 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 0A5213A68FB for ; Sun, 6 Dec 2009 10:19:06 -0800 (PST) Received: by pzk6 with SMTP id 6so3468281pzk.29 for ; Sun, 06 Dec 2009 10:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=EXopKxmAVNltYfodOhQBsEujWhyZhhjSLHw9JawhYL0=; b=vNzaeFWYtvMEGNQKEdeVUVmnSgOAZvKDsr5By+mnOif38JKRtIUc4LoGwOZpsGLk7W jfMjBkmS0mjsJNYw/QYtOf2LCo1I3BT1ziE4jm/0pWqTYQqT5FQxpotHCNqF9VTFtinn JpAY8GQj3pqODG4roTUau0ObarldhcL0T8vJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=st4JaO3hf5BHbCg37pCqSV0FLDOx7NA3ILCgD4h+800yaaMU6EhJfdpkQCj//4ohT8 9pGDf+rein02FuXQKKGijebER6UlHwZIEH9S6Zjos5bklaAnajpezDGtNLzRLITBBJte eXm+mLMahcB4vCTzVPIVEUCkenDwEeh7kSQGE= MIME-Version: 1.0 Received: by 10.140.128.9 with SMTP id a9mr385334rvd.152.1260123534739; Sun, 06 Dec 2009 10:18:54 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 6 Dec 2009 12:18:54 -0600 Message-ID: <68f4a0e80912061018l676ee13r33f0ac66f5ead7ba@mail.gmail.com> From: Ethan Jewett To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 18:19:10 -0000 I would like to understand what advantages this approach has over Basic with a secure connection. I think the major downside to providing this type of bootstrapping method is that there is no way for a user to verify that the client is behaving well with regards to their username/password combination. Once you give your username/password to a client that is a bad actor, the game is up. A lot of work has been done trying to eradicate the so-called "password anti-pattern" and there is a lot of work left to do. It seems that this approach would be going backwards. That said, there are always tradeoffs, so outlining the pluses and minuses should probably be done thoroughly before coming to a decision. Ethan On Sun, Dec 6, 2009 at 1:55 AM, Eran Hammer-Lahav wro= te: > The reason why I got interested in bringing this work to the IETF to begi= n with was to try and use it to solve the problems with HTTP Basic auth. It= is clear that at this point Digest is not likely to win wide adoption and = the simplicity of Basic trumps most other considerations. I am looking for = a way to allow clients to use existing usernames and password, by defining = a token class that uses these credentials to bootstrap and provide clients = with a set of token credentials they already have. > > I was (easily) convinced that using passwords as HMAC keys is a bad idea = because it will require servers to store passwords in the clear which even = Basic does not require them. However, I think it is worth trying to find id= eas on how to use existing usernames with the new token scheme that will re= place Basic auth in the most common use cases. > > This is currently not an explicit item of the WG, but we are allowed to i= nclude such a token class in our '2-legged' proposal. > > Comments? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Sun Dec 6 10:35:18 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A890C3A693E for ; Sun, 6 Dec 2009 10:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8xEItOWfIyu for ; Sun, 6 Dec 2009 10:35:17 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9D96A3A66B4 for ; Sun, 6 Dec 2009 10:35:17 -0800 (PST) Received: (qmail 2023 invoked from network); 6 Dec 2009 18:35:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Dec 2009 18:35:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 6 Dec 2009 11:34:36 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 6 Dec 2009 11:35:00 -0700 Thread-Topic: [OAUTH-WG] Including token class in authenticated requests Thread-Index: Acp2Z7/p/yGw5bS+QUii5cK7qhB/mQALhFGQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852938B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0912060332r15a67b85off0a78474820a07d@mail.gmail.com> In-Reply-To: <6c0fd2bc0912060332r15a67b85off0a78474820a07d@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Including token class in authenticated requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 18:35:18 -0000 Token credentials include: * Identifier (what is usually considered the 'token') * Identifier structure (opaque string, encoded value, XML/JSON syntax) * Cryptographic properties/method (the black box applied to the normalized = request to produce some kind of verifiable value) * Shared-secret (optional, which can be embedded in the identifier or provi= ded separately) Tokens credentials also have: * Realm - the protected resource segment they can be used to access * Source/purpose - the process through which they have been obtained (direc= tly/username, delegation) I used the term class to identify the combination of these token properties= . I agree that the proposed class names are confusing as they focus on only= the cryptographic properties. But that can be solved with better names rat= her than a better term. If all tokens were server-issued, the server would simply provide a server-= specific token name and provide the cryptographic method to be used with it= . For example, when the server issues a token, it will say: name=3D"supertoken", method=3D"hmac-sha-1", secret=3D"3hj2jh32", token=3D"h= kj3h3uhd" Then when in the challenge it will ask for any "supertoken" using the "hmac= -sha-1" method. Why do we need a name? We need something to tell the client which token to = use, and it should not be limited to just the cryptographic method used. Th= is is the existing problem in Basic and Digest and why we need to define a = new scheme which greatly overlaps them. They do not support any other class= es of tokens other than username (yes, they can be used with other classes = but only in a fully controlled client-server environment, not the real worl= d). The problem with a server-picked name, is that it only works with server-is= sued tokens. It is very likely that in the (near) future someone will want = to define a self-issued token using PKI or other means. That requires the s= erver to be able to express what it supports with something other than a se= rver-picked name. We can break all the properties into separate attributes. The problem with = that is it requires the ability to declare specific combinations. How shoul= d the server express it supports a username class token with hmac-sha-1 as = well as a delegation class token with hmac-sha-256 or hmac-sha-1? I am not = sure what's the right way to segment all this. But I know that it cannot be= limited to just a choice of crypto. EHL > -----Original Message----- > From: Hubert Le Van Gong [mailto:hubertlvg@gmail.com] > Sent: Sunday, December 06, 2009 3:32 AM > To: Stephen Farrell > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Including token class in authenticated requests >=20 > Yeah I kind of agree the name might be misleading. Separating the 2 > properties (token type and crypto) would be preferable. > Talking of token classes/types then we probably should reuse names that > already exist like: username token, binary token (similar I think to the > opaque one mentioned so far) and XML token. >=20 > Hubert >=20 >=20 > On Sun, Dec 6, 2009 at 12:13 PM, Stephen Farrell > wrote: > > > > > > On 6 Dec 2009, at 07:29, Eran Hammer-Lahav > wrote: > > > >> The class of the token identified the cryptographic properties of the > >> token (e.g. hmac-sha-1, hmac-sha-256, rsassa-pkcs1-v1.5-sha-256, > >> bearer-opaque). > > > > That's just confusing. The examples are mac/signature schemes. If you > > want token classes something else is needed. What is "token class" > > supposed to mean? > > S. > > > >> > >> The server includes in the challenge the list of supported token class= es: > >> > >> =A0 WWW-Authenticate: Token realm=3D"generic", classes=3D"hmac-sha-1 > >> hmac-sha-256" > >> > >> The question is, is it necessary for the client to inform the server > >> back which token class it is using? Whether the server issued the > >> token, or supports token classes issued by another entity (the > >> client, third party, etc.), it is should be pretty easy for the > >> server to know the properties of the token, simply by looking up the > token identifier. > >> > >> With the proposed 4 classes, the token is an opaque string which will > >> require the server to either look it up in a database or decrypt it > >> for self-contained information. Either way, in the current model > >> knowing the token class is easy to do without having the client > >> provide it. Future extensions defining new token classes (and I > >> expect a few proposals before we are done with this work) can easily > >> accommodate the need to identify the token class from the token > identifier. > >> > >> While it is trivial for the client to include this information, and > >> it must have it either way since it picks the appropriate token based > >> on the classes supported by the server, it is still incorrect to > >> require the client to send wasteful information. On the other hand, > >> this might be one of those optimizations that are just not worth the > >> hassle, and the client can waste > >> 20-40 bytes in each request sending the additional info. > >> > >> Comments? > >> > >> EHL > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From eran@hueniverse.com Sun Dec 6 10:43:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0919C3A686B for ; Sun, 6 Dec 2009 10:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAM-LHRx2cb6 for ; Sun, 6 Dec 2009 10:43:06 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 410113A6848 for ; Sun, 6 Dec 2009 10:43:06 -0800 (PST) Received: (qmail 8846 invoked from network); 6 Dec 2009 18:42:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Dec 2009 18:42:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 6 Dec 2009 11:42:56 -0700 From: Eran Hammer-Lahav To: Ethan Jewett , "OAuth WG (oauth@ietf.org)" Date: Sun, 6 Dec 2009 11:43:20 -0700 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp2oJkQ132viBvAQV6jTdhjBGDklgAApSBA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852938B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912061018l676ee13r33f0ac66f5ead7ba@mail.gmail.com> In-Reply-To: <68f4a0e80912061018l676ee13r33f0ac66f5ead7ba@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 18:43:07 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Ethan Jewett > Sent: Sunday, December 06, 2009 10:19 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping > usernames >=20 > I would like to understand what advantages this approach has over Basic w= ith > a secure connection. First, it doesn't require a secure connection. But a secure connection does= n't solve phishing and other problems. If there was a way for me to give my= credentials to an application I trust (like my browser) which will then au= thenticate me without sending my password, but still use my password to aut= henticate, authenticating against attackers will not help them much beyond = being able to make that one request on their own. EHL =20 From hallam@gmail.com Sun Dec 6 10:44:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869883A691A for ; Sun, 6 Dec 2009 10:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kSWm0zBCJPG for ; Sun, 6 Dec 2009 10:44:58 -0800 (PST) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.211.171]) by core3.amsl.com (Postfix) with ESMTP id 47F913A68D0 for ; Sun, 6 Dec 2009 10:44:58 -0800 (PST) Received: by ywh1 with SMTP id 1so7638534ywh.18 for ; Sun, 06 Dec 2009 10:44:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DcAwNx9F1tPzLw7Mx3ABO35mmFQ7mVf5Kz/1GcD4oEE=; b=nFqr/N2sZYlk6d+D1gTzrauBNWaDlVA3fzMQH3LdpYHIgtZI3JLc1L6h1VTGyA9W1d ulygF6tbTYJiGKtBsPihB3JHW/fDaBM3kJiqxLKYtpFxCcVjl76+sWGA+v/nOtvq/mAU luPqe0dWpb5jzwh/9W/OBXwUhEOYegzwKjobQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mIsHy9LTdVS0WJgYDvl3YXk6tCZASLxWSY3jrzkhL7Sc09EeiZDmTtuSeDEV/6l/y7 lboatVwKGvfaDMaQnQqS0PCHg+QCHNRJfeoHL+zJEa7NB5GeIqanr/EAzkdigAmB5GXo So63S2RYYSC4SZCB5/HJMK1d16vhuSouf+x6k= MIME-Version: 1.0 Received: by 10.91.51.28 with SMTP id d28mr2167897agk.120.1260125085592; Sun, 06 Dec 2009 10:44:45 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 6 Dec 2009 13:44:45 -0500 Message-ID: From: Phillip Hallam-Baker To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 18:44:59 -0000 The problem with solving Basic Auth is that patent trolls are sitting on the technologies you would want to use instead. I absolutely disagree with the idea that storing the password en-clair makes Digest less satisfactory than Basic. Intercepting passwords on the wire is a trivial issue, if the attacker can compromise the password database on a server then they can bypass any other access control and get whatever they want in any case. This argument was dead and burried in the early 1990s when crack came out and even the most ideological UNIX fanboy had to finally admit that shadow passwords were essential. I know the arguments made in the UNIX manual. THEY ARE WRONG. They were somewhat accurate when they were written forty years ago. At this point the argument about the salt and so on are utterly ridiculous, wrong and dangerous. The fact is that well over 95% of passwords will be found in a dictionary of a million passwords. Forcing users to add non-alphabetic characters or to use capitalization results in a trivial increase in the work factor. The problem with DIGEST is that there is not enough ergodicity in the proof of possession blob passed over the wire. So DIGEST is now vulnerable to all the same attacks that can be performed against a password file. There is no way to fix that without using public key cryptography. DIGEST was designed to give the best security possible without using encumbered technology. On Sun, Dec 6, 2009 at 2:55 AM, Eran Hammer-Lahav wro= te: > The reason why I got interested in bringing this work to the IETF to begi= n with was to try and use it to solve the problems with HTTP Basic auth. It= is clear that at this point Digest is not likely to win wide adoption and = the simplicity of Basic trumps most other considerations. I am looking for = a way to allow clients to use existing usernames and password, by defining = a token class that uses these credentials to bootstrap and provide clients = with a set of token credentials they already have. > > I was (easily) convinced that using passwords as HMAC keys is a bad idea = because it will require servers to store passwords in the clear which even = Basic does not require them. However, I think it is worth trying to find id= eas on how to use existing usernames with the new token scheme that will re= place Basic auth in the most common use cases. > > This is currently not an explicit item of the WG, but we are allowed to i= nclude such a token class in our '2-legged' proposal. > > Comments? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From eran@hueniverse.com Sun Dec 6 10:54:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 159183A6811 for ; Sun, 6 Dec 2009 10:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.945 X-Spam-Level: X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+Vp9kCIM5cj for ; Sun, 6 Dec 2009 10:54:44 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 04D2C3A67F4 for ; Sun, 6 Dec 2009 10:54:43 -0800 (PST) Received: (qmail 7929 invoked from network); 6 Dec 2009 18:54:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Dec 2009 18:54:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 6 Dec 2009 11:54:32 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 6 Dec 2009 11:54:56 -0700 Thread-Topic: [OAUTH-WG] Including token class in authenticated requests Thread-Index: Acp2Z7/p/yGw5bS+QUii5cK7qhB/mQALhFGQAAPkWDA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852938B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293898@P3PW5EX1MB01.EX1.SECURESERVER.NET> <6c0fd2bc0912060332r15a67b85off0a78474820a07d@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437852938B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852938B6@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Including token class in authenticated requests X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 18:54:45 -0000 If it wasn't clear, I am trying to find the right level of abstraction... j= ust listing the cryptographic method isn't enough, but I am not sure what e= lse is needed. It may just be that the token scheme spec should only define= a base set of methods and a placeholder class parameter for others to defi= ne, such as OAuth. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Sunday, December 06, 2009 10:35 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Including token class in authenticated requests >=20 > Token credentials include: >=20 > * Identifier (what is usually considered the 'token') > * Identifier structure (opaque string, encoded value, XML/JSON syntax) > * Cryptographic properties/method (the black box applied to the normalize= d > request to produce some kind of verifiable value) > * Shared-secret (optional, which can be embedded in the identifier or > provided separately) >=20 > Tokens credentials also have: >=20 > * Realm - the protected resource segment they can be used to access > * Source/purpose - the process through which they have been obtained > (directly/username, delegation) >=20 > I used the term class to identify the combination of these token properti= es. I > agree that the proposed class names are confusing as they focus on only t= he > cryptographic properties. But that can be solved with better names rather > than a better term. >=20 > If all tokens were server-issued, the server would simply provide a serve= r- > specific token name and provide the cryptographic method to be used with > it. For example, when the server issues a token, it will say: >=20 > name=3D"supertoken", method=3D"hmac-sha-1", secret=3D"3hj2jh32", > token=3D"hkj3h3uhd" >=20 > Then when in the challenge it will ask for any "supertoken" using the "hm= ac- > sha-1" method. >=20 > Why do we need a name? We need something to tell the client which token > to use, and it should not be limited to just the cryptographic method use= d. > This is the existing problem in Basic and Digest and why we need to defin= e a > new scheme which greatly overlaps them. They do not support any other > classes of tokens other than username (yes, they can be used with other > classes but only in a fully controlled client-server environment, not the= real > world). >=20 > The problem with a server-picked name, is that it only works with server- > issued tokens. It is very likely that in the (near) future someone will w= ant to > define a self-issued token using PKI or other means. That requires the se= rver > to be able to express what it supports with something other than a server= - > picked name. >=20 > We can break all the properties into separate attributes. The problem wit= h > that is it requires the ability to declare specific combinations. How sho= uld the > server express it supports a username class token with hmac-sha-1 as well= as > a delegation class token with hmac-sha-256 or hmac-sha-1? I am not sure > what's the right way to segment all this. But I know that it cannot be li= mited > to just a choice of crypto. >=20 > EHL >=20 > > -----Original Message----- > > From: Hubert Le Van Gong [mailto:hubertlvg@gmail.com] > > Sent: Sunday, December 06, 2009 3:32 AM > > To: Stephen Farrell > > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Including token class in authenticated > > requests > > > > Yeah I kind of agree the name might be misleading. Separating the 2 > > properties (token type and crypto) would be preferable. > > Talking of token classes/types then we probably should reuse names > > that already exist like: username token, binary token (similar I think > > to the opaque one mentioned so far) and XML token. > > > > Hubert > > > > > > On Sun, Dec 6, 2009 at 12:13 PM, Stephen Farrell > > > > wrote: > > > > > > > > > On 6 Dec 2009, at 07:29, Eran Hammer-Lahav > > wrote: > > > > > >> The class of the token identified the cryptographic properties of > > >> the token (e.g. hmac-sha-1, hmac-sha-256, > > >> rsassa-pkcs1-v1.5-sha-256, bearer-opaque). > > > > > > That's just confusing. The examples are mac/signature schemes. If > > > you want token classes something else is needed. What is "token class= " > > > supposed to mean? > > > S. > > > > > >> > > >> The server includes in the challenge the list of supported token cla= sses: > > >> > > >> =A0 WWW-Authenticate: Token realm=3D"generic", classes=3D"hmac-sha-1 > > >> hmac-sha-256" > > >> > > >> The question is, is it necessary for the client to inform the > > >> server back which token class it is using? Whether the server > > >> issued the token, or supports token classes issued by another > > >> entity (the client, third party, etc.), it is should be pretty easy > > >> for the server to know the properties of the token, simply by > > >> looking up the > > token identifier. > > >> > > >> With the proposed 4 classes, the token is an opaque string which > > >> will require the server to either look it up in a database or > > >> decrypt it for self-contained information. Either way, in the > > >> current model knowing the token class is easy to do without having > > >> the client provide it. Future extensions defining new token classes > > >> (and I expect a few proposals before we are done with this work) > > >> can easily accommodate the need to identify the token class from > > >> the token > > identifier. > > >> > > >> While it is trivial for the client to include this information, and > > >> it must have it either way since it picks the appropriate token > > >> based on the classes supported by the server, it is still incorrect > > >> to require the client to send wasteful information. On the other > > >> hand, this might be one of those optimizations that are just not > > >> worth the hassle, and the client can waste > > >> 20-40 bytes in each request sending the additional info. > > >> > > >> Comments? > > >> > > >> EHL > > >> > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Dec 6 11:12:19 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2763A689C for ; Sun, 6 Dec 2009 11:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.942 X-Spam-Level: X-Spam-Status: No, score=-2.942 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqMpDY30kMer for ; Sun, 6 Dec 2009 11:12:17 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 1F42A3A67E7 for ; Sun, 6 Dec 2009 11:12:17 -0800 (PST) Received: (qmail 1589 invoked from network); 6 Dec 2009 19:12:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 6 Dec 2009 19:12:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 6 Dec 2009 12:12:05 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Sun, 6 Dec 2009 12:12:29 -0700 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp2p8BvpEje/cPLT8G5c5I9++g5UAAACK+A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852938BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912061018l676ee13r33f0ac66f5ead7ba@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437852938B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912061110t5b9548a2q449440787cf07036@mail.gmail.com> In-Reply-To: <68f4a0e80912061110t5b9548a2q449440787cf07036@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 19:12:20 -0000 It's very likely that this goal is overreaching and impractical within the = scope of this WG. I just want to give it a brief consideration. EHL > -----Original Message----- > From: Ethan Jewett [mailto:esjewett@gmail.com] > Sent: Sunday, December 06, 2009 11:10 AM > To: Eran Hammer-Lahav > Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping > usernames >=20 > In that case, I think I misunderstand the proposal. I'll wait for the dis= cussion > to fill out before I comment further. >=20 > Thanks, > Ethan >=20 > On Sun, Dec 6, 2009 at 12:43 PM, Eran Hammer-Lahav > wrote: > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Ethan Jewett > >> Sent: Sunday, December 06, 2009 10:19 AM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping > >> usernames > >> > >> I would like to understand what advantages this approach has over > >> Basic with a secure connection. > > > > First, it doesn't require a secure connection. But a secure connection > doesn't solve phishing and other problems. If there was a way for me to g= ive > my credentials to an application I trust (like my browser) which will the= n > authenticate me without sending my password, but still use my password to > authenticate, authenticating against attackers will not help them much > beyond being able to make that one request on their own. > > > > EHL > > > > From hallam@gmail.com Sun Dec 6 12:14:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2998128C0E5 for ; Sun, 6 Dec 2009 12:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP09EXa82VmR for ; Sun, 6 Dec 2009 12:14:44 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id D023228C0E2 for ; Sun, 6 Dec 2009 12:14:43 -0800 (PST) Received: by gxk28 with SMTP id 28so3552907gxk.9 for ; Sun, 06 Dec 2009 12:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0+lBvq/d8F6u6keDtHrNAFci7uWviMlYS+wT4rN7vCo=; b=aTpxJODzq6GfVPhOwX6wSwNQ9Xgc0EZ4S0MS+8bPp50vAaA1XrnxAXXJg14GPb3jIZ 2fEyTdZbu18rV7dzzHoRuGV7VodcukuJzg5sn+P+p+gUnnP7CZGxvOoBP+m3ga4Lvdug XUHdFPVXuiq1Zr+83TRItlsxL3V85mjOlOICw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A4cLl9mCZoV+8+yuYrawAw59VTL1B0qSk8KTW7u3N9lFnhQve1FDk900eZJVqiVHjX 7ZiHWnjsOiRYXIKUc/sBrMpFOVLlORJ412rOi7NcjwTJIMbFkYoC54mBSi60eZU7IcdT 2gRqriQ+Q3Uh/E0FbctC/0vPjFG1DLGZREl0g= MIME-Version: 1.0 Received: by 10.91.50.29 with SMTP id c29mr9611604agk.63.1260130470638; Sun, 06 Dec 2009 12:14:30 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852938B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912061018l676ee13r33f0ac66f5ead7ba@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437852938B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 6 Dec 2009 15:14:30 -0500 Message-ID: From: Phillip Hallam-Baker To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 20:14:45 -0000 That was the original objective of DIGEST, even if there is a phishing attack the password itself is not disclosed, only a hash of the password. I did warn people at the time that BASIC was a bad idea. On Sun, Dec 6, 2009 at 1:43 PM, Eran Hammer-Lahav wro= te: > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Ethan Jewett >> Sent: Sunday, December 06, 2009 10:19 AM >> To: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping >> usernames >> >> I would like to understand what advantages this approach has over Basic = with >> a secure connection. > > First, it doesn't require a secure connection. But a secure connection do= esn't solve phishing and other problems. If there was a way for me to give = my credentials to an application I trust (like my browser) which will then = authenticate me without sending my password, but still use my password to a= uthenticate, authenticating against attackers will not help them much beyon= d being able to make that one request on their own. > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From eran@hueniverse.com Sun Dec 6 12:29:34 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42EA3A686C for ; Sun, 6 Dec 2009 12:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNZgfK9Tlas8 for ; Sun, 6 Dec 2009 12:29:34 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E53F33A67B0 for ; Sun, 6 Dec 2009 12:29:33 -0800 (PST) Received: (qmail 23612 invoked from network); 6 Dec 2009 20:29:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Dec 2009 20:29:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 6 Dec 2009 13:29:20 -0700 From: Eran Hammer-Lahav To: Phillip Hallam-Baker Date: Sun, 6 Dec 2009 13:29:44 -0700 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp2sLmOz4QB+p5uS7STHS02csAySgAAdnEg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852938C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <68f4a0e80912061018l676ee13r33f0ac66f5ead7ba@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723437852938B7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 20:29:35 -0000 The main implementation issue I hear about DIGEST is the multi-request requ= irement. Because OAuth 1.0 flipped that (by making the client issue the non= ce, etc.) it is more appealing to developers. I don't know if trying to dir= ectly fix Basic is a practical/good idea. People seem to have very strong f= eeling about it. EHL > -----Original Message----- > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Sunday, December 06, 2009 12:15 PM > To: Eran Hammer-Lahav > Cc: Ethan Jewett; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping > usernames >=20 > That was the original objective of DIGEST, even if there is a phishing at= tack > the password itself is not disclosed, only a hash of the password. >=20 > I did warn people at the time that BASIC was a bad idea. >=20 > On Sun, Dec 6, 2009 at 1:43 PM, Eran Hammer-Lahav > wrote: > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Ethan Jewett > >> Sent: Sunday, December 06, 2009 10:19 AM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping > >> usernames > >> > >> I would like to understand what advantages this approach has over > >> Basic with a secure connection. > > > > First, it doesn't require a secure connection. But a secure connection > doesn't solve phishing and other problems. If there was a way for me to g= ive > my credentials to an application I trust (like my browser) which will the= n > authenticate me without sending my password, but still use my password to > authenticate, authenticating against attackers will not help them much > beyond being able to make that one request on their own. > > > > EHL > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 >=20 >=20 > -- > -- > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ From rbarnes@bbn.com Sun Dec 6 18:03:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299963A69DA for ; Sun, 6 Dec 2009 18:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSnU5e4kb+PD for ; Sun, 6 Dec 2009 18:03:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 35FC73A693F for ; Sun, 6 Dec 2009 18:03:54 -0800 (PST) Received: from [128.89.253.201] (helo=[172.27.15.171]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NHSwx-00041O-BA; Sun, 06 Dec 2009 21:03:43 -0500 Message-Id: From: Richard Barnes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293535@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 6 Dec 2009 21:03:42 -0500 References: <90C41DD21FB7C64BB94121FBBC2E72343785293535@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp & Nonce, together or apart X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 02:03:55 -0000 Separate. IIRC, they are handled separately, e.g., the server looks for non-decreasing timestamps. If they're not used separately (if the time semantic isn't important), then we should just have a nonce. --Richard On Dec 4, 2009, at 12:25 AM, Eran Hammer-Lahav wrote: > Here is an semi-bikeshedding question: > > timestamp="137131200", nonce="dj83hs9s" > OR > nonce="137131200:dj83hs9s" > > The only reason to put them together is because they are really two > parts of the same thing, and are not used separately. The only > reason to keep them separate is to make parsing a tiny bit easier. > > Comments? > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rbarnes@bbn.com Sun Dec 6 18:39:53 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912AC3A69EE for ; Sun, 6 Dec 2009 18:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycPbzZsL8MdA for ; Sun, 6 Dec 2009 18:39:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6B1A73A69F6 for ; Sun, 6 Dec 2009 18:39:52 -0800 (PST) Received: from [128.89.253.201] (helo=[172.27.15.171]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NHTVl-0004c6-BK; Sun, 06 Dec 2009 21:39:41 -0500 Message-Id: <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> From: Richard Barnes To: Peter Saint-Andre In-Reply-To: <4B183C57.4090100@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 6 Dec 2009 21:39:41 -0500 References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B183C57.4090100@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: Idan Gazit , oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 02:39:53 -0000 Ask and ye shall receive: (Updated terminology to match draft-hammer-oauth, i.e., s/Consumer/ Client/ and s/Service Provider/Server/) On Dec 3, 2009, at 5:31 PM, Peter Saint-Andre wrote: > > > On 12/1/09 5:21 PM, Idan Gazit wrote: >> Hey folks, >> >> I redrew/updated an old diagram >> (http://documentation.fring.com/images/1/11/Oauth_diagram.png) >> outlining >> the OAuth authentication flow. The old one didn't reflect the >> changes in >> 1.0a. >> >> The updated diagrams are here: >> >> http://s3.pixane.com/Oauth_diagram.png >> http://s3.pixane.com/Oauth_diagram.pdf > > Your diagrams are very helpful. Now we just need to convert them to > ASCII art for inclusion in an Internet-Draft. ;-) > >> Please feel free to use them, I hereby place them in the public >> domain. > > That's cool, too! > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From chris.messina@gmail.com Sun Dec 6 18:45:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3E828C0CF for ; Sun, 6 Dec 2009 18:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VugZ9rWgOFD3 for ; Sun, 6 Dec 2009 18:45:26 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id A49163A67B8 for ; Sun, 6 Dec 2009 18:45:25 -0800 (PST) Received: by fxm5 with SMTP id 5so4504142fxm.28 for ; Sun, 06 Dec 2009 18:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GS4Q+8qvH08UdzzCXJjTOEcMwraPW59UXMCtig2xWM8=; b=AlablRqhVUSFKGQ+5iOLTLBDyinRqKCvtlffnvaRrzKruQAuF11ZUTGG8TvpBOWYNp YRdiMV2jbl36a1g2JujW0/aiU4OIbfs/Kzoc+sw4IJxOZ0fb+1olA9tFzT74v3/WOMQ0 8zx9MrWwbLwpBoDDAl8/WppLd0pa9G9eIBNXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hFFJHOChNr31D55Wij21cwRIzO0R1d+hXi613ztQYVutPLtz1wT0afJVDrUA68lBZJ ZL+WfPVDeIlcWS2aqqVk2UlcKs4KCp65QE12qecLYdNCn+dghrtH2EV6v0nJyC7JNU1q 0g4gEXKutsypaAc7UzmvO7FaqeEmTNFEvhkbA= MIME-Version: 1.0 Received: by 10.239.139.89 with SMTP id s25mr665802hbs.113.1260153911826; Sun, 06 Dec 2009 18:45:11 -0800 (PST) In-Reply-To: <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B183C57.4090100@stpeter.im> <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> Date: Sun, 6 Dec 2009 18:45:11 -0800 Message-ID: <1bc4603e0912061845j768606ddn891ea1a1ab813cf5@mail.gmail.com> From: Chris Messina To: Richard Barnes Content-Type: multipart/alternative; boundary=001485f6cd8c46d997047a1a726b Cc: Idan Gazit , oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 02:45:27 -0000 --001485f6cd8c46d997047a1a726b Content-Type: text/plain; charset=ISO-8859-1 Richard, that ASCII art is top notch. Nice! ;) Idan: what software did you use to make your flow? Would you mind sharing the originals? I might make a few tweaks to see if I can make parts of the diagram a bit more legible...! Thanks, Chris On Sun, Dec 6, 2009 at 6:39 PM, Richard Barnes wrote: > Ask and ye shall receive: > > > (Updated terminology to match draft-hammer-oauth, i.e., s/Consumer/Client/ > and s/Service Provider/Server/) > > > > On Dec 3, 2009, at 5:31 PM, Peter Saint-Andre wrote: > > >> >> On 12/1/09 5:21 PM, Idan Gazit wrote: >> >>> Hey folks, >>> >>> I redrew/updated an old diagram >>> (http://documentation.fring.com/images/1/11/Oauth_diagram.png) outlining >>> the OAuth authentication flow. The old one didn't reflect the changes in >>> 1.0a. >>> >>> The updated diagrams are here: >>> >>> http://s3.pixane.com/Oauth_diagram.png >>> http://s3.pixane.com/Oauth_diagram.pdf >>> >> >> Your diagrams are very helpful. Now we just need to convert them to >> ASCII art for inclusion in an Internet-Draft. ;-) >> >> Please feel free to use them, I hereby place them in the public domain. >>> >> >> That's cool, too! >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --001485f6cd8c46d997047a1a726b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Richard, that ASCII art is top notch. Nice! ;)

Idan: wha= t software did you use to make your flow? Would you mind sharing the origin= als? I might make a few tweaks to see if I can make parts of the diagram a = bit more legible...!

Thanks,

Chris

On Sun, Dec 6, 2009 at 6:39 PM, Richard Barnes <rbarnes@bbn.com> wrote:
Ask and ye shall receive:
<http://geopriv.dreamhosters.com/Oauth_diagram.txt>

(Updated terminology to match draft-hammer-oauth, i.e., s/Consumer/Client/ = and s/Service Provider/Server/)



On Dec 3, 2009, at 5:31 PM, Peter Saint-Andre wrote:

<hat type=3D'individual'/>

On 12/1/09 5:21 PM, Idan Gazit wrote:
Hey folks,

I redrew/updated an old diagram
(http://documentation.fring.com/images/1/11/Oauth_diagram.p= ng) outlining
the OAuth authentication flow. The old one didn't reflect the changes i= n
1.0a.

The updated diagrams are here:

http:/= /s3.pixane.com/Oauth_diagram.png
http:/= /s3.pixane.com/Oauth_diagram.pdf

Your diagrams are very helpful. Now we just need to convert them to
ASCII art for inclusion in an Internet-Draft. ;-)

Please feel free to use them, I hereby place them in the public domain.

That's cool, too!

Peter

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
Chris Messi= na
Open Web Advocate

Personal: = http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagen= cy.com
Diso Project: http://diso= -project.org
OpenID Foundation: http:/= /openid.net

This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private
--001485f6cd8c46d997047a1a726b-- From rbarnes@bbn.com Sun Dec 6 18:49:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B57D3A69EE for ; Sun, 6 Dec 2009 18:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNPy9tMKt4wB for ; Sun, 6 Dec 2009 18:49:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 318FF3A697F for ; Sun, 6 Dec 2009 18:49:36 -0800 (PST) Received: from [128.89.253.201] (helo=[172.27.15.171]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NHTfA-0004lt-CA; Sun, 06 Dec 2009 21:49:24 -0500 Message-Id: <8765C8ED-55C1-4901-B678-545A3B2511DB@bbn.com> From: Richard Barnes To: Chris Messina In-Reply-To: <1bc4603e0912061845j768606ddn891ea1a1ab813cf5@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-526606615 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 6 Dec 2009 21:49:24 -0500 References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B183C57.4090100@stpeter.im> <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> <1bc4603e0912061845j768606ddn891ea1a1ab813cf5@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: Idan Gazit , oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 02:49:37 -0000 --Apple-Mail-1-526606615 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The software was MacVim :) Based on Idan's pictures at the top of this thread, namely: Good luck revising. Remember that you need to stay within 60 rows / 72 columns to fit in the RFC format! --Richard On Dec 6, 2009, at 9:45 PM, Chris Messina wrote: > Richard, that ASCII art is top notch. Nice! ;) > > Idan: what software did you use to make your flow? Would you mind > sharing the originals? I might make a few tweaks to see if I can > make parts of the diagram a bit more legible...! > > Thanks, > > Chris > > On Sun, Dec 6, 2009 at 6:39 PM, Richard Barnes > wrote: > Ask and ye shall receive: > > > (Updated terminology to match draft-hammer-oauth, i.e., s/Consumer/ > Client/ and s/Service Provider/Server/) > > > > On Dec 3, 2009, at 5:31 PM, Peter Saint-Andre wrote: > > > > On 12/1/09 5:21 PM, Idan Gazit wrote: > Hey folks, > > I redrew/updated an old diagram > (http://documentation.fring.com/images/1/11/Oauth_diagram.png) > outlining > the OAuth authentication flow. The old one didn't reflect the > changes in > 1.0a. > > The updated diagrams are here: > > http://s3.pixane.com/Oauth_diagram.png > http://s3.pixane.com/Oauth_diagram.pdf > > Your diagrams are very helpful. Now we just need to convert them to > ASCII art for inclusion in an Internet-Draft. ;-) > > Please feel free to use them, I hereby place them in the public > domain. > > That's cool, too! > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Chris Messina > Open Web Advocate > > Personal: http://factoryjoe.com > Follow me on Twitter: http://twitter.com/chrismessina > > Citizen Agency: http://citizenagency.com > Diso Project: http://diso-project.org > OpenID Foundation: http://openid.net > > This email is: [ ] shareable [X] ask first [ ] private --Apple-Mail-1-526606615 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
The software was MacVim = :)

Based on Idan's pictures at the top of this = thread, namely:

Good luck revising. =  Remember that you need to stay within 60 rows / 72 columns to fit = in the RFC format!

--Richard



On Dec 6, 2009, at 9:45 PM, = Chris Messina wrote:

Richard, = that ASCII art is top notch. Nice! ;)

Idan: what = software did you use to make your flow? Would you mind sharing the = originals? I might make a few tweaks to see if I can make parts of the = diagram a bit more legible...!
=

Thanks,

Chris

On Sun, Dec 6, 2009 at 6:39 PM, Richard Barnes = <rbarnes@bbn.com> = wrote:
Ask and ye shall = receive:
<http://geopriv.dreamhosters.com/Oauth_diagram.txt>= ;

(Updated terminology to match draft-hammer-oauth, i.e., = s/Consumer/Client/ and s/Service Provider/Server/)



On Dec 3, 2009, at 5:31 PM, Peter = Saint-Andre wrote:

<hat = type=3D'individual'/>

On 12/1/09 5:21 PM, Idan Gazit = wrote:
Hey folks,

I redrew/updated an old diagram
(http://documentation.fring.com/images/1/11/Oauth_diagram= .png) outlining
the OAuth authentication flow. The old one = didn't reflect the changes in
1.0a.

The updated diagrams = are here:

http://s3.pixane.com/Oauth_diagram.png
http://s3.pixane.com/Oauth_diagram.pdf
=

Your diagrams are very helpful. Now we just need to = convert them to
ASCII art for inclusion in an Internet-Draft. = ;-)

Please feel free to = use them, I hereby place them in the public domain.
=
That's cool, too!

Peter

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


_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=

= _______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=



--
Chris = Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on = Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso = Project: http://diso-project.org
OpenID = Foundation: http://openid.net
=
This email is:   [ ] shareable    [X] ask first =   [ ] private

= --Apple-Mail-1-526606615-- From chris.messina@gmail.com Sun Dec 6 19:10:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00193A698D for ; Sun, 6 Dec 2009 19:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5hgw7Us1-wQ for ; Sun, 6 Dec 2009 19:10:10 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id C55113A68DA for ; Sun, 6 Dec 2009 19:10:09 -0800 (PST) Received: by fxm5 with SMTP id 5so4515264fxm.28 for ; Sun, 06 Dec 2009 19:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zu0O3y55zI2A1ZcoLZ7KMv5iTRryCm44GLQSq0xwkKs=; b=XxeCPDYYbjKNnaXfilZvE8QQmz2tcVEK/N+sGXx7BOHjNTnh3zWtrwDSo6NHBj/9vR Jp2UDREoiW2JvqUyKEGdWuKUr/c5wvkoEYK/62aWpH/KBsM8fmneILIwMJyxTJ/Rx1Of ywgaYoNEqWXKgmbvoCWZjl6wT/HoIRPY6EC5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f3D1TJg/mlP1ggQfxMWcy2Jwc5P/9XWFo3wICVg832lgYCQYsChNfOYWYRynUL40da xmurok8Jz6Hr+fKt2N1xBm5obPFqzXFNBYNqUdanvt+rdakNebxbQeQPMg9LqGngV9X0 71deuaWNflt+c2S9pEQDisjpt8wd+TUAZOdQU= MIME-Version: 1.0 Received: by 10.239.190.216 with SMTP id y24mr594005hbh.185.1260155396828; Sun, 06 Dec 2009 19:09:56 -0800 (PST) In-Reply-To: <8765C8ED-55C1-4901-B678-545A3B2511DB@bbn.com> References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B183C57.4090100@stpeter.im> <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> <1bc4603e0912061845j768606ddn891ea1a1ab813cf5@mail.gmail.com> <8765C8ED-55C1-4901-B678-545A3B2511DB@bbn.com> Date: Sun, 6 Dec 2009 19:09:56 -0800 Message-ID: <1bc4603e0912061909q1f714f87qdf647a0ac3dc8123@mail.gmail.com> From: Chris Messina To: Richard Barnes Content-Type: multipart/alternative; boundary=001485f772a2ca3010047a1acabc Cc: Idan Gazit , oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 03:10:12 -0000 --001485f772a2ca3010047a1acabc Content-Type: text/plain; charset=ISO-8859-1 Ah, sorry, I meant revising Idan's PDF version... not the ASCII version. ;) On Sun, Dec 6, 2009 at 6:49 PM, Richard Barnes wrote: > The software was MacVim :) > > Based on Idan's pictures at the top of this thread, namely: > > > Good luck revising. Remember that you need to stay within 60 rows / 72 > columns to fit in the RFC format! > > > --Richard > > > > On Dec 6, 2009, at 9:45 PM, Chris Messina wrote: > > Richard, that ASCII art is top notch. Nice! ;) > > Idan: what software did you use to make your flow? Would you mind sharing > the originals? I might make a few tweaks to see if I can make parts of the > diagram a bit more legible...! > > Thanks, > > Chris > > On Sun, Dec 6, 2009 at 6:39 PM, Richard Barnes wrote: > >> Ask and ye shall receive: >> >> >> (Updated terminology to match draft-hammer-oauth, i.e., s/Consumer/Client/ >> and s/Service Provider/Server/) >> >> >> >> On Dec 3, 2009, at 5:31 PM, Peter Saint-Andre wrote: >> >> >>> >>> On 12/1/09 5:21 PM, Idan Gazit wrote: >>> >>>> Hey folks, >>>> >>>> I redrew/updated an old diagram >>>> (http://documentation.fring.com/images/1/11/Oauth_diagram.png) >>>> outlining >>>> the OAuth authentication flow. The old one didn't reflect the changes in >>>> 1.0a. >>>> >>>> The updated diagrams are here: >>>> >>>> http://s3.pixane.com/Oauth_diagram.png >>>> http://s3.pixane.com/Oauth_diagram.pdf >>>> >>> >>> Your diagrams are very helpful. Now we just need to convert them to >>> ASCII art for inclusion in an Internet-Draft. ;-) >>> >>> Please feel free to use them, I hereby place them in the public domain. >>>> >>> >>> That's cool, too! >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Chris Messina > Open Web Advocate > > Personal: http://factoryjoe.com > Follow me on Twitter: http://twitter.com/chrismessina > > Citizen Agency: http://citizenagency.com > Diso Project: http://diso-project.org > OpenID Foundation: http://openid.net > > This email is: [ ] shareable [X] ask first [ ] private > > > -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --001485f772a2ca3010047a1acabc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ah, sorry, I meant revising Idan's PDF version... not the ASCII version= . ;)

On Sun, Dec 6, 2009 at 6:49 PM, Rich= ard Barnes <rbarnes= @bbn.com> wrote:
Th= e software was MacVim :)

Based on Idan's pictu= res at the top of this thread, namely:

Good luck revising. =A0Remember= that you need to stay within 60 rows / 72 columns to fit in the RFC format= !

--Richard



On Dec 6, 2009, at 9:45 PM, Chr= is Messina wrote:

Richard, that ASCII ar= t is top notch. Nice! ;)

Idan: what software did you use= to make your flow? Would you mind sharing the originals? I might make a fe= w tweaks to see if I can make parts of the diagram a bit more legible...!

Thanks,

Chris

On Sun, Dec 6, 2009 at 6:39 PM, Richard Barnes <rbarnes@b= bn.com> wrote:
Ask and ye shall receive:
<ht= tp://geopriv.dreamhosters.com/Oauth_diagram.txt>

(Updated terminology to match draft-hammer-oauth, i.e., s/Consumer/Cl= ient/ and s/Service Provider/Server/)



On= Dec 3, 2009, at 5:31 PM, Peter Saint-Andre wrote:

<hat type=3D'individual'/>

On 12/1/09 5:21 PM,= Idan Gazit wrote:
Hey folks,

I redrew/updated an old diagram
(h= ttp://documentation.fring.com/images/1/11/Oauth_diagram.png) outlining<= br> the OAuth authentication flow. The old one didn't reflect the changes = in
1.0a.

The updated diagrams are here:

http://s3.pixane.co= m/Oauth_diagram.png
http:= //s3.pixane.com/Oauth_diagram.pdf

Your diagrams = are very helpful. Now we just need to convert them to
ASCII art for inc= lusion in an Internet-Draft. ;-)

Please feel free to use them, I hereb= y place them in the public domain.

That's cool, = too!

Peter

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


=
_______________________________________________
OAuth mailing lis= t
OAuth@ietf.org
= = https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth = mailing list
OAuth@= ietf.org
https://www.ietf.org/mailman/listinfo/oauth



--
Chris Mess= ina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com= /chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation:= http://openid.net

This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private<= br>


<= br clear=3D"all">
--
Chris Messina
Open Web Advocate

Perso= nal: http://factoryjoe.com
Follow me on Twitter: http://tw= itter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net
<= br>This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private --001485f772a2ca3010047a1acabc-- From idan@pixane.com Mon Dec 7 00:12:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096373A6A15 for ; Mon, 7 Dec 2009 00:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tP69q0qVHBo for ; Mon, 7 Dec 2009 00:12:41 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id DE2BB28C0DD for ; Mon, 7 Dec 2009 00:12:40 -0800 (PST) Received: by fxm5 with SMTP id 5so4651352fxm.28 for ; Mon, 07 Dec 2009 00:12:27 -0800 (PST) Received: by 10.102.240.34 with SMTP id n34mr1151060muh.124.1260173547092; Mon, 07 Dec 2009 00:12:27 -0800 (PST) Received: from ?192.168.1.10? (bzq-80-62-53.red.bezeqint.net [82.80.62.53]) by mx.google.com with ESMTPS id t10sm2095919muh.2.2009.12.07.00.12.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 00:12:26 -0800 (PST) Message-Id: From: Idan Gazit To: Chris Messina In-Reply-To: <1bc4603e0912061845j768606ddn891ea1a1ab813cf5@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 10:12:24 +0200 References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B183C57.4090100@stpeter.im> <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> <1bc4603e0912061845j768606ddn891ea1a1ab813cf5@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 08:12:42 -0000 Chris, I used OmniGraffle. I've put the original up here: http://s3.pixane.com/Oauth_diagram.graffle.zip The only catch is that I've used some commercial fonts: Museo Sans 900 (commercial) Museo 100 (commercial) League Gothic (free, http://bit.ly/league_gothic) I'm happy to make changes, what parts of the diagram bother you? -I On Dec 7, 2009, at 4:45 AM, Chris Messina wrote: > > Idan: what software did you use to make your flow? Would you mind > sharing the originals? I might make a few tweaks to see if I can > make parts of the diagram a bit more legible...! > From idan@pixane.com Mon Dec 7 00:13:54 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F262628C0DD for ; Mon, 7 Dec 2009 00:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643, SARE_RECV_BEZEQINT_B=0.763] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnEULfoa67vT for ; Mon, 7 Dec 2009 00:13:53 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id DE8C03A67E1 for ; Mon, 7 Dec 2009 00:13:52 -0800 (PST) Received: by fxm5 with SMTP id 5so4652076fxm.28 for ; Mon, 07 Dec 2009 00:13:38 -0800 (PST) Received: by 10.103.48.26 with SMTP id a26mr1980508muk.83.1260173617781; Mon, 07 Dec 2009 00:13:37 -0800 (PST) Received: from ?192.168.1.10? (bzq-80-62-53.red.bezeqint.net [82.80.62.53]) by mx.google.com with ESMTPS id e8sm3952958muf.28.2009.12.07.00.13.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 00:13:37 -0800 (PST) Message-Id: <47014464-E795-46E9-8D7A-1893C6F7B17F@pixane.com> From: Idan Gazit To: Richard Barnes In-Reply-To: <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 10:13:34 +0200 References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B183C57.4090100@stpeter.im> <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> X-Mailer: Apple Mail (2.936) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 08:13:54 -0000 Hey, that's awesome. Should I update to match? On Dec 7, 2009, at 4:39 AM, Richard Barnes wrote: > Ask and ye shall receive: > > > (Updated terminology to match draft-hammer-oauth, i.e., s/Consumer/ > Client/ and s/Service Provider/Server/) From eran@hueniverse.com Mon Dec 7 00:27:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC673A6A12 for ; Mon, 7 Dec 2009 00:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.967 X-Spam-Level: X-Spam-Status: No, score=-2.967 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OGQH6pPrQ5q for ; Mon, 7 Dec 2009 00:27:46 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DD85B3A6898 for ; Mon, 7 Dec 2009 00:27:45 -0800 (PST) Received: (qmail 13788 invoked from network); 7 Dec 2009 08:27:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Dec 2009 08:27:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 7 Dec 2009 01:27:31 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 7 Dec 2009 01:27:57 -0700 Thread-Topic: Token Access Authentication Scheme Draft Thread-Index: Acp3Fy41mhoVRFEVTsOZ4fl/+l3K7w== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 08:27:46 -0000 http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt This draft is my first attempt at defining a general purpose authentication= scheme to fulfill the WG requirement to produce a scheme suitable for 2-le= gged authentication. It also supports the OAuth 3-legged use cases as discu= ssed on the list. This draft is in very early stage and has been submitted = early to help better facilitate the conversation. It has been hard for us to discuss ideas without a concrete proposal. I hop= e this will help and motivate people to participate and provide feedback an= d new ideas. While there are many holes in the draft, it should be pretty e= asy to follow it. Major changes from OAuth 1.0: * New auth scheme with new parameter names * Signature base string replaced with normalized request string, and now do= es not require *any* encoding * Supports multiple token classes, authentication methods, and coverage sco= pe Main feedback requested: * Initial impressions - this is particularly important to get. Does the dra= ft make sense? * Functionality - does it include all the requested/required functionality? * Abstraction level - do the attributes provide the right level of configur= ation and choice? Please refrain from editorial feedback at this point (grammar, typos, etc.)= , but do provide structural feedback. I plan to push an updated version by Wed which will incorporate as much fee= dback as I can. I plan to ask for the WG to promote this draft to a WG item= within 2 weeks. Thanks, EHL From stephen.farrell@cs.tcd.ie Mon Dec 7 02:35:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4956228C129 for ; Mon, 7 Dec 2009 02:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gva3p0nmtVg2 for ; Mon, 7 Dec 2009 02:35:25 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 96B813A681F for ; Mon, 7 Dec 2009 02:35:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 8700A3600B9; Mon, 7 Dec 2009 10:35:14 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNZfKH5wPois; Mon, 7 Dec 2009 10:35:14 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id BA0DB3600B8; Mon, 7 Dec 2009 10:35:13 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id B64BC7C315; Mon, 7 Dec 2009 10:35:13 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naik7cVpasIm; Mon, 7 Dec 2009 10:35:13 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id E9A5C7C12D; Mon, 7 Dec 2009 10:35:12 +0000 (GMT) Message-ID: <4B1CDA67.3050800@cs.tcd.ie> Date: Mon, 07 Dec 2009 10:35:19 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Phillip Hallam-Baker References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 10:35:26 -0000 Phillip Hallam-Baker wrote: > The problem with solving Basic Auth is that patent trolls are sitting > on the technologies you would want to use instead. So I wonder if anyone would be interested in an EKE based scheme? I mean interested enough that it'd get deployed. The timing might be good for that now. S. From stephen.farrell@cs.tcd.ie Mon Dec 7 02:54:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE11728C136 for ; Mon, 7 Dec 2009 02:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfkJZIOc9PBR for ; Mon, 7 Dec 2009 02:54:38 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 4ED7C28C126 for ; Mon, 7 Dec 2009 02:54:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 961A73600BA; Mon, 7 Dec 2009 10:54:27 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyrpY3285P4H; Mon, 7 Dec 2009 10:54:26 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id CE03B3600B9; Mon, 7 Dec 2009 10:54:26 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id CA9477C315; Mon, 7 Dec 2009 10:54:26 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hPM9zVfc7DP; Mon, 7 Dec 2009 10:54:26 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id 0D0B07C30A; Mon, 7 Dec 2009 10:54:26 +0000 (GMT) Message-ID: <4B1CDEE7.5010702@cs.tcd.ie> Date: Mon, 07 Dec 2009 10:54:31 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 10:54:46 -0000 Eran Hammer-Lahav wrote: > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt > I think that's a really good start & that the WG should adopt it. One thing that this suggests to me is that for cases where the client and server do have a shared secret, but are not running over TLS, (or where TLS is terminated before the actual server), we could use that shared secret to protect the response in a similar way to the request. I've no idea if folks think that'd be useful enough to be worth doing or not (and I'd be a little leery of it myself since it de-motivates turning on TLS), nor whether it would belong in this spec or this WG, but I think its worthwhile asking since I suspect that compromised on-path proxies might become a more common attack vector in future. S. > This draft is my first attempt at defining a general purpose authentication scheme to fulfill the WG requirement to produce a scheme suitable for 2-legged authentication. It also supports the OAuth 3-legged use cases as discussed on the list. This draft is in very early stage and has been submitted early to help better facilitate the conversation. > > It has been hard for us to discuss ideas without a concrete proposal. I hope this will help and motivate people to participate and provide feedback and new ideas. While there are many holes in the draft, it should be pretty easy to follow it. > > Major changes from OAuth 1.0: > > * New auth scheme with new parameter names > * Signature base string replaced with normalized request string, and now does not require *any* encoding > * Supports multiple token classes, authentication methods, and coverage scope > > Main feedback requested: > > * Initial impressions - this is particularly important to get. Does the draft make sense? > * Functionality - does it include all the requested/required functionality? > * Abstraction level - do the attributes provide the right level of configuration and choice? > > Please refrain from editorial feedback at this point (grammar, typos, etc.), but do provide structural feedback. > > I plan to push an updated version by Wed which will incorporate as much feedback as I can. I plan to ask for the WG to promote this draft to a WG item within 2 weeks. > > Thanks, > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From James.H.Manger@team.telstra.com Mon Dec 7 05:20:27 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13433A67B5 for ; Mon, 7 Dec 2009 05:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJdEaBybSHyD for ; Mon, 7 Dec 2009 05:20:27 -0800 (PST) Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by core3.amsl.com (Postfix) with ESMTP id AC7893A67B1 for ; Mon, 7 Dec 2009 05:20:26 -0800 (PST) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipai.vtcif.telstra.com.au with ESMTP; 08 Dec 2009 00:19:14 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 68AA61DA82; Tue, 8 Dec 2009 00:19:14 +1100 (EST) Received: from WSMSG3755.srv.dir.telstra.com (wsmsg3755.srv.dir.telstra.com [172.49.40.196]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 3668E41E0E; Tue, 8 Dec 2009 00:18:50 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 8 Dec 2009 00:19:13 +1100 From: "Manger, James H" To: Stephen Farrell , "OAuth WG (oauth@ietf.org)" , Phillip Hallam-Baker Date: Tue, 8 Dec 2009 00:19:11 +1100 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp3KPs8ahYI7zbiTymyQA5ObeXDnQAEmpeA Message-ID: <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> In-Reply-To: <4B1CDA67.3050800@cs.tcd.ie> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 13:20:27 -0000 PiBQaGlsbGlwIEhhbGxhbS1CYWtlciB3cm90ZToNCj4gPiBUaGUgcHJvYmxlbSB3aXRoIHNvbHZp bmcgQmFzaWMgQXV0aCBpcyB0aGF0IHBhdGVudCB0cm9sbHMgYXJlIHNpdHRpbmcNCj4gPiBvbiB0 aGUgdGVjaG5vbG9naWVzIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBpbnN0ZWFkLg0KPiANCj4gU28g SSB3b25kZXIgaWYgYW55b25lIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gYW4gRUtFIGJhc2VkIHNj aGVtZT8NCj4gSSBtZWFuIGludGVyZXN0ZWQgZW5vdWdoIHRoYXQgaXQnZCBnZXQgZGVwbG95ZWQu IFRoZSB0aW1pbmcgbWlnaHQNCj4gYmUgZ29vZCBmb3IgdGhhdCBub3cuDQoNClNSUCAoU2VjdXJl IFJlbW90ZSBQYXNzd29yZCkgaGFzIGJlZW4gc3BlY2lmaWVkIHRvIHdvcmsgd2l0aCBUTFMgaW4g UkZDIDUwNTQgW25vdGU6IG5vIGNsaWVudCBvciBzZXJ2ZXIgY2VydGlmaWNhdGVzIHJlcXVpcmVk XS4NClRoaXMgY2xhc3NpZmllcyBhcyBhbiBFS0UgYmFzZWQgc2NoZW1lIGRvZXNuJ3QgaXQ/DQoN ClNSUCBpbiBUTFMgc2VjdXJlcyBhIGNvbm5lY3Rpb24gdXNpbmcgYSBwYXNzd29yZC4gSXQgdXNl cyBhIGhhbmRzaGFrZSBjb25zaXN0aW5nIG9mIGEgZmV3IHJvdW5kIHRyaXBzIHRvIHdvcmsuIEl0 IGlzIG5vdCBzdWl0YWJsZSBmb3IgcHJvdGVjdGluZyBhIHN0YW5kYWxvbmUgcmVxdWVzdC4NCg0K Rm9yIHByb3RlY3RpbmcgYSBzdGFuZGFsb25lIHJlcXVlc3QsIHdpdGhvdXQgYW55IGNoYWxsZW5n ZSBmcm9tIHRoZSBzZXJ2ZXIsIHRoZSBiZXN0IHlvdSBjYW4gZG8gaXQgcnVuIGEgcGFzc3dvcmQt YmFzZWQga2V5IGRlcml2YXRpb24gZnVuY3Rpb24gKFBCS0RGKSAocnVubmluZyBhIGhhc2ggYWxn b3JpdGhtIGZvciBtYW55IHRob3VzYW5kcyBvZiBpdGVyYXRpb25zKSB0aGVuIHVzZSB0aGUgcmVz dWx0aW5nIGtleSB0byBjYWxjdWxhdGUgYSBNQUMgb3ZlciB0aGUgcmVxdWVzdC4NCg0KSSB0aGlu ayB0aGUgcGFzc3dvcmQtcHJvdGVjdGlvbiBmZWF0dXJlIGluIHRoZSBsYXRlc3QgdmVyc2lvbnMg b2YgTWljcm9zb2Z0IE9mZmljZSBkbyBhYm91dCBhcyBnb29kIGEgam9iIGFzIGlzIHBvc3NpYmxl IGZvciB0aGUgc3RhbmRhbG9uZSByZXF1ZXN0IHNjZW5hcmlvICh3aGljaCBpcyBiYXNpY2FsbHkg dGhlIHNhbWUgc2NlbmFyaW8gYXMgcHJvdGVjdGluZyBhIHN0YW5kYWxvbmUgZmlsZSkuIEkgY2Fu J3QgcmVtZW1iZXIgZXhhY3RseSB3aGljaCBQQktERiB0aGV5IHVzZSBvciBob3cgbWFueSBpdGVy YXRpb25zIC0tIGJ1dCB3YXMgbWFueSwgbWFueSBvcmRlcnMgb2YgbWFnbml0dWRlIGJldHRlciB0 aGFuIGVhcmxpZXIgKDIwMDM/KSB2ZXJzaW9ucy4NCg0KDQotLSANCkphbWVzIE1hbmdlcg0K From rbarnes@bbn.com Mon Dec 7 06:13:11 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A995E3A68B6 for ; Mon, 7 Dec 2009 06:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcnbHr63h2AU for ; Mon, 7 Dec 2009 06:13:10 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C46F93A67E3 for ; Mon, 7 Dec 2009 06:13:10 -0800 (PST) Received: from [128.89.253.93] (helo=[192.168.0.198]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NHeKh-0000Dj-Bv; Mon, 07 Dec 2009 09:12:59 -0500 Message-Id: <1C21C830-DF7F-4B6F-8FBD-E57FD0E2C52B@bbn.com> From: Richard Barnes To: Idan Gazit In-Reply-To: <47014464-E795-46E9-8D7A-1893C6F7B17F@pixane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 09:12:59 -0500 References: <42D0D54E-BD07-41E2-A823-F6AD3365D833@pixane.com> <4B183C57.4090100@stpeter.im> <84446155-80D9-42BA-8889-B2C12E5BDCAC@bbn.com> <47014464-E795-46E9-8D7A-1893C6F7B17F@pixane.com> X-Mailer: Apple Mail (2.936) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 1.0a flow diagram X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 14:13:11 -0000 I like consistency of terminology. If we're trying to get people to move over to using the IETF spec, then it's probably a good idea to change the terms to match. The mapping is pretty simple; quoting from draft-hammer-oauth-08: " The original community specification used a somewhat different terminology which maps to this specifications as follows (original community terms provided on left): Consumer: client Service Provider: server User: resource owner Consumer Key and Secret: client credentials Request Token and Secret: temporary credentials Access Token and Secret: token credentials " On Dec 7, 2009, at 3:13 AM, Idan Gazit wrote: > Hey, that's awesome. > > Should I update to match? > > On Dec 7, 2009, at 4:39 AM, Richard Barnes wrote: > >> Ask and ye shall receive: >> >> >> (Updated terminology to match draft-hammer-oauth, i.e., s/Consumer/ >> Client/ and s/Service Provider/Server/) > From faynberg@alcatel-lucent.com Mon Dec 7 07:15:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40C6128C197 for ; Mon, 7 Dec 2009 07:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2oFxtJRm7pq for ; Mon, 7 Dec 2009 07:15:44 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 5485728C181 for ; Mon, 7 Dec 2009 07:15:44 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nB7FFURr025912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Dec 2009 09:15:30 -0600 (CST) Received: from [135.244.34.0] (faynberg.lra.lucent.com [135.244.34.0]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nB7FFTTZ017048; Mon, 7 Dec 2009 09:15:29 -0600 (CST) Message-ID: <4B1D1C10.9050903@alcatel-lucent.com> Date: Mon, 07 Dec 2009 10:15:28 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stephen Farrell References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> In-Reply-To: <4B1CDA67.3050800@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: Phillip Hallam-Baker , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 15:15:45 -0000 Well, I was about to propose this, but Stephen beat me! Yes, I think that EKE is one way of getting there, and I wanted to add for a consideration a protocol from the same family, PAK, that has been deployed (as part of Inferno and Plan 9 operating systems in Open Source) and standardized by 3GPP2 and ITU-T. We have described it in the IETF RFC RFC 5683 (which was supposed to be published, but is waiting for some bureaucratic stamp beyond the IETF and RFC Editor reach). The final text is in http://tools.ietf.org/html/draft-brusilovsky-pak-10. PAK is using a password to 1) authenticate the D-H and 2) create a session key, based on the password. Igor Stephen Farrell wrote: > Phillip Hallam-Baker wrote: > >> The problem with solving Basic Auth is that patent trolls are sitting >> on the technologies you would want to use instead. >> > > So I wonder if anyone would be interested in an EKE based scheme? > I mean interested enough that it'd get deployed. The timing might > be good for that now. > > S. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From stephen.farrell@cs.tcd.ie Mon Dec 7 07:56:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8461828C198 for ; Mon, 7 Dec 2009 07:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8h9WRkU-6Tej for ; Mon, 7 Dec 2009 07:56:24 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 408053A6A45 for ; Mon, 7 Dec 2009 07:56:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id 0CE9B3600BD; Mon, 7 Dec 2009 15:56:13 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO+ZyBeNk1VD; Mon, 7 Dec 2009 15:56:12 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id 1250C36008A; Mon, 7 Dec 2009 15:56:12 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id 04AE27C334; Mon, 7 Dec 2009 15:56:12 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdZ-koXxvbKi; Mon, 7 Dec 2009 15:56:11 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id 373147C333; Mon, 7 Dec 2009 15:56:11 +0000 (GMT) Message-ID: <4B1D25A2.200@cs.tcd.ie> Date: Mon, 07 Dec 2009 15:56:18 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: faynberg@alcatel-lucent.com References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <4B1D1C10.9050903@alcatel-lucent.com> In-Reply-To: <4B1D1C10.9050903@alcatel-lucent.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 15:56:25 -0000 Igor Faynberg wrote: > Well, I was about to propose this, but Stephen beat me! > > Yes, I think that EKE is one way of getting there, and I wanted to add > for a consideration a protocol from the same family, PAK, that has been > deployed (as part of Inferno and Plan 9 operating systems in Open > Source) and standardized by 3GPP2 and ITU-T. We have described it in > the IETF RFC RFC 5683 (which was supposed to be published, but is > waiting for some bureaucratic stamp beyond the IETF and RFC Editor > reach). The final text is in > http://tools.ietf.org/html/draft-brusilovsky-pak-10. ...which references https://datatracker.ietf.org/ipr/1179/ Doing exactly EKE [1] (and no more) on the other hand may be cleaner. However, James' points are relevant - these protocols are not really single shot, though might still fit a bunch of OAuth use-cases for token acquisition since that will often involve a couple of exchanges. S. [1] http://www.freepatentsonline.com/5241599.html > > PAK is using a password to 1) authenticate the D-H and 2) create a > session key, based on the password. > > Igor > > Stephen Farrell wrote: >> Phillip Hallam-Baker wrote: >> >>> The problem with solving Basic Auth is that patent trolls are sitting >>> on the technologies you would want to use instead. >>> >> >> So I wonder if anyone would be interested in an EKE based scheme? >> I mean interested enough that it'd get deployed. The timing might >> be good for that now. >> >> S. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From eran@hueniverse.com Mon Dec 7 08:07:07 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDD93A68D8 for ; Mon, 7 Dec 2009 08:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFRa4IKzVtQr for ; Mon, 7 Dec 2009 08:07:06 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 73FA43A6853 for ; Mon, 7 Dec 2009 08:07:06 -0800 (PST) Received: (qmail 15173 invoked from network); 7 Dec 2009 16:06:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Dec 2009 16:06:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 7 Dec 2009 09:06:55 -0700 From: Eran Hammer-Lahav To: Stephen Farrell Date: Mon, 7 Dec 2009 09:07:23 -0700 Thread-Topic: [OAUTH-WG] Token Access Authentication Scheme Draft Thread-Index: Acp3K6dZTHuAQFurQNiPDdFNAgD8CAAKw0FQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852939C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDEE7.5010702@cs.tcd.ie> In-Reply-To: <4B1CDEE7.5010702@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:07:07 -0000 This has been proposed before in the security review for draft-hammer-oauth= . It should be pretty easy to add. My concern would be that the web develop= ers I know will never bother validating server responses. EHL > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, December 07, 2009 2:55 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft >=20 >=20 > Eran Hammer-Lahav wrote: > > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt > > >=20 > I think that's a really good start & that the WG should adopt it. >=20 > One thing that this suggests to me is that for cases where the client and > server do have a shared secret, but are not running over TLS, (or where T= LS is > terminated before the actual server), we could use that shared secret to > protect the response in a similar way to the request. >=20 > I've no idea if folks think that'd be useful enough to be worth doing or = not > (and I'd be a little leery of it myself since it de-motivates turning on = TLS), nor > whether it would belong in this spec or this WG, but I think its worthwhi= le > asking since I suspect that compromised on-path proxies might become a > more common attack vector in future. >=20 > S. >=20 >=20 > > This draft is my first attempt at defining a general purpose authentica= tion > scheme to fulfill the WG requirement to produce a scheme suitable for 2- > legged authentication. It also supports the OAuth 3-legged use cases as > discussed on the list. This draft is in very early stage and has been sub= mitted > early to help better facilitate the conversation. > > > > It has been hard for us to discuss ideas without a concrete proposal. I= hope > this will help and motivate people to participate and provide feedback an= d > new ideas. While there are many holes in the draft, it should be pretty e= asy > to follow it. > > > > Major changes from OAuth 1.0: > > > > * New auth scheme with new parameter names > > * Signature base string replaced with normalized request string, and > > now does not require *any* encoding > > * Supports multiple token classes, authentication methods, and > > coverage scope > > > > Main feedback requested: > > > > * Initial impressions - this is particularly important to get. Does the= draft > make sense? > > * Functionality - does it include all the requested/required functional= ity? > > * Abstraction level - do the attributes provide the right level of > configuration and choice? > > > > Please refrain from editorial feedback at this point (grammar, typos, e= tc.), > but do provide structural feedback. > > > > I plan to push an updated version by Wed which will incorporate as much > feedback as I can. I plan to ask for the WG to promote this draft to a WG= item > within 2 weeks. > > > > Thanks, > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > From stephen.farrell@cs.tcd.ie Mon Dec 7 08:14:51 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01CD28C198 for ; Mon, 7 Dec 2009 08:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgPqhwCaf0Ox for ; Mon, 7 Dec 2009 08:14:50 -0800 (PST) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id 869DB3A68E9 for ; Mon, 7 Dec 2009 08:14:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id B83373600BB; Mon, 7 Dec 2009 16:14:39 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q8Au0-uhsSh; Mon, 7 Dec 2009 16:14:37 +0000 (GMT) Received: from mail01.newbay.com (mail01.newbay.com [192.168.12.25]) by mail.newbay.com (Postfix) with ESMTP id DF5EA36008A; Mon, 7 Dec 2009 16:14:37 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail01.newbay.com (Postfix) with ESMTP id C41827C334; Mon, 7 Dec 2009 16:14:37 +0000 (GMT) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail01.newbay.com ([127.0.0.1]) by localhost (mail01.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS7+CAm+1v0j; Mon, 7 Dec 2009 16:14:37 +0000 (GMT) Received: from [192.168.3.23] (unknown [192.168.3.23]) by mail01.newbay.com (Postfix) with ESMTP id E10FC7C338; Mon, 7 Dec 2009 16:14:36 +0000 (GMT) Message-ID: <4B1D29F3.6060008@cs.tcd.ie> Date: Mon, 07 Dec 2009 16:14:43 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDEE7.5010702@cs.tcd.ie> <90C41DD21FB7C64BB94121FBBC2E723437852939C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852939C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:14:51 -0000 Eran Hammer-Lahav wrote: > This has been proposed before in the security review for draft-hammer-oauth. It should be pretty easy to add. My concern would be that the web developers I know will never bother validating server responses. That's a valid concern. Do you know why? I could imagine some mixture of the following: 1. their current applications aren't sensitive enough to bother doing this 2. lack of tools/APIs to make it easy to verify responses 3. responses get mangled so often so you'd never get many that actually verify 4. something else If #1 & #2 were the primary reasons I don't think those should mean not taking this on (not that I'm yet arguing that we should, I'm still just asking). #3 however would be a bit of a killer, as, I suppose, could #4:-) S. > > EHL > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Monday, December 07, 2009 2:55 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft >> >> >> Eran Hammer-Lahav wrote: >>> http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt >>> >> I think that's a really good start & that the WG should adopt it. >> >> One thing that this suggests to me is that for cases where the client and >> server do have a shared secret, but are not running over TLS, (or where TLS is >> terminated before the actual server), we could use that shared secret to >> protect the response in a similar way to the request. >> >> I've no idea if folks think that'd be useful enough to be worth doing or not >> (and I'd be a little leery of it myself since it de-motivates turning on TLS), nor >> whether it would belong in this spec or this WG, but I think its worthwhile >> asking since I suspect that compromised on-path proxies might become a >> more common attack vector in future. >> >> S. >> >> >>> This draft is my first attempt at defining a general purpose authentication >> scheme to fulfill the WG requirement to produce a scheme suitable for 2- >> legged authentication. It also supports the OAuth 3-legged use cases as >> discussed on the list. This draft is in very early stage and has been submitted >> early to help better facilitate the conversation. >>> It has been hard for us to discuss ideas without a concrete proposal. I hope >> this will help and motivate people to participate and provide feedback and >> new ideas. While there are many holes in the draft, it should be pretty easy >> to follow it. >>> Major changes from OAuth 1.0: >>> >>> * New auth scheme with new parameter names >>> * Signature base string replaced with normalized request string, and >>> now does not require *any* encoding >>> * Supports multiple token classes, authentication methods, and >>> coverage scope >>> >>> Main feedback requested: >>> >>> * Initial impressions - this is particularly important to get. Does the draft >> make sense? >>> * Functionality - does it include all the requested/required functionality? >>> * Abstraction level - do the attributes provide the right level of >> configuration and choice? >>> Please refrain from editorial feedback at this point (grammar, typos, etc.), >> but do provide structural feedback. >>> I plan to push an updated version by Wed which will incorporate as much >> feedback as I can. I plan to ask for the WG to promote this draft to a WG item >> within 2 weeks. >>> Thanks, >>> >>> EHL >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> > From eran@hueniverse.com Mon Dec 7 08:15:21 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7414628C18F for ; Mon, 7 Dec 2009 08:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw8H+OG5EXUY for ; Mon, 7 Dec 2009 08:15:20 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3515A28C1AD for ; Mon, 7 Dec 2009 08:15:20 -0800 (PST) Received: (qmail 25607 invoked from network); 7 Dec 2009 16:15:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Dec 2009 16:15:09 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 7 Dec 2009 09:15:08 -0700 From: Eran Hammer-Lahav To: Stephen Farrell , "faynberg@alcatel-lucent.com" Date: Mon, 7 Dec 2009 09:15:36 -0700 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp3VdFduE5KThvFSaOk6STOsySjCAAAjrJA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852939C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <4B1D1C10.9050903@alcatel-lucent.com> <4B1D25A2.200@cs.tcd.ie> In-Reply-To: <4B1D25A2.200@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Phillip Hallam-Baker , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:15:21 -0000 Any replacement to Basic auth we may consider for inclusion in the Token sc= heme must be a single request, and must be at a similar complexity level as= the current Token proposal. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Monday, December 07, 2009 7:56 AM > To: faynberg@alcatel-lucent.com > Cc: Phillip Hallam-Baker; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping > usernames >=20 >=20 >=20 > Igor Faynberg wrote: > > Well, I was about to propose this, but Stephen beat me! > > > > Yes, I think that EKE is one way of getting there, and I wanted to add > > for a consideration a protocol from the same family, PAK, that has > > been deployed (as part of Inferno and Plan 9 operating systems in Open > > Source) and standardized by 3GPP2 and ITU-T. We have described it in > > the IETF RFC RFC 5683 (which was supposed to be published, but is > > waiting for some bureaucratic stamp beyond the IETF and RFC Editor > > reach). The final text is in > > http://tools.ietf.org/html/draft-brusilovsky-pak-10. >=20 > ...which references https://datatracker.ietf.org/ipr/1179/ >=20 > Doing exactly EKE [1] (and no more) on the other hand may be cleaner. >=20 > However, James' points are relevant - these protocols are not really sing= le > shot, though might still fit a bunch of OAuth use-cases for token acquisi= tion > since that will often involve a couple of exchanges. >=20 > S. >=20 > [1] http://www.freepatentsonline.com/5241599.html >=20 > > > > PAK is using a password to 1) authenticate the D-H and 2) create a > > session key, based on the password. > > > > Igor > > > > Stephen Farrell wrote: > >> Phillip Hallam-Baker wrote: > >> > >>> The problem with solving Basic Auth is that patent trolls are > >>> sitting on the technologies you would want to use instead. > >>> > >> > >> So I wonder if anyone would be interested in an EKE based scheme? > >> I mean interested enough that it'd get deployed. The timing might be > >> good for that now. > >> > >> S. > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Dec 7 08:18:08 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA68028C1AC for ; Mon, 7 Dec 2009 08:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucwiYB6e43Oc for ; Mon, 7 Dec 2009 08:18:08 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3143D28C198 for ; Mon, 7 Dec 2009 08:18:08 -0800 (PST) Received: (qmail 30645 invoked from network); 7 Dec 2009 16:17:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Dec 2009 16:17:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 7 Dec 2009 09:17:57 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , Stephen Farrell , "OAuth WG (oauth@ietf.org)" , Phillip Hallam-Baker Date: Mon, 7 Dec 2009 09:18:25 -0700 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp3KPs8ahYI7zbiTymyQA5ObeXDnQAEmpeAAAdVveA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:18:09 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Monday, December 07, 2009 5:19 AM > For protecting a standalone request, without any challenge from the serve= r, > the best you can do it run a password-based key derivation function (PBKD= F) > (running a hash algorithm for many thousands of iterations) then use the > resulting key to calculate a MAC over the request. Is there a spec to reference for this? Also, does this require storing pass= words in the clear on the server? EHL From rbarnes@bbn.com Mon Dec 7 12:31:28 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC023A67A5 for ; Mon, 7 Dec 2009 12:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hgztSm+FHj3 for ; Mon, 7 Dec 2009 12:31:26 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 6DCBE3A677D for ; Mon, 7 Dec 2009 12:31:26 -0800 (PST) Received: from [128.89.253.235] (helo=[172.27.15.171]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NHkEi-0003ni-Ce; Mon, 07 Dec 2009 15:31:13 -0500 Message-Id: <73F2EFDD-AEA2-4471-9ED2-1C23178C01C9@bbn.com> From: Richard Barnes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293834@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary=Apple-Mail-2-590312008 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 7 Dec 2009 15:31:09 -0500 References: <90C41DD21FB7C64BB94121FBBC2E7234378520A48A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937B8@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852937D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <48AE706BD74FCC4297AD778805CA46F6184C5CF73C@usps.sonoa.local> <90C41DD21FB7C64BB94121FBBC2E72343785293834@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:31:28 -0000 --Apple-Mail-2-590312008 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Eran, It seems like a bad idea to treat query parameters in form-encoded =20 bodies differently from query parameters in the request URI. To the =20 developer, there's not a whole lot of difference between submitting a =20= form via GET or POST; if anything, there seems to be a preference for =20= POST because it doesn't expose the parameters in the request URI. Not =20= protecting query parameters carried in a form-encoded body would mean =20= that parameters in GET submissions would be authenticated but those in =20= POSTs wouldn't be. That's a pretty big difference for two things that =20= are currently considered to be pretty similar. On the other hand, my impression from reading OAuth 1.0 is that it =20 doesn't really require access to the raw request body, just to the =20 names and values of the parameters. The only issue in that case is =20 that the signer and verifier know whether the values they're handling =20= are raw or decoded, to avoid double-encoding. And the only case where =20= that gets you into trouble is when the HTTP platform you're using =20 doesn't always give you one or the other. Are there cases where =20 that's true? Are there implementations that switch? All the ones =20 I've developed with have done one or the other (mostly decoded). =20 (For that matter, they're in the same form as the GET parameters, so =20 there's no difference in how they're handled.) --Richard On Dec 5, 2009, at 12:29 AM, Eran Hammer-Lahav wrote: > I am proposing to make anything to do with the body optional and at =20= > the discretion of the server whether they want to require or =20 > validate it. And either way, stop treating form-encoded bodies =20 > differently than any other. > > EHL > > From: Greg Brail [mailto:gbrail@sonoasystems.com] > Sent: Friday, December 04, 2009 6:07 PM > To: Brian Eaton; Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: RE: [OAUTH-WG] Access to raw HTTP request body > > In Java Servlet 2.5, if I=92m reading section SRV3.1.1 of the spec =20 > correctly the servlet has the opportunity to get the individual =20 > parameters (and thus direct the servlet engine to parse the =20 > parameters automatically), or to read the raw request body. There is =20= > no way to get both. > > So for servlets, at least, it seems to me that the answer is that in =20= > any practical use case, access to the original POST body can=92t be =20= > counted upon. > > On a related note, I=92ll reiterate that accessing the raw request =20 > body can add a layer of inefficiency to an HTTP proxy, such as our =20 > own, especially when the body is large. > > Is there a possibility that we can require signing the POST body =20 > when the OAuth protocol is used to ask for request and access =20 > tokens, but NOT require such signing when authenticated requests are =20= > made later on? That way an implementer could choose to take the =20 > performance hit for the two methods in the OAuth protocol flow (at =20 > least in 1.0) that absolutely require that the POST body be signed, =20= > but not for everything else. > > I suppose that is the point of the body-signing extension, so =20 > forgive me if I haven=92t read that one yet. > > greg > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =20 > Behalf Of Brian Eaton > Sent: Friday, December 04, 2009 5:49 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Access to raw HTTP request body > > On Fri, Dec 4, 2009 at 2:38 PM, Eran Hammer-Lahav =20 > wrote: > > Are there cases where form-encoded bodies change after set by the =20= > client (in a lower layer)? > > I think it depends on the client. Most of the client code I've looked > at assumes that authentication happens with (surprise surprise) bearer > tokens. It's a real pain for client authors to move that code around. > > > Or where the server might have access to the processed form-=20 > encoded parameters but not the original encoded body string? > > This definitely happens, it's how the vanilla java servlet API works. > I think the same is true of django. > > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2-590312008 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
I am proposing to make anything to do with the body = optional and at the discretion of the server whether they want to = require or validate it. And either way, stop treating form-encoded = bodies differently than any other.
 Greg = Brail [mailto:gbrail@sonoasystems.com] 
Sent: Friday, December 04, 2009 = 6:07 PM
To: Brian Eaton; Eran = Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Access to = raw HTTP request body
 
In Java Servlet 2.5, if I=92m = reading section SRV3.1.1 of the spec correctly the servlet has the = opportunity to get the individual parameters (and thus direct the = servlet engine to parse the parameters automatically), or to read the = raw request body. There is no way to get both.
So for servlets, at least, it seems to = me that the answer is that in any practical use case, access to the = original POST body can=92t be counted upon.
On a related note, I=92ll reiterate = that accessing the raw request body can add a layer of inefficiency to = an HTTP proxy, such as our own, especially when the body is = large.
 
Is there a = possibility that we can require signing the POST body when the OAuth = protocol is used to ask for request and access tokens, but NOT require = such signing when authenticated requests are made later on? That way an = implementer could choose to take the performance hit for the two methods = in the OAuth protocol flow (at least in 1.0) that absolutely require = that the POST body be signed, but not for everything = else.
 
I suppose that is the = point of the body-signing extension, so forgive me if I haven=92t read = that one yet.
 
 
-----Original = Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf Of Brian Eaton
Sent: Friday, December 04, 2009 5:49 PM
To: = Eran Hammer-Lahav
Cc: OAuth WG ( 
> Are there cases where form-encoded bodies = change after set by the client (in a lower layer)?
I think it depends on the = client.  Most of the client code I've looked
at = assumes that authentication happens with (surprise surprise) = bearer
tokens.  It's a real pain for client authors = to move that code around.
 
 
I think the same is true of = django.
 
Brian
OAuth@ietf.org
Subject: Re: [OAUTH-WG] Access to raw HTTP request body X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 20:50:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343785293B7CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My impressions are somewhat different. Twitter API uses POST with query par= ameters and this seems to be the growing trend. POST with form-encoded para= meters is mostly common in browsers submitting forms. After all, form-encod= ed parameters are part of the HTML specification whether in the query or bo= dy. I think OAuth 1.0 made a mistake getting involved in the application layer = semantics when authenticating a request. It belongs at the HTTP layer which= doesn't understand anything about query structure or content type. Parameter encoding has been the most problematic part of 1.0, and so far th= is use case has not been defended on this list. These issues are now drivin= g companies like Y!, MS, and Google to dump crypto altogether and use secre= t-less bearer tokens. Without preventing bearer tokens, I would like to mak= e they use less appealing. Offering a coverage method that helps with that = is important. However, there is an easy solution. We can include another coverage method = that includes form-encoded bodies like 'base+form-encoded'. It will use a s= imilar normalization scheme as 1.0 but simpler, building on top of the 'bas= e' method. I am happy to give it a try if others express support for it. EHL From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Monday, December 07, 2009 12:31 PM To: Eran Hammer-Lahav Cc: Greg Brail; Brian Eaton; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Access to raw HTTP request body Eran, It seems like a bad idea to treat query parameters in form-encoded bodies d= ifferently from query parameters in the request URI. To the developer, the= re's not a whole lot of difference between submitting a form via GET or POS= T; if anything, there seems to be a preference for POST because it doesn't = expose the parameters in the request URI. Not protecting query parameters = carried in a form-encoded body would mean that parameters in GET submission= s would be authenticated but those in POSTs wouldn't be. That's a pretty b= ig difference for two things that are currently considered to be pretty sim= ilar. On the other hand, my impression from reading OAuth 1.0 is that it doesn't = really require access to the raw request body, just to the names and values= of the parameters. The only issue in that case is that the signer and ver= ifier know whether the values they're handling are raw or decoded, to avoid= double-encoding. And the only case where that gets you into trouble is wh= en the HTTP platform you're using doesn't always give you one or the other.= Are there cases where that's true? Are there implementations that switch= ? All the ones I've developed with have done one or the other (mostly deco= ded). (For that matter, they're in the same form as the GET parameters, s= o there's no difference in how they're handled.) --Richard On Dec 5, 2009, at 12:29 AM, Eran Hammer-Lahav wrote: I am proposing to make anything to do with the body optional and at the dis= cretion of the server whether they want to require or validate it. And eith= er way, stop treating form-encoded bodies differently than any other. EHL From: Greg Brail [mailto:gbrail@sonoasystems.com] Sent: Friday, December 04, 2009 6:07 PM To: Brian Eaton; Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: RE: [OAUTH-WG] Access to raw HTTP request body In Java Servlet 2.5, if I'm reading section SRV3.1.1 of the spec correctly = the servlet has the opportunity to get the individual parameters (and thus = direct the servlet engine to parse the parameters automatically), or to rea= d the raw request body. There is no way to get both. So for servlets, at least, it seems to me that the answer is that in any pr= actical use case, access to the original POST body can't be counted upon. On a related note, I'll reiterate that accessing the raw request body can a= dd a layer of inefficiency to an HTTP proxy, such as our own, especially wh= en the body is large. Is there a possibility that we can require signing the POST body when the O= Auth protocol is used to ask for request and access tokens, but NOT require= such signing when authenticated requests are made later on? That way an im= plementer could choose to take the performance hit for the two methods in t= he OAuth protocol flow (at least in 1.0) that absolutely require that the P= OST body be signed, but not for everything else. I suppose that is the point of the body-signing extension, so forgive me if= I haven't read that one yet. greg -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Eaton Sent: Friday, December 04, 2009 5:49 PM To: Eran Hammer-Lahav Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Access to raw HTTP request body On Fri, Dec 4, 2009 at 2:38 PM, Eran Hammer-Lahav > wrote: > Are there cases where form-encoded bodies change after set by the client = (in a lower layer)? I think it depends on the client. Most of the client code I've looked at assumes that authentication happens with (surprise surprise) bearer tokens. It's a real pain for client authors to move that code around. > Or where the server might have access to the processed form-encoded param= eters but not the original encoded body string? This definitely happens, it's how the vanilla java servlet API works. I think the same is true of django. Cheers, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343785293B7CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

My impres= sions are somewhat different. Twitter API uses POST with query parameters a= nd this seems to be the growing trend. POST with form-encoded parameters is= mostly common in browsers submitting forms. After all, form-encoded parame= ters are part of the HTML specification whether in the query or body.<= /o:p>

 

I think OAuth 1.0 made a mistake getting involved = in the application layer semantics when authenticating a request. It belong= s at the HTTP layer which doesn’t understand anything about query str= ucture or content type.

 

Parameter encoding ha= s been the most problematic part of 1.0, and so far this use case has not b= een defended on this list. These issues are now driving companies like Y!, = MS, and Google to dump crypto altogether and use secret-less bearer tokens.= Without preventing bearer tokens, I would like to make they use less appea= ling. Offering a coverage method that helps with that is important.

 

However, there is an easy solution. We can include a= nother coverage method that includes form-encoded bodies like ‘base+f= orm-encoded’. It will use a similar normalization scheme as 1.0 but s= impler, building on top of the ‘base’ method.=

 

I am happy to give it a try if others express support for it.<= o:p>

 

EHL

 

Fr= om: Richard Barnes [mailto:rbarnes@bbn.com]
Sent: Monday, Dec= ember 07, 2009 12:31 PM
To: Eran Hammer-Lahav
Cc: Greg = Brail; Brian Eaton; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH= -WG] Access to raw HTTP request body

 

Eran,

 

It seems like a bad idea to treat query parameters in for= m-encoded bodies differently from query parameters in the request URI. &nbs= p;To the developer, there's not a whole lot of difference between submittin= g a form via GET or POST; if anything, there seems to be a preference for P= OST because it doesn't expose the parameters in the request URI.  Not = protecting query parameters carried in a form-encoded body would mean that = parameters in GET submissions would be authenticated but those in POSTs wou= ldn't be.  That's a pretty big difference for two things that are curr= ently considered to be pretty similar.

 

On the other= hand, my impression from reading OAuth 1.0 is that it doesn't really requi= re access to the raw request body, just to the names and values of the para= meters.  The only issue in that case is that the signer and verifier k= now whether the values they're handling are raw or decoded, to avoid double= -encoding.  And the only case where that gets you into trouble is when= the HTTP platform you're using doesn't always give you one or the other. &= nbsp;Are there cases where that's true?  Are there implementations tha= t switch?  All the ones I've developed with have done one or the other= (mostly decoded).   (For that matter, they're in the same form as the= GET parameters, so there's no difference in how they're handled.)

 

--Richard

 

 

On Dec 5, 2009, at 12:29 AM, Eran Hammer-Lahav wrote:=



=

I am proposing to make anything to do with= the body optional and at the discretion of the server whether they want to= require or validate it. And either way, stop treating form-encoded bodies = differently than any other.

 

= EHL

 

<= b>From: = Greg Brail [mailto:gb= rail@sonoasystems.com] =
Sent: Friday, De= cember 04, 2009 6:07 PM
To:&n= bsp;Brian Eaton; Eran Hammer-Lahav
Cc: OAuth WG (oa= uth@ietf.org)
Subject:&nb= sp;RE: [OAUTH-WG] Access to raw HTTP request body

 

=

In Java Servlet 2.5, if I’m reading section S= RV3.1.1 of the spec correctly the servlet has the opportunity to get the in= dividual parameters (and thus direct the servlet engine to parse the parame= ters automatically), or to read the raw request body. There is no way to ge= t both.

 =

So for servlets, at lea= st, it seems to me that the answer is that in any practical use case, acces= s to the original POST body can’t be counted upon.<= /p>

 

On a related note, I’ll reiterate that acce= ssing the raw request body can add a layer of inefficiency to an HTTP proxy= , such as our own, especially when the body is large.

=

 

<= p class=3DMsoNormal>Is there a possibility that we can require signing t= he POST body when the OAuth protocol is used to ask for request and access = tokens, but NOT require such signing when authenticated requests are made l= ater on? That way an implementer could choose to take the performance hit f= or the two methods in the OAuth protocol flow (at least in 1.0) that absolu= tely require that the POST body be signed, but not for everything else.

 

I suppose that is the point of the= body-signing extension, so forgive me if I haven’t read that one yet= .

 =

     = ;            &n= bsp;            = ;            &n= bsp;            = ;     greg

 

= -----Original Message-----
From: oauth-bounces@ietf.org [ma= ilto:oauth-bounces@ietf.org] On Behalf Of Brian Eaton
Sent: Friday, = December 04, 2009 5:49 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] A= ccess to raw HTTP request body

 

= On Fri, Dec 4, 2009 at 2:38 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

<= /div>

> Are there cases where form-encoded b= odies change after set by the client (in a lower layer)?<= /p>

 

I think it depends on the client.  Most of t= he client code I've looked

at assumes that authentication happens with (surprise surprise) bea= rer

tokens.  I= t's a real pain for client authors to move that code around.

 

> Or where the server might have access to= the processed form-encoded parameters but not the original encoded body st= ring?

 

This definitely happens, = it's how the vanilla java servlet API works.

I think the same is true of django.

 

Cheers,

Brian

_______________________________________________

OAuth mailing list

_______________________________________________
OAuth ma= iling list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth

= --_000_90C41DD21FB7C64BB94121FBBC2E72343785293B7CP3PW5EX1MB01E_-- From eran@hueniverse.com Mon Dec 7 15:38:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805AA28C0E2 for ; Mon, 7 Dec 2009 15:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.981 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6s5AD8holA5 for ; Mon, 7 Dec 2009 15:38:28 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 47B883A69AA for ; Mon, 7 Dec 2009 15:38:28 -0800 (PST) Received: (qmail 3206 invoked from network); 7 Dec 2009 23:38:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Dec 2009 23:38:16 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 7 Dec 2009 16:38:07 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , "OAuth WG (oauth@ietf.org)" Date: Mon, 7 Dec 2009 16:38:34 -0700 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp3KPs8ahYI7zbiTymyQA5ObeXDnQAEmpeAAAdVveAADitbYAABLzIA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 23:38:29 -0000 VGhpcyBtZWFucyBzZXJ2ZXJzIHVzaW5nIGEgc2FsdC9oYXNoIHRvZGF5IHRvIHN0b3JlIHRoZWly IHVzZXJzJyBwYXNzd29yZHMgd2lsbCBoYXZlIHRvIHByb3ZpZGUgdGhhdCB0byB0aGUgY2xpZW50 IGluIG9yZGVyIHRvIG1ha2UgdGhpcyB3b3JrICh3aGljaCB0YWtlcyBhd2F5IHRoZSBhYmlsaXR5 IHRvIG1ha2UgdGhpcyB3b3JrIHdpdGhvdXQgYSBjaGFsbGVuZ2UpLg0KDQpTbyB3aGlsZSB0aGlz IGxvb2tzIGxpa2UgYW4gaW50ZXJlc3RpbmcgaWRlYSwgaXQgd29uJ3Qgd29yayB0byBib290c3Ry YXAgZXhpc3RpbmcgY3JlZGVudGlhbHMgaW4gbW9zdCBzZXJ2ZXJzLg0KDQpFSEwNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNYW5nZXIsIEphbWVzIEggW21haWx0bzpK YW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tXQ0KPiBTZW50OiBNb25kYXksIERlY2VtYmVy IDA3LCAyMDA5IDM6MjkgUE0NCj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRyAob2F1 dGhAaWV0Zi5vcmcpDQo+IFN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIFJlcXVlc3QgZm9yIHByb3Bv c2FscyBvbiBib290c3RyYXBwaW5nDQo+IHVzZXJuYW1lcw0KPiANCj4gPiBJcyB0aGVyZSBhIHNw ZWMgdG8gcmVmZXJlbmNlIGZvciB0aGlzPw0KPiANCj4gUEJLREYyIChwYXNzd29yZC1iYXNlZCBr ZXkgZGVyaXZhdGlvbiBmdW5jdGlvbiwgdmVyc2lvbiAyKSBpcyBzcGVjaWZpZWQgaW4NCj4gUEtD UyAjNSB2Mi4wIGFuZCBpbiBSRkMgMjg5OCAoc2FtZSBjb250ZW50LCBkaWZmZXJlbnQgZm9ybWF0 KS4NCj4gU3RhcnQgYXQgaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9QQktERjIuDQo+IEl0 IGV2ZW4gZGVmaW5lcyBhIHBhc3N3b3JkLWJhc2VkIE1BQyAoUEJNQUMxKS4NCj4gDQo+IEkgY2Fu bm90IHJlbWVtYmVyIChhbmQgY2Fubm90IGZpbmQpIHdoZXJlIHBhc3N3b3JkLWJhc2VkIHByb3Rl Y3Rpb24gaW4NCj4gTWljcm9zb2Z0IE9mZmljZSBpcyBkZXRhaWxlZC4NCj4gDQo+IA0KPiA+IEFs c28sIGRvZXMgdGhpcyByZXF1aXJlIHN0b3JpbmcgcGFzc3dvcmRzIGluIHRoZSBjbGVhciBvbiB0 aGUgc2VydmVyPw0KPiANCj4gTm8uIFRoZSBzZXJ2ZXIgY2FuIGFsd2F5cyBlbmNyeXB0ZWQgYW55 IG9mIGl0cyBvd24gZGF0YSBob3dldmVyIGl0IHdhbnRzLg0KPiBEZWNyeXB0aW9uICh3aXRoIGEg a2V5IG9uIHRoZSBzZXJ2ZXIpIHdpbGwgcmV2ZWFsIHRoZSBwYXNzd29yZHMgaW4gdGhlIGNsZWFy Lg0KPiANCj4gSWYgeW91IG5lZWQgdG8gYXZvaWQgYW55IHJvdW5kIHRyaXAgKGllIHdhbnQgYSBz dGFuZGFsb25lIGF1dGhlbnRpYyByZXF1ZXN0KQ0KPiB0aGVuIEkgdGhpbmsgaXQgaXMgZnVuZGFt ZW50YWxseSBpbXBvc3NpYmxlIGZvciB0aGUgc2VydmVyIG5vdCB0byBoYXZlIGFjY2Vzcw0KPiB0 byB0aGUgInBhc3N3b3JkIiBpbiB0aGUgY2xlYXIuDQo+IA0KPiBPZiBjb3Vyc2UgdGhlIHNlcnZl ciBjYW4gc3RvcmUgYSBoYXNoIG9mIHRoZSBwYXNzd29yZCAoJiB1c2VybmFtZSksIGFuZCB0aGUN Cj4gY2xpZW50IGNhbiB1c2UgdGhlIHNhbWUgaGFzaCBhcyB0aGUgc2hhcmVkIHNlY3JldC4gRElH RVNUIGRvZXMgdGhpcw0KPiAoaW5jbHVkaW5nIHRoZSByZWFsbSBhcyB3ZWxsKS4gVGhlIHBhc3N3 b3JkIGlzIG5vdCBpbiB0aGUgY2xlYXIsIGJ1dCB0aGUgaGFzaCBpcw0KPiBpbiB0aGUgY2xlYXIg YW5kIGFuIGF0dGFja2VyIG9ubHkgbmVlZHMgdGhlIGhhc2ggdG8gbWFzcXVlcmFkZSBhcyB0aGUg Y2xpZW50Lg0KPiBUaGlzIGlzIHdvcnRoIGRvaW5nIChhbiBhdHRhY2tlciBjYW5ub3QgcmV1c2Ug dGhlIGhhc2ggYXQgYW5vdGhlciBzaXRlIHdoZXJlDQo+IHRoZSB1c2VyIHVzZXMgdGhlIHNhbWUg cGFzc3dvcmQpLCBidXQgZG9lc24ndCByZWFsbHkgaW1wcm92ZSB0aGUgc2VjdXJpdHkgb2YNCj4g dGhlIHNpdGUgaXRzZWxmLg0KPiANCj4gDQo+IC0tDQo+IEphbWVzIE1hbmdlcg0K From eran@hueniverse.com Mon Dec 7 15:52:03 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E8F3A6A99 for ; Mon, 7 Dec 2009 15:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGy77T6v64OY for ; Mon, 7 Dec 2009 15:52:02 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E06903A680D for ; Mon, 7 Dec 2009 15:52:01 -0800 (PST) Received: (qmail 24166 invoked from network); 7 Dec 2009 23:51:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 7 Dec 2009 23:51:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 7 Dec 2009 16:51:50 -0700 From: Eran Hammer-Lahav To: "Roy T. Fielding" Date: Mon, 7 Dec 2009 16:52:19 -0700 Thread-Topic: Authentication realm Thread-Index: Acp3kyWNQNFe0y2dRVyyzjkDrf7vcgAA3qcA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293C4C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852938C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CE3B6.3080003@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723437852939F5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C5F189-27A9-42F8-9472-B932DD62F1DB@gbiv.com> In-Reply-To: <69C5F189-27A9-42F8-9472-B932DD62F1DB@gbiv.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "HTTP Working Group \(ietf-http-wg@w3.org\)" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Authentication realm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 23:52:03 -0000 > -----Original Message----- > From: Roy T. Fielding [mailto:fielding@gbiv.com] > Sent: Monday, December 07, 2009 3:15 PM > Realm is useful for distinguishing multiple authentication realms on the = same > server. I don't see how that would change, regardless of the new auth > mechanism. It is part of the credential caching mechanism of clients. I agree. But if we define a mechanism that goes further and define credenti= al types supported by the server (i.e. a combination of authorization, cryp= to, scope, etc.), realm becomes redundant. If the server names it token typ= es and then ask for one of those types, it provides a similar functionality= as realm but goes further. I am trying to avoid having two mechanisms that greatly overlap but are not= exactly the same. > BTW, I find it odd that token auth has >=20 > 10.4. Plaintext Storage of Credentials >=20 > I thought we learned that lesson a long time ago. Why is it not using a = hash > of the shared secret instead of the shared secret, like how digest md5-se= ss > uses H(user:realm:password)? Because the first draft is based on OAuth 1.0, and we have yet to address t= his... This text was inherited from the previous version. Thanks! I've got my first issue to address. :-) EHL From eran@hueniverse.com Mon Dec 7 16:25:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087833A68AE for ; Mon, 7 Dec 2009 16:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.004 X-Spam-Level: X-Spam-Status: No, score=-3.004 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD+i5uhUTQfa for ; Mon, 7 Dec 2009 16:25:56 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 282EC3A6862 for ; Mon, 7 Dec 2009 16:25:56 -0800 (PST) Received: (qmail 21380 invoked from network); 8 Dec 2009 00:25:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Dec 2009 00:25:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 7 Dec 2009 17:24:52 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Mon, 7 Dec 2009 17:25:20 -0700 Thread-Topic: Authentication realm Thread-Index: Acp3kyWNQNFe0y2dRVyyzjkDrf7vcgAA3qcAAAB37KA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293C5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852938C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CE3B6.3080003@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723437852939F5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C5F189-27A9-42F8-9472-B932DD62F1DB@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C4C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293C4C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Roy T. Fielding" Subject: Re: [OAUTH-WG] Authentication realm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 00:25:57 -0000 The HMAC methods require the client and server to store secrets in the clea= r (or at least have access to their decrypted form). Are there any ideas fo= r avoiding this? What we can do on the server side to avoid having to keep = the HMAC keys in the clear. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, December 07, 2009 3:52 PM > To: Roy T. Fielding > Cc: Julian Reschke; HTTP Working Group (ietf-http-wg@w3.org); OAuth WG > (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Authentication realm >=20 >=20 >=20 > > -----Original Message----- > > From: Roy T. Fielding [mailto:fielding@gbiv.com] > > Sent: Monday, December 07, 2009 3:15 PM >=20 > > Realm is useful for distinguishing multiple authentication realms on > > the same server. I don't see how that would change, regardless of the > > new auth mechanism. It is part of the credential caching mechanism of > clients. >=20 > I agree. But if we define a mechanism that goes further and define creden= tial > types supported by the server (i.e. a combination of authorization, crypt= o, > scope, etc.), realm becomes redundant. If the server names it token types > and then ask for one of those types, it provides a similar functionality = as > realm but goes further. >=20 > I am trying to avoid having two mechanisms that greatly overlap but are n= ot > exactly the same. >=20 > > BTW, I find it odd that token auth has > > > > 10.4. Plaintext Storage of Credentials > > > > I thought we learned that lesson a long time ago. Why is it not using > > a hash of the shared secret instead of the shared secret, like how > > digest md5-sess uses H(user:realm:password)? >=20 > Because the first draft is based on OAuth 1.0, and we have yet to address > this... This text was inherited from the previous version. >=20 > Thanks! I've got my first issue to address. :-) >=20 > EHL >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From email@pbryan.net Mon Dec 7 17:05:35 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2AA28C1BF for ; Mon, 7 Dec 2009 17:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+GE-hpr5voR for ; Mon, 7 Dec 2009 17:05:34 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id AC69B28C1B7 for ; Mon, 7 Dec 2009 17:05:34 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 3B0166154; Tue, 8 Dec 2009 01:05:24 +0000 (UTC) From: "Paul C. Bryan" To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Mon, 07 Dec 2009 17:05:03 -0800 Message-ID: <1260234303.6142.635.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 01:05:35 -0000 On Sun, 2009-12-06 at 00:55 -0700, Eran Hammer-Lahav wrote: > The reason why I got interested in bringing this work to the IETF to > begin with was to try and use it to solve the problems with HTTP Basic > auth. It is clear that at this point Digest is not likely to win wide > adoption and the simplicity of Basic trumps most other considerations. > I am looking for a way to allow clients to use existing usernames and > password, by defining a token class that uses these credentials to > bootstrap and provide clients with a set of token credentials they > already have. > > I was (easily) convinced that using passwords as HMAC keys is a bad > idea because it will require servers to store passwords in the clear > which even Basic does not require them. However, I think it is worth > trying to find ideas on how to use existing usernames with the new > token scheme that will replace Basic auth in the most common use > cases. > > This is currently not an explicit item of the WG, but we are allowed > to include such a token class in our '2-legged' proposal. > > Comments? Whatever is proposed, I presume needs to cope with the way passwords are stored on the server; usually not in cleartext. I think this is one of the significant factors in the lack of adoption in Digest authentication, as most servers don't/can't store H(A1) in their databases. So if my logic stands, to meet the objective, I think boils down to either the password being sent in the clear (HTTP Basic) or being encrypted using a symmetric key that's negotiated between server and client (or asymmetric key, identified, certified and validated somehow). If work is put into negotiating a symmetric key to use to transmit passwords, it seems on the same order of effort to simply authenticate and receive a token in return. In other words, doesn't "2-legged" OAuth meet this objective? Paul > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Mon Dec 7 19:32:16 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4DB3A688E for ; Mon, 7 Dec 2009 19:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBOnZ6FUJSp6 for ; Mon, 7 Dec 2009 19:32:15 -0800 (PST) Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by core3.amsl.com (Postfix) with ESMTP id EDE803A681F for ; Mon, 7 Dec 2009 19:32:14 -0800 (PST) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipai.vtcif.telstra.com.au with ESMTP; 08 Dec 2009 14:31:02 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 8C8D41DA84; Tue, 8 Dec 2009 14:31:02 +1100 (EST) Received: from WSMSG3753.srv.dir.telstra.com (wsmsg3753.srv.dir.telstra.com [172.49.40.174]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id OAA29975; Tue, 8 Dec 2009 14:31:02 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Tue, 8 Dec 2009 14:31:01 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Tue, 8 Dec 2009 14:30:59 +1100 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp3KPs8ahYI7zbiTymyQA5ObeXDnQAEmpeAAAdVveAADitbYAABLzIAAAZt64A= Message-ID: <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 03:32:16 -0000 PiBUaGlzIG1lYW5zIHNlcnZlcnMgdXNpbmcgYSBzYWx0L2hhc2ggdG9kYXkgdG8gc3RvcmUgdGhl aXIgdXNlcnMnDQo+IHBhc3N3b3JkcyB3aWxsIGhhdmUgdG8gcHJvdmlkZSB0aGF0IHRvIHRoZSBj bGllbnQgaW4gb3JkZXIgdG8gbWFrZSB0aGlzDQo+IHdvcmsgKHdoaWNoIHRha2VzIGF3YXkgdGhl IGFiaWxpdHkgdG8gbWFrZSB0aGlzIHdvcmsgd2l0aG91dCBhDQo+IGNoYWxsZW5nZSkuDQo+IA0K PiBTbyB3aGlsZSB0aGlzIGxvb2tzIGxpa2UgYW4gaW50ZXJlc3RpbmcgaWRlYSwgaXQgd29uJ3Qg d29yayB0bw0KPiBib290c3RyYXAgZXhpc3RpbmcgY3JlZGVudGlhbHMgaW4gbW9zdCBzZXJ2ZXJz Lg0KDQoNCkkgdGhpbmsgd2hhdCB5b3UgYXJlIGFza2luZyBmb3IgaXMgdGhlb3JldGljYWxseSBp bXBvc3NpYmxlLiBHaXZlbiBhIHVzZXItaWQgJiBwYXNzd29yZDoNCjEuIEF1dGhlbnRpY2F0ZSBh IHN0YW5kYWxvbmUgcmVxdWVzdCAod2l0aCBubyByZWFsLXRpbWUgZGF0YSBmcm9tIHRoZSBzZXJ2 ZXIgZmlyc3QpOw0KMi4gRG9uJ3Qgc2VuZCB0aGUgcGFzc3dvcmQgaW4gdGhlIGNsZWFyOw0KMy4g VGhlIHNlcnZlciBjYW4gdXNlIGFuIGV4aXN0aW5nIHBhc3N3b3JkIGRhdGFiYXNlIHRoYXQgc3Rv cmVzIHNhbHRlZCBwYXNzd29yZCBoYXNoZXMuDQoNCklmIHlvdSBkb24ndCBkcm9wIDMsIGVpdGhl ciB0aGUgc2FsdCBoYXMgdG8gYmUgc2VudCB0byB0aGUgY2xpZW50ICh2aW9sYXRpbmcgIzEpLCBv ciB0aGUgcGFzc3dvcmQgaGFzIHRvIGJlIHNlbnQgaW4gdGhlIGNsZWFyIHNvIHRoZSBzZXJ2ZXIg Y2FuIHJlZG8gdGhlIGhhc2ggdG8gY29tcGFyZSAodmlvbGF0aW5nICMyKS4NCg0KSWYgeW91IGRy b3AgMSwgeW91IGNhbiB1c2UgcGFzc3dvcmQtYXV0aGVudGljYXRlZCBrZXkgYWdyZWVtZW50IHNj aGVtZXMgKHN1Y2ggYXMgRUtFLCBTUlAsIFBBSy4uLjsgc2VlIGh0dHA6Ly9lbi53aWtpcGVkaWEu b3JnL3dpa2kvUGFzc3dvcmQtYXV0aGVudGljYXRlZF9rZXlfYWdyZWVtZW50KS4gVGhlc2UgYXJl IHRoZSB1bHRpbWF0ZSBwYXNzd29yZC1iYXNlZCBwcm90b2NvbHMgKGluIHByYWN0aXNlIGFuZCBp biB0aGVvcnkpLiBBbiBhdHRhY2tlciBjYW4gb25seSBtYWtlIDEgcGFzc3dvcmQgZ3Vlc3MgcGVy IHJ1biBvZiB0aGUgcHJvdG9jb2wgLS0gdGhleSBjYW5ub3QgcGVyZm9ybSBhbiBvZmYtbGluZSBk aWN0aW9uYXJ5IGF0dGFjay4gVGhlc2UgYWxnb3JpdGhtcyB1c2UgdGhlIG1hdGhzIG9mIHB1Ymxp Yy1rZXkgY3J5cHRvLiBQYXRlbnQgaXNzdWVzIGhhdmUgb2Z0ZW4gY2xvdWRlZCB0aGUgdXNlIG9m IHRoZXNlIGFsZ29yaXRobXMgW0kga25vdyBub3RoaW5nIGFib3V0IHRoZSBwYXRlbnQgaXNzdWVz XS4gQSBUTFMtbGF5ZXIgc3BlYyBleGlzdHMgW1JGQyA1MDU0XS4gSSBndWVzcyBhbiBIVFRQLWxh eWVyIHZlcnNpb24gY291bGQgYmUgZGVmaW5lZCwgYnV0IEkgYW0gbm90IHN1cmUgaXQgY291bGQg YWRkcyBlbm91Z2ggdmFsdWUgb3ZlciB0aGUgVExTLWxheWVyIHNwZWMuDQoNCklmIHlvdSBkcm9w IDIsIHlvdSBoYXZlIEJBU0lDLg0KDQpJZiB5b3UgZHJvcCAzLCB5b3UgY2FuIHVzZSBQQktERjIg d2l0aCBhIG5vbmNlL3RpbWVzdGFtcCBjaG9zZW4gYnkgY2xpZW50IGFzIGEgc2FsdCAocHJvYmFi bHkgYWRkaW5nIHRoZSB1c2VyLWlkLCBhbGdvcml0aG0gbmFtZXMgZXRjIGludG8gdGhlIHNhbHQg YXMgd2VsbCksIGEgaHVnZSBudW1iZXIgb2YgaXRlcmF0aW9ucyBvZiBhIGhhc2ggYWxnb3JpdGht IChlZyBjaG9zZW4gc28gdGhlIGNvbXB1dGF0aW9uIHRha2VzIH4xIHNlY29uZCksIHRoZW4gdXNl IHRoZSByZXN1bHQgYXMgYSBNQUMga2V5LiBUaGUgInBhc3N3b3JkIiBpbnB1dCB0byBQQktERjIg Y2FuIGFjdHVhbGx5IGJlIGhhc2gocGFzc3dvcmR8fHVzZXJpZCkuIFRoZSBzZXJ2ZXIgbmVlZHMg YWNjZXNzIHRvIHRoaXMgaGFzaCBpbiB0aGUgY2xlYXIuIEFuIGF0dGFja2VyIGNvbXByb21pc2lu ZyB0aGUgc2VydmVyJ3MgYWNjb3VudCBkYXRhYmFzZSBjYW4gdXNlIGhhc2gocGFzc3dvcmR8fHVz ZXJpZCkgdG8gbG9naW4gYXMgdGhlIHVzZXIgKHdpdGhvdXQga25vd2luZyB0aGUgcGFzc3dvcmQp Lg0KDQoNCg0KDQoNClAuUy4gVGhlIGZvbGxvd2luZyBibG9nIHBvc3QgKGFuZCB2YXJpb3VzIG90 aGVyIHBvc3RzIGluIHRoZSBzYW1lIGJsb2cpIGhhcyBkZXRhaWxzIGFib3V0IHRoZSBwYXNzd29y ZC1iYXNlZCBzZWN1cml0eSBpbiBPZmZpY2UgMjAwNyAoYW5kIHVwZGF0ZXMpLg0KSXQgdXNlcyBh IHNsaWdodCB2YXJpYXRpb24gb24gUEJLREYxOiB3aXRoIDEwMCwwMDAgaXRlcmF0aW9ucyBvZiBT SEEtMSBieSBkZWZhdWx0Lg0KaHR0cDovL2Jsb2dzLm1zZG4uY29tL2RhdmlkX2xlYmxhbmMvYXJj aGl2ZS8yMDA4LzEyLzA0L25ldy1pbXByb3ZlZC1vZmZpY2UtY3J5cHRvLmFzcHggDQoNCg0KDQot LSANCkphbWVzIE1hbmdlcg0K From beaton@google.com Mon Dec 7 23:05:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844C528C105 for ; Mon, 7 Dec 2009 23:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO4yf6nhzrdw for ; Mon, 7 Dec 2009 23:05:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1DA7F3A67C2 for ; Mon, 7 Dec 2009 23:05:42 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id nB875UE1007379 for ; Tue, 8 Dec 2009 07:05:31 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260255931; bh=xZnp9JQRgb61VbAqi0Hzcxa9BJc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JWUhs79c/u2yRKFqY3jzflJIYrHXaE6jV5qT03JnOLzvDj5hrtv4Zo4aSdGt1IepF 3qOPC2tLLRCc1J98RpPpg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Uo4Q57tyQkJ/ENFLD7F5xXnTPQZdM3DSwjtCJ46RNBR1q8/CFGU5BAuOpOsdZ2wli mOOaN5xc19dXjJ3ZuVFsw== Received: from pwi13 (pwi13.prod.google.com [10.241.219.13]) by wpaz24.hot.corp.google.com with ESMTP id nB875SPG000555 for ; Mon, 7 Dec 2009 23:05:28 -0800 Received: by pwi13 with SMTP id 13so420388pwi.2 for ; Mon, 07 Dec 2009 23:05:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.201.3 with SMTP id y3mr474803rvf.288.1260255927684; Mon, 07 Dec 2009 23:05:27 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 7 Dec 2009 23:05:27 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 07:05:44 -0000 On Mon, Dec 7, 2009 at 12:27 AM, Eran Hammer-Lahav wrote: > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt I'm not a fan, for a couple of reasons. The signature base string (section 8 in the draft) is still very complex to describe and construct... and even with all that complexity, I don't think it meets most of the use cases for two-legged OAuth that were identified in earlier conversations about why people are using OAuth signing [1]. I'd like to propose an alternative approach for OAuth message authentication that focuses on providing a reusable signature base string and meeting existing two-legged OAuth use cases. This is fairly close to SWT [2], but I think SWT has some warts [3] that need fixing. If there is general support/interest in this, I'm happy to write it up more formally. Here's an informal version: An OAuth message signature is made up of three components, an envelope, a message, and a signature. The envelope and the message are base64 encoded JSON objects. The signature is a base64 encoded byte string. The encoding uses the web-safe base64 alphabet without line feeds or padding described by RFC 4648 [4]. The three components are joined with '.' characters. The envelope field is a description of the payload. It contains a "name" field that identifies the key used to sign the message. It contains an "algorithm" field that identifies the signature algorithm used to sign the message. And it contains a timestamp (measured in seconds since the epoch) and a nonce used to prevent replay attacks. For example, the envelope might look like this: { "name": "source.example.com", "algorithm": "RSA-SHA256", "timestamp": 1260253850, "nonce": "0437f743b5809" } The message field contains the payload of the signed message. For signing an HTTP request, the message contains a single field "url", with a copy of the HTTP URL of the request: { "url": "http://destination.example.com/resource?abcd=1234" } Signing messages besides HTTP requests, or extending the HTTP request signature to cover additional components of the request, is trivial: add new fields to the JSON payload of the message. The signature base string is generated by concatentating the base64 encoded envelope and message. First, the envelope is encoded. For the example above, the envelope becomes: ewogICAgIm5hbWUiCg Next, the message is encoded. For the example above, the message becomes: ewogICAgIm5hbWUiCg The envelope and the message are then joined with a '.' character: ewogICAgIm5hbWUiCg.ewogICAgIm5hbWUiCg The resulting string is signed with the specified key and algorithm. The signature is base64 encoded and appended to the envelope and message. For the example above: ewogICAgIm5hbWUiCg.ewogICAgIm5hbWUiCg.qSSVPG3bTw5-YFab315w The resulting signed token can then be embedded in an HTTP header: Authorization: Token ewogICAgIm5hbWUiCg.ewogICAgIm5hbWUiCg.qSSVPG3bTw5-YFab315w Verification of the signature is trivial, because it does not require reconstructing the signature base string or canonicalization of values. The exact data that was signed is present in the request. Cheers, Brian [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00530.html [2] https://oauth-wrap-wg.googlegroups.com/web/SWT-v0.9.5.1.pdf [3] https://groups.google.com/group/WRAP-WG/browse_thread/thread/a88135610e57b976 [4] http://tools.ietf.org/html/rfc4648#section-5 From James.H.Manger@team.telstra.com Mon Dec 7 23:52:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596203A68A8 for ; Mon, 7 Dec 2009 23:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1LdHEssNFIL for ; Mon, 7 Dec 2009 23:52:31 -0800 (PST) Received: from mailipbo.vtcif.telstra.com.au (mailipbo.vtcif.telstra.com.au [202.12.144.29]) by core3.amsl.com (Postfix) with ESMTP id 21A403A6885 for ; Mon, 7 Dec 2009 23:52:30 -0800 (PST) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipbi.vtcif.telstra.com.au with ESMTP; 08 Dec 2009 10:29:20 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id B0C971DA82; Tue, 8 Dec 2009 10:29:19 +1100 (EST) Received: from WSMSG3753.srv.dir.telstra.com (wsmsg3753.srv.dir.telstra.com [172.49.40.174]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA10045; Tue, 8 Dec 2009 10:29:19 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Tue, 8 Dec 2009 10:29:18 +1100 From: "Manger, James H" To: Eran Hammer-Lahav , "OAuth WG (oauth@ietf.org)" Date: Tue, 8 Dec 2009 10:29:17 +1100 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp3KPs8ahYI7zbiTymyQA5ObeXDnQAEmpeAAAdVveAADitbYA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 07:52:32 -0000 PiBJcyB0aGVyZSBhIHNwZWMgdG8gcmVmZXJlbmNlIGZvciB0aGlzPw0KDQpQQktERjIgKHBhc3N3 b3JkLWJhc2VkIGtleSBkZXJpdmF0aW9uIGZ1bmN0aW9uLCB2ZXJzaW9uIDIpIGlzIHNwZWNpZmll ZCBpbg0KUEtDUyAjNSB2Mi4wIGFuZCBpbiBSRkMgMjg5OCAoc2FtZSBjb250ZW50LCBkaWZmZXJl bnQgZm9ybWF0KS4NClN0YXJ0IGF0IGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUEJLREYy Lg0KSXQgZXZlbiBkZWZpbmVzIGEgcGFzc3dvcmQtYmFzZWQgTUFDIChQQk1BQzEpLg0KDQpJIGNh bm5vdCByZW1lbWJlciAoYW5kIGNhbm5vdCBmaW5kKSB3aGVyZSBwYXNzd29yZC1iYXNlZCBwcm90 ZWN0aW9uIGluIE1pY3Jvc29mdCBPZmZpY2UgaXMgZGV0YWlsZWQuDQoNCg0KPiBBbHNvLCBkb2Vz IHRoaXMgcmVxdWlyZSBzdG9yaW5nIHBhc3N3b3JkcyBpbiB0aGUgY2xlYXIgb24gdGhlIHNlcnZl cj8NCg0KTm8uIFRoZSBzZXJ2ZXIgY2FuIGFsd2F5cyBlbmNyeXB0ZWQgYW55IG9mIGl0cyBvd24g ZGF0YSBob3dldmVyIGl0IHdhbnRzLg0KRGVjcnlwdGlvbiAod2l0aCBhIGtleSBvbiB0aGUgc2Vy dmVyKSB3aWxsIHJldmVhbCB0aGUgcGFzc3dvcmRzIGluIHRoZSBjbGVhci4NCg0KSWYgeW91IG5l ZWQgdG8gYXZvaWQgYW55IHJvdW5kIHRyaXAgKGllIHdhbnQgYSBzdGFuZGFsb25lIGF1dGhlbnRp YyByZXF1ZXN0KSB0aGVuIEkgdGhpbmsgaXQgaXMgZnVuZGFtZW50YWxseSBpbXBvc3NpYmxlIGZv ciB0aGUgc2VydmVyIG5vdCB0byBoYXZlIGFjY2VzcyB0byB0aGUgInBhc3N3b3JkIiBpbiB0aGUg Y2xlYXIuDQoNCk9mIGNvdXJzZSB0aGUgc2VydmVyIGNhbiBzdG9yZSBhIGhhc2ggb2YgdGhlIHBh c3N3b3JkICgmIHVzZXJuYW1lKSwgYW5kIHRoZSBjbGllbnQgY2FuIHVzZSB0aGUgc2FtZSBoYXNo IGFzIHRoZSBzaGFyZWQgc2VjcmV0LiBESUdFU1QgZG9lcyB0aGlzIChpbmNsdWRpbmcgdGhlIHJl YWxtIGFzIHdlbGwpLiBUaGUgcGFzc3dvcmQgaXMgbm90IGluIHRoZSBjbGVhciwgYnV0IHRoZSBo YXNoIGlzIGluIHRoZSBjbGVhciBhbmQgYW4gYXR0YWNrZXIgb25seSBuZWVkcyB0aGUgaGFzaCB0 byBtYXNxdWVyYWRlIGFzIHRoZSBjbGllbnQuIFRoaXMgaXMgd29ydGggZG9pbmcgKGFuIGF0dGFj a2VyIGNhbm5vdCByZXVzZSB0aGUgaGFzaCBhdCBhbm90aGVyIHNpdGUgd2hlcmUgdGhlIHVzZXIg dXNlcyB0aGUgc2FtZSBwYXNzd29yZCksIGJ1dCBkb2Vzbid0IHJlYWxseSBpbXByb3ZlIHRoZSBz ZWN1cml0eSBvZiB0aGUgc2l0ZSBpdHNlbGYuDQoNCg0KLS0gDQpKYW1lcyBNYW5nZXINCg== From eran@hueniverse.com Mon Dec 7 23:53:46 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7626128C0D0 for ; Mon, 7 Dec 2009 23:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWHUhk7x-dCk for ; Mon, 7 Dec 2009 23:53:45 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 69A003A6885 for ; Mon, 7 Dec 2009 23:53:45 -0800 (PST) Received: (qmail 12120 invoked from network); 8 Dec 2009 07:53:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 8 Dec 2009 07:53:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 8 Dec 2009 00:52:01 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 8 Dec 2009 00:52:30 -0700 Thread-Topic: [OAUTH-WG] Token Access Authentication Scheme Draft Thread-Index: Acp31NiF0S/HB+BDRQmzIvYhqbr1rwABDWKw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343785293CC2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 07:53:46 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Monday, December 07, 2009 11:05 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft >=20 > On Mon, Dec 7, 2009 at 12:27 AM, Eran Hammer-Lahav > wrote: > > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt >=20 > I'm not a fan, for a couple of reasons. >=20 > The signature base string (section 8 in the draft) is still very complex = to > describe and construct... and even with all that complexity, I don't thin= k it > meets most of the use cases for two-legged OAuth that were identified in > earlier conversations about why people are using OAuth signing [1]. Can you list the use cases it doesn't meet? This is largely a cosmetic rewr= ite of 1.0 with the exception of directly supporting form-encoded parameter= s which is still being discussed. Your reference is to a post about mostly = non-HTTP use cases. > An OAuth message signature is made up of three components, an envelope, > a message, and a signature. The envelope and the message are base64 > encoded JSON objects. The signature is a base64 encoded byte string. Th= e > encoding uses the web-safe base64 alphabet without line feeds or padding > described by RFC 4648 [4]. The three components are joined with '.' > characters. Requiring JSON parser is additional work for the client. Not much work, but= more than just parsing an HTTP header which it has to do anyway. =20 > The envelope field is a description of the payload. It contains a "name"= field > that identifies the key used to sign the message. It contains an "algori= thm" > field that identifies the signature algorithm used to sign the message. = And it > contains a timestamp (measured in seconds since the epoch) and a nonce > used to prevent replay attacks. > For example, the envelope might look like this: >=20 > { > "name": "source.example.com", > "algorithm": "RSA-SHA256", > "timestamp": 1260253850, > "nonce": "0437f743b5809" > } Not sure what 'name' means. Is it a made up string by the server? Is it a w= ell-defined certificate field? =20 > The message field contains the payload of the signed message. For signin= g > an HTTP request, the message contains a single field "url", with a copy o= f the > HTTP URL of the request: >=20 > { > "url": "http://destination.example.com/resource?abcd=3D1234" > } This requires normalization as HTTP requests don't actually have such a URL= . > Verification of the signature is trivial, because it does not require > reconstructing the signature base string or canonicalization of values. = The > exact data that was signed is present in the request. You are trading the server's need to reconstruct the normalized request str= ing with the need to validate all the values contained. The server still ha= s to compare the Host header, port, request URI, and everything else to wha= t has been signed. Doesn't seem like a big difference. The only fundamental difference here, beyond format, is that you are includ= ing what you are signing. Doing that, regardless of structure is a signific= ant shift in how requests have been signed in 1.0. This is not a reason not= to adopt such a proposal, but before considering the details of your idea,= we need to discuss this first. I am not crazy about using JSON here, but that's a matter of style. The rea= l issue is if we want to include the normalized request string with the req= uest. And you still have to provide the encoded token using an attribute. O= nly Basic Auth is allowed to violate the key=3D"value" header rule. EHL From mjmalone@gmail.com Tue Dec 8 10:07:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741E528C1C3 for ; Tue, 8 Dec 2009 10:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfvXznEM5nha for ; Tue, 8 Dec 2009 10:07:28 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 444C33A6830 for ; Tue, 8 Dec 2009 10:07:28 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so1184162qwb.31 for ; Tue, 08 Dec 2009 10:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Oa8ULCBgGdlQIL9HaTzm+LpmUYSeP3qHy7KPca9UDhQ=; b=dWO2nNhFtADYKIlDZKQQGlrWOHKAQJcdehB2TxQMtvmwFF0l3WNlXEHCPzicj9kRgV rrE/saZtM30+Scw/w3kZFkVkyx2IfvCVc280yNsUWWMYQUxwaMqd5of+nWEwjxuziDvx zJ6EzaLGMbLsy2z5Cy6IEWIsaHsdSngmymlvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Xq5w7iwZG73/Lb0zSFAPnHAVXnpYPiwCe8cO103mF04HXU4Pe32yJsTBlPPN03SPLd mOufIIPgbqN649C1w0Jen4JcG6bB2+tau02sO2JeYhfEtUYBSlg0Du5TikOmbt+BDnSy fg+MD7jBwLsMDfyJKWiEU42o9LyFMfcwU3334= MIME-Version: 1.0 Received: by 10.229.92.211 with SMTP id s19mr1150872qcm.46.1260295634161; Tue, 08 Dec 2009 10:07:14 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293C5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723437852938C4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CE3B6.3080003@gmx.de> <90C41DD21FB7C64BB94121FBBC2E723437852939F5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C5F189-27A9-42F8-9472-B932DD62F1DB@gbiv.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C4C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293C5D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Mike Malone Date: Tue, 8 Dec 2009 10:06:54 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Roy T. Fielding" , "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Authentication realm X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 18:07:29 -0000 I think the situation here is slightly different than Digest. If I'm not mistaken, Digest is still vulnerable if I get H(user:realm:password). All you're doing by storing H(user:realm:password) on the server side is keeping an attacker from getting the user's plaintext password, which may be used elsewhere, I guess (you're also keeping the password from being sent over the wire in the clear, which is the big win). Example digest auth signature (somewhat simplified, removed nonce, etc): HA1 =3D MD5("mike:realm@example.com:password") HA2 =3D MD5("GET:/") Signature =3D MD5(HA1:HA2) If I can get HA1 (which the server has to store in the clear) then I can still forge requests... so it's really not all that different than what OAuth is doing. In the case of OAuth, if the server is compromised the solution would probably be to revoke all tokens and make everyone re-authenticate. Mike On Mon, Dec 7, 2009 at 4:25 PM, Eran Hammer-Lahav wro= te: > The HMAC methods require the client and server to store secrets in the cl= ear (or at least have access to their decrypted form). Are there any ideas = for avoiding this? What we can do on the server side to avoid having to kee= p the HMAC keys in the clear. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Eran Hammer-Lahav >> Sent: Monday, December 07, 2009 3:52 PM >> To: Roy T. Fielding >> Cc: Julian Reschke; HTTP Working Group (ietf-http-wg@w3.org); OAuth WG >> (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Authentication realm >> >> >> >> > -----Original Message----- >> > From: Roy T. Fielding [mailto:fielding@gbiv.com] >> > Sent: Monday, December 07, 2009 3:15 PM >> >> > Realm is useful for distinguishing multiple authentication realms on >> > the same server. =A0I don't see how that would change, regardless of t= he >> > new auth mechanism. =A0It is part of the credential caching mechanism = of >> clients. >> >> I agree. But if we define a mechanism that goes further and define crede= ntial >> types supported by the server (i.e. a combination of authorization, cryp= to, >> scope, etc.), realm becomes redundant. If the server names it token type= s >> and then ask for one of those types, it provides a similar functionality= as >> realm but goes further. >> >> I am trying to avoid having two mechanisms that greatly overlap but are = not >> exactly the same. >> >> > BTW, I find it odd that token auth has >> > >> > =A0 =A010.4. =A0Plaintext Storage of Credentials >> > >> > I thought we learned that lesson a long time ago. =A0Why is it not usi= ng >> > a hash of the shared secret instead of the shared secret, like how >> > digest md5-sess uses H(user:realm:password)? >> >> Because the first draft is based on OAuth 1.0, and we have yet to addres= s >> this... This text was inherited from the previous version. >> >> Thanks! I've got my first issue to address. :-) >> >> EHL >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dan.winship@gmail.com Tue Dec 8 10:59:44 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8913A6923 for ; Tue, 8 Dec 2009 10:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEzYEjx-ffJK for ; Tue, 8 Dec 2009 10:59:43 -0800 (PST) Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id C2F223A6A36 for ; Tue, 8 Dec 2009 10:59:42 -0800 (PST) Received: from desktop.home.mysterion.org (c-76-97-71-164.hsd1.ga.comcast.net [76.97.71.164]) by mysterion.org (Postfix) with ESMTPA id C59B4802AE; Tue, 8 Dec 2009 13:59:31 -0500 (EST) Message-ID: <4B1EA213.2040902@gmail.com> Date: Tue, 08 Dec 2009 13:59:31 -0500 From: Dan Winship User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Thunderbird/3.0b4 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 18:59:44 -0000 On 12/07/2009 03:27 AM, Eran Hammer-Lahav wrote: > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt OK, so I'm not familiar with OAuth in detail, and am reviewing this more from the perspective of an HTTP client library author who will eventually end up implementing the spec... First off, I don't like the idea of having one new meta-scheme ("Token") with multiple sub-schemes ("oauth", etc). I've already got code to allow extensibility/pluggability at the scheme level (Basic, Digest, NTLM, etc). I don't want to have a *second* extension point inside one of the auth schemes. If there's going to be both OAuth and SomeoneElsesTokenBasedAuth, I'd rather have them as separate top-level schemes, even if the implementations ended up sharing a lot of parsing/digest-computing code between them. If you really think it's important to have a generic "token" framework with OAuth as just one implementation of it, a nicer way would be to remove the "class" attribute and the "Token" scheme name, and just say that each token auth subtype will define its own scheme name. So instead of WWW-Authenticate: Token class="oauth", methods="hmac-sha-1 hmac-sha-256", timestamp="137131190" you'd have WWW-Authenticate: OAuth methods="hmac-sha-1 hmac-sha-256", timestamp="137131190" but most of the rest of the spec would be unchanged. (OK, reading back through old threads I see that part of the goal was to not have it be named "OAuth". But you could just use "OAuth2" or "OAuthToken" or something.) But then again, is there any evidence that anyone besides OAuth will ever use the Token scheme? (And if so, that the existing definition of the Token parameters will be right for them?) Moving on... If Token/OAuth is not intended for use with Proxy-Authenticate/Proxy-Authorization, then you should say that explicitly near the beginning, and if not, then everywhere you say "WWW-Authenticate" or "Authorization", you need to allow for the proxy versions as well. (Maybe just by saying "whenever I say WWW-Authenticate, I mean 'either WWW-Authenticate or Proxy-Authenticate'.") I know you said you don't care about typos, but "OWF" should be "OWS". "rsassa-pkcs1-v1.5-sha-256" is way too long a name. :) The grammar for method-list says method-list = "method" "=" <"> 1#method-name <"> where "1#method-name" in RFC2616 ABNF means a comma-delimited list of method-name. But the text (4.2) and the example quoted above use a space-delimited list. (Likewise with coverage-list.) The first paragraph of section 5 seems to say that clients MUST include a Authorization header when requesting a protected resource even if they don't know that it's protected. :) In theory, the information in the Authentication-Error response could just be included in WWW-Authenticate... If error-message is supposed to be localized then you should allow for the RFC 2183 grammar (or eventually, the grammar from the RFC that draft-reschke-rfc2183-in-http becomes). The "normalized request string" says it includes both the hostname and the request URI, which would be redundant. Maybe when you say "request resource URI" you mean just the Request-URI production from the Request-Line (ie, the path+query), not the actual complete request URI? You should clarify that. Although if the user is behind a proxy then the Request-URI will be a complete URI rather than just the path+query. So you might want to say something like "the path and query components of the request URI, as they appear in the Request-Line"? There have been interoperability problems with Digest auth digest computation because people weren't sure if the quotes around attribute values were considered part of the value or not when computing the hash. You should be explicit. "Any authentication attribute, with the exception of the "auth", which is assigned a value (including default values), are added to the normalized request string as follows" is hard to understand. I think what you mean is "Any attribute which is present in the Authorization header, with the exception of "auth", is added to the normalized request string as follows". Hm... although 7.1 seems to suggest something else. I'm not at all sure what attributes are supposed to be included in the normalized request string now. Would probably be good to have an example of computing the string. -- Dan From jpanzer@google.com Tue Dec 8 11:29:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FC723A68C2 for ; Tue, 8 Dec 2009 11:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.948 X-Spam-Level: X-Spam-Status: No, score=-105.948 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo2PppGbHjz0 for ; Tue, 8 Dec 2009 11:29:23 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 52CF03A6848 for ; Tue, 8 Dec 2009 11:29:23 -0800 (PST) Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id nB8JTBWJ023414 for ; Tue, 8 Dec 2009 11:29:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260300552; bh=1wT3B3prmeKoq1v9VFZx2eASC8Y=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=UxnjRkIyn7+aF8d29zrI5VAqtWEQJYGkgEh7KJEH39ILHlDLXXco80+Xn9U/twai9 7E0R4JFQzFgGm70R1SHvA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=ALiivfUhhQovjE73pADVe2JDfLcVXjH8/2ep00Xu+WrhiPpNgCvI8bIl420eiqu2o 4VCctCcMMP4yd01KhEZ/w== Received: from pwi13 (pwi13.prod.google.com [10.241.219.13]) by spaceape12.eur.corp.google.com with ESMTP id nB8JT523021561 for ; Tue, 8 Dec 2009 11:29:07 -0800 Received: by pwi13 with SMTP id 13so820926pwi.2 for ; Tue, 08 Dec 2009 11:29:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.115.67.8 with SMTP id u8mr15947820wak.190.1260300544110; Tue, 08 Dec 2009 11:29:04 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: John Panzer Date: Tue, 8 Dec 2009 11:28:44 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0016e64ce5b83deff9047a3c96cc X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 19:29:25 -0000 --0016e64ce5b83deff9047a3c96cc Content-Type: text/plain; charset=ISO-8859-1 (Is there an HTML markup output version available as well? Easier to link to...) "The token scheme support an extensible" --> supports Suggestion: It would be better to start with simple examples (bearer token) which avoids the need to wade through concepts like timestamp synchronization and authentication coverage in order to understand the simplest possible flow? (E.g., the example in 1.2.) Suggestion: Make it clear up front that protected resources are allowed and encouraged to put a WWW-Authenticate: header on all requests (even ones that return 200 for read-only access) to indicate what authentication is allowed in general. (The equivalent of the "login" link on web pages that present a read-only view.) Section 2, step 1: It sounds like all of the attributes are required even if some of them are irrelevant to the current credential class. Suggestion: attributes that are unnecessary SHOULD be omitted; e.g., method and coverage are n/a for bearer tokens. I suppose this is the same as saying that instead of saying coverage="none" we should omit coverage. In general, I think that much of the text could be made simpler by separating out the coverage="none" case from the other cases. At the moment the only method under discussion with coverage="none" is bearer token. I think that's all there ever will be. If that's correct, perhaps separating out things that way would lead to a simpler reading experience (for the bearer token-users for sure, and possibly for everybody else as they don't have to worry about the special case of coverage="none" over and over again.) Section 5: "A client making a request for a protected resource either directly, or in retrying a request after receiving a 401 status code (Unauthorized) with a token challenge, MUST include at least one "Authorization" header field including token scheme credentials." - This could be read as forbidding clients from querying protected resources before figuring out what Authorization: header to use (as they sometimes need to make an initial request to discover that the resource is protected). Possibly just rewording to "credentialled request"? What is the right terminology here? Section 6: "MAY includes the" --> include the Section 7: "In addition, the "none" method is defined to allow the use of bearer token which does not utilizes any cryptographic means." Grammar: "defined to allow the use of bearer tokens, which do not utilize cryptographic signatures." Suggestion: Calling the token method "none" is odd and jarring. It makes me think about the classic routine "Who's on first?". How about "bearer"? As in, the method for request validation is to simply check that it bears the token. "relying solely on the value of the token identifier to authenticate the client" Surely we are authenticating the request in all these methods? (Authenticating the client may be a side effect, but it is neither necessary nor sufficient.) Suggestion: Add a note (SHOULD) about using SSL / TLS when discussing the bearer token option, either within this section or in the security considerations section (couldn't find one after some searching). It's implied by the discussion in section 8.1 but it's difficult to parse out. "The "coverage" attribute MUST be set to "none" but MAY be omitted from the request." This reads oddly -- I would assume that I can set it to anything if it's omitted :). Suggestion: MUST be either set to "none", or omitted from the request. "Nevertheless, these attributes MUST be included in the normalized request string together with any other authentication attributes." After quick read, I have no idea what this sentence means operationally. Can you clarify? -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer On Mon, Dec 7, 2009 at 12:27 AM, Eran Hammer-Lahav wrote: > http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt > > This draft is my first attempt at defining a general purpose authentication > scheme to fulfill the WG requirement to produce a scheme suitable for > 2-legged authentication. It also supports the OAuth 3-legged use cases as > discussed on the list. This draft is in very early stage and has been > submitted early to help better facilitate the conversation. > > It has been hard for us to discuss ideas without a concrete proposal. I > hope this will help and motivate people to participate and provide feedback > and new ideas. While there are many holes in the draft, it should be pretty > easy to follow it. > > Major changes from OAuth 1.0: > > * New auth scheme with new parameter names > * Signature base string replaced with normalized request string, and now > does not require *any* encoding > * Supports multiple token classes, authentication methods, and coverage > scope > > Main feedback requested: > > * Initial impressions - this is particularly important to get. Does the > draft make sense? > * Functionality - does it include all the requested/required functionality? > * Abstraction level - do the attributes provide the right level of > configuration and choice? > > Please refrain from editorial feedback at this point (grammar, typos, > etc.), but do provide structural feedback. > > I plan to push an updated version by Wed which will incorporate as much > feedback as I can. I plan to ask for the WG to promote this draft to a WG > item within 2 weeks. > > Thanks, > > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e64ce5b83deff9047a3c96cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (Is there an HTML markup output version available as well? =A0Easier to lin= k to...)

"The to= ken scheme support an extensible" --> supports

Suggestion: It would be better to start with simple exa= mples (bearer token) which avoids the need to wade through concepts like ti= mestamp synchronization and authentication coverage in order to understand = the simplest possible flow? =A0(E.g., the example in 1.2.)

Suggestion: Make it clear up front that protected resou= rces are allowed and encouraged to put a WWW-Authenticate: header on all re= quests (even ones that return 200 for read-only access) to indicate what au= thentication is allowed in general. =A0(The equivalent of the "login&q= uot; link on web pages that present a read-only view.)

Section 2, step 1: =A0It sounds like all of the attribu= tes are required even if some of them are irrelevant to the current credent= ial class. =A0Suggestion: attributes that are unnecessary SHOULD be omitted= ; e.g., method and coverage are n/a for bearer tokens. =A0I suppose this is= the same as saying that instead of saying coverage=3D"none" we s= hould omit coverage.

In general, I think that much of the text could be made= simpler by separating out the coverage=3D"none" case from the ot= her cases. =A0At the moment the only method under discussion with coverage= =3D"none" is bearer token. =A0I think that's all there ever w= ill be. =A0If that's correct, perhaps separating out things that way wo= uld lead to a simpler reading experience (for the bearer token-users for su= re, and possibly for everybody else as they don't have to worry about t= he special case of coverage=3D"none" over and over again.)

Section 5: "A c= lient making a request for a protected resource either directly, 
   or in retrying a request after receiving a 401 status cod=
e
   (Unauthorized) with a token challenge, MUST include at least one
   "Authorization" header field including token scheme credential=
s."
- This could be read as forbidding clients from q= uerying protected resources before figuring out what Authorization: header = to use (as they sometimes need to make an initial request to discover that = the resource is protected). =A0Possibly just rewording to "credentiall= ed request"? =A0What is the right terminology here?

Section 6: "MAY= includes the" --> include the

Sect= ion 7: "In addition, the "none= " method is
   defined to allow the use of bearer token which does not u=
tilizes any=A0
cryptographic means."

Grammar: "defined to allow the use o= f bearer tokens, which do not utilize cryptographic signatures."
Suggestion: =A0Calling the token method "none" is odd and ja= rring. =A0It makes me think about the classic routine "Who's on fi= rst?". =A0How about "bearer"? =A0As in, the method for reque= st validation is to simply check that it bears the token.

"relying solely= on the
value of the= token identifier to authenticate the client"

Surely we are authenticating the request in all these method= s? =A0(Authenticating the client may be a side effect, but it is neither ne= cessary nor sufficient.)

Suggestion: =A0Add a note= (SHOULD) about using SSL / TLS when discussing the bearer token option, ei= ther within this section or in the security considerations section (couldn&= #39;t find one after some searching). =A0It's implied by the discussion= in section 8.1 but it's difficult to parse out.=A0

"The "cove= rage"
attribute= MUST be set to "none" but MAY be omitted from the request."

This reads oddly -- I would assume that I can set it to= anything if it's omitted :). =A0Suggestion: =A0MUST be either set to &= quot;none", or omitted from the request.

&quo= t;Nevertheless, these attributes MUST be= included in the normalized
request string together with any= other authentication attributes."

Aft= er quick read, I have no idea what this sentence means operationally. =A0Ca= n you clarify?

--

John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanzer



On Mon, Dec 7, 2009 at 12:27 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt

This draft is my first attempt at defining a general purpose authentication= scheme to fulfill the WG requirement to produce a scheme suitable for 2-le= gged authentication. It also supports the OAuth 3-legged use cases as discu= ssed on the list. This draft is in very early stage and has been submitted = early to help better facilitate the conversation.

It has been hard for us to discuss ideas without a concrete proposal. I hop= e this will help and motivate people to participate and provide feedback an= d new ideas. While there are many holes in the draft, it should be pretty e= asy to follow it.

Major changes from OAuth 1.0:

* New auth scheme with new parameter names
* Signature base string replaced with normalized request string, and now do= es not require *any* encoding
* Supports multiple token classes, authentication methods, and coverage sco= pe

Main feedback requested:

* Initial impressions - this is particularly important to get. Does the dra= ft make sense?
* Functionality - does it include all the requested/required functionality?=
* Abstraction level - do the attributes provide the right level of configur= ation and choice?

Please refrain from editorial feedback at this point (grammar, typos, etc.)= , but do provide structural feedback.

I plan to push an updated version by Wed which will incorporate as much fee= dback as I can. I plan to ask for the WG to promote this draft to a WG item= within 2 weeks.

Thanks,

EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e64ce5b83deff9047a3c96cc-- From rbarnes@bbn.com Tue Dec 8 15:47:14 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B1C3A683D for ; Tue, 8 Dec 2009 15:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcbadAzbeuQG for ; Tue, 8 Dec 2009 15:47:13 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B35303A67B2 for ; Tue, 8 Dec 2009 15:47:12 -0800 (PST) Received: from [192.1.255.190] (helo=col-dhcp-192-1-255-190.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NI9lk-0004MD-C2; Tue, 08 Dec 2009 18:47:01 -0500 Message-Id: <253B6D38-4EDA-4B23-B6B3-26F0B7EC5F8F@bbn.com> From: Richard Barnes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293332@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary=Apple-Mail-7-688462600 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Dec 2009 18:47:00 -0500 References: <90C41DD21FB7C64BB94121FBBC2E7234378520A481@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B17C9EC.7090003@aol.com> <4B17CE8C.2030703@alcatel-lucent.com> <4B17D96E.8030002@stpeter.im> <4B17DCAC.9060201@gmail.com> <4B17DE3D.3000204@aol.com> <1D38D21A-D81F-4E7C-A14C-C75368A0B725@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E72343785293332@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Timestamp and sync X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 23:47:14 -0000 --Apple-Mail-7-688462600 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I actually like this approach: If the server rejects the request because the timestamp is stale, then it includes a timestamp in its response, corresponding to the current time by its clock. The client can then remember the offset for this server to maintain sync for future requests. Distributed clients can pass this state to their peers as they get it. When this is being used in the delegation workflow, the client and server can sync up as part of the delegation, when they're both establishing state already. This works pretty well as long as the clocks don't skew much against each other. Note that there is a potential security vulnerability here, however: An attacker could exploit this mechanism to get the client to generate signatures with timestamps in the future (as seen by the server), for the attacker to use when the time comes. The simplest mitigation to this seems to be to have the server authenticate the returned timestamp, e.g., by constructing a signature that covers the client's nonce and timestamp as well as the server's timestamp. This is another reason to allow OAuth signatures on responses, as I think was suggested earlier. Trying to sync via the problem reporting extension (as Paul suggests), would still leave this vulnerability. --Richard On Dec 3, 2009, at 12:39 PM, Eran Hammer-Lahav wrote: > It relates indirectly. The problem reporting extension provides one > way to implement #1. However, since we are proposing a new auth > scheme, we are going to revisit error codes anyway. > > EHL > > From: Paul Lindner [mailto:lindner@inuus.com] > Sent: Thursday, December 03, 2009 9:23 AM > To: Eran Hammer-Lahav > Cc: George Fletcher; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Timestamp and sync > > How does this relate to the OAuth Problem Reporting extension? > > timestamp_refused > the oauth_timestamp value is unacceptable to the Service Provider. > In this case, the response SHOULD also contain an > oauth_acceptable_timestamps parameter (described below). > > The parameter named oauth_acceptable_timestamps consists of two > numbers in decimal notation, separated by '-' (hyphen). It's the > range of timestamps acceptable to the sender. That is, it means the > sender will currently accept an oauth_timestamp that's not less than > the first number and not greater than the second number. > If the client sees this error it can adjust the skew based on the > server's clock, not some arbitrary NTP server... > > > On Thu, Dec 3, 2009 at 8:55 AM, Eran Hammer-Lahav > wrote: > Just use the NTP data to calculate the skew. No need to change the OS > level clock. That was not implied in my list. > > EHL > > On Dec 3, 2009, at 7:50, "George Fletcher" wrote: > > > But what can the client do with that message? Should the client > modify > > the OS settings of the device to start syncing the clock? > > > > Thanks, > > George > > > > Paul Madsen wrote: > >> Isn the point of #2 to allow the server to indicate to the client > >> 'Hey > >> use NTP - perhaps this server' when it is clear that the client > wasnt > >> already doing so? > >> > >> Peter Saint-Andre wrote: > >>> > >>> > >>> On 12/3/09 7:43 AM, Igor Faynberg wrote: > >>> > >>>> I am actually +1 on both options (assuming that using GPS for > time > >>>> synchronizaion is implicitly included). While I agree with George > >>>> that > >>>> the client's clock may not be manipulated externally, I did not > >>>> think > >>>> that option #2 implied that. > >>>> > >>> > >>> What confuses me about option #2 is this: why is it the OAuth > >>> server's > >>> responsibility to tell the OAuth client about a trusted NTP > >>> server? IMHO > >>> the device on which the OAuth client is running can already > >>> discover NTP > >>> servers on its own, and nothing the OAuth server tells the OAuth > >>> client > >>> will have an special influence here. > >>> > >>> /psa > >>> > >>> > >>> --- > >>> --- > >>> ------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> OAuth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >> --- > >> > --------------------------------------------------------------------- > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-7-688462600 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
I actually like this = approach: If the server rejects the request because the timestamp is = stale, then it includes a timestamp in its response, corresponding to = the current time by its clock.  The client can then remember the = offset for this server to maintain sync for future requests. =  Distributed clients can pass this state to their peers as they get = it.  When this is being used in the delegation workflow, the client = and server can sync up as part of the delegation, when they're both = establishing state already.  This works pretty well as long as the = clocks don't skew much against each other.

Note = that there is a potential security vulnerability here, however: An = attacker could exploit this mechanism to get the client to generate = signatures with timestamps in the future (as seen by the server), for = the attacker to use when the time comes.  The simplest mitigation = to this seems to be to have the server authenticate the returned = timestamp, e.g., by constructing a signature that covers the client's = nonce and timestamp as well as the server's timestamp.  This is = another reason to allow OAuth signatures on responses, as I think was = suggested earlier.  Trying to sync via the problem reporting = extension (as Paul suggests), would still leave this = vulnerability.

--Richard



On Dec 3, 2009, at 12:39 PM, Eran = Hammer-Lahav wrote:

It relates indirectly. The problem reporting = extension provides one way to implement #1. However, since we are = proposing a new auth scheme, we are going to revisit error codes = anyway.
 
EHL
 Paul = Lindner [mailto:lindner@inuus.com] 
Sent: Thursday, December 03, 2009 = 9:23 AM
To: Eran = Hammer-Lahav
Cc: George Fletcher; OAuth WG = ( Re: [OAUTH-WG] Timestamp = and sync
On Thu, Dec 3, 2009 = at 8:55 AM, Eran Hammer-Lahav <Just use the NTP data to calculate the skew. No need to = change the OS
level clock. That was not implied in my list.

On Dec 3, 2009, = at 7:50, "George Fletcher" < OAuth@ietf.org
>>>  OAuth@ietf.org
>>  OAuth@ietf.org
> OAuth@ietf.org
OAuth@ietf.org
Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 23:55:15 -0000 Just to put one more nail in this coffin: This mechanism would offer a cute bid-down attack, in which the man-in-the-middle says, "sorry, I only support PLAINTEXT, please go to https://evil.com/oauth/". On Dec 3, 2009, at 6:57 PM, Eran Hammer-Lahav wrote: > What if the HTTPS URI was explicitly provided, not implied by > inserting an 's' into the URI? Not sure what's the best way of > providing it, but I'm sure we can find a way... > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >> Of Paul C. Bryan >> Sent: Thursday, December 03, 2009 3:52 PM >> To: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option >> >> On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote: >>> How do people feel about the idea of allowing the server to say it >>> is >>> willing to accept a plaintext request (with or without a secret) but >>> only over HTTPS? >>> >>> This is a bit odd because is conflates the http and https schemes to >>> discuss the same resource regardless of the scheme, but it is how >>> most >>> sites deploy their endpoints. >> >> I think it's wrong for exactly the reason you stated above. The >> presence of "- >> S" means the resource is also exposed at the same hostname, but >> implicitly >> via HTTPS on port 443, with the same URI. This is too much of a >> stretch for >> me. >> >>> >>> For example: >>> >>> A request for http://example.com/resource/1 will yield the following >>> response: >>> >>> HTTP/1.1 401 Unauthorized >>> WWW-Authenticate: Token realm="http://example.com/", class="oauth", >>> methods="HMAC Plain-S" >>> >>> Which means OAuth tokens are accepted using the HMAC method, or the >>> Plain method over HTTPS. If the client wishes to use Plain, it must >>> send an authenticated response to https://example.com/resource/1. >>> >>> Comments? >>> >>> EHL >>> PS. You'll notice I am throwing a lot of new ideas to the list for >>> feedback as I am working on my authentication draft. Feel free to >>> bounce your own ideas (thanks James!). >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rbarnes@bbn.com Tue Dec 8 16:17:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0B33A69CF for ; Tue, 8 Dec 2009 16:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBKgotFOEsyJ for ; Tue, 8 Dec 2009 16:17:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7C15C3A69CD for ; Tue, 8 Dec 2009 16:17:43 -0800 (PST) Received: from [192.1.255.190] (helo=col-dhcp-192-1-255-190.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1NIAFH-0004qM-CN; Tue, 08 Dec 2009 19:17:32 -0500 Message-Id: <21D4FB55-A8EF-4619-8C5F-5F7E1E54CB8A@bbn.com> From: Richard Barnes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293745@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary=Apple-Mail-8-690293657 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 8 Dec 2009 19:17:31 -0500 References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529368A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293745@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 00:17:45 -0000 --Apple-Mail-8-690293657 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable This isn't quite right. First of all, you're not constraining the =20 types of *tokens*, you're constraining the types of token *secrets* =20 (the private part, not the public part; the key, not the key label). Second, there's basically only two classes of signature/secret anyway, =20= symmetric and asymmetric. MAC algorithms generally take any string of =20= bytes as a key (possibly with a length constraint), since they're just =20= going to XOR it with data anyway. Public-key algorithms require the =20 secret key to have an relationship to its public half. The practical =20= implication is that you can use your tokens as MAC keys if you want, =20 but you might need to carry tokens separately if you're using an =20 asymmetric signature algorithm. Net of all that, I'll agree with Brian's earlier claim that OAuth 1.0 =20= had this basically right by having the server advertise what =20 algorithms it supports, with the one major change that we probably =20 should use the same base string for all algorithms. --Richard On Dec 4, 2009, at 3:35 PM, Eran Hammer-Lahav wrote: > We have been to some extent talking part each other. Breno and I =20 > spend some time talking about this off line and reached a better =20 > understanding of our positions. > > We have been approaching this from the wrong direction. > > The server should not be broadcasting what types of algorithms it =20 > supports. Instead it should be listing what kind of *tokens* it =20 > supports. Since a token secret issued for use with HMAC-SHA1 should/=20= > may be different from that used with HMAC-SHA512, it is the token =20 > class that determines what it can be used with. > > The server should indicate the kinds of tokens supported for a given =20= > resource/realm. When obtaining such tokens, the client will be =20 > provided with a new attribute indicating the token type (which will =20= > dictate how it should use it to sign/etc. the canonicalized request.). > > The server should indicate in the WWW-Authenticate header which =20 > canonicalizations it supports (with bearer token being a special =20 > case). > > The authentication scheme should specify how to take the raw =20 > signature and encode it into the Authentication header. > > This means *are* going to pick a few token types to standardize =20 > which will include the crypto used, and allow extensions by =20 > publishing an RFC + registration. > > EHL > > > > > From: Breno [mailto:breno.demedeiros@gmail.com] > Sent: Friday, December 04, 2009 11:46 AM > To: Eran Hammer-Lahav > Cc: Brian Eaton; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Signature crypto > > I am not sure I buy this. For instance, RSA-SHA1 is _not_ a =20 > signature scheme, PKCS#11 does establish a signature scheme based on =20= > RSA + SHA-1. > > So to delve beyond the level of abstraction of 'authentication =20 > mechanism name' you need to point to a separate spec for both =20 > signing and verification. > > I am not sure how much one needs to do beyond defining the byte =20 > representation of what needs to be signed. > > Some MACs require random pads in addition to keys. Those won't fit =20 > into this abstraction but I don't think we need absolute generality =20= > here. > > On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav = > wrote: > Point where? > > I didn=92t mean new spec for the algorithm, just for how it is used =20= > with the OAuth authentication scheme. > > EHL > > From: Breno [mailto:breno.demedeiros@gmail.com] > Sent: Friday, December 04, 2009 11:20 AM > To: Brian Eaton > Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Signature crypto > > There is no need to publish a new spec for a new MAC algorithm. MAC =20= > algorithms typically go through certification (e.g., NIST) and have =20= > detailed specs, including test vectors for interoperability. > > For OAuth, if you want to explicitly support a new MAC algorithm you =20= > will not need to change the transport and you just have to point to =20= > the particular spec that defines the MAC algorithm. > > On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton =20 > wrote: > On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav = > wrote: > > I am trying to avoid the need to publish a specification every =20 > time you want > > to add a new MAC-based algorithm. > > People are going to end up needing to write new code every time they > want to add a new MAC-based algorithm. > > Cheers, > Brian > > > > --=20 > Breno de Medeiros > > > > > --=20 > Breno de Medeiros > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-8-690293657 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable This isn't quite right. =  First of all, you're not constraining the types of *tokens*, = you're constraining the types of token *secrets* (the private part, not = the public part; the key, not the key label).

Second, = there's basically only two classes of signature/secret anyway, symmetric = and asymmetric.  MAC algorithms generally take any string of bytes = as a key (possibly with a length constraint), since they're just going = to XOR it with data anyway.  Public-key algorithms require the = secret key to have an relationship to its public half.  The = practical implication is that you can use your tokens as MAC keys if you = want, but you might need to carry tokens separately if you're using an = asymmetric signature algorithm.

Net of all = that, I'll agree with Brian's earlier claim that OAuth 1.0 had this = basically right by having the server advertise what algorithms it = supports, with  the one major change that we probably should use = the same base string for all algorithms. =  

--Richard 


On Dec 4, 2009, at 3:35 PM, Eran Hammer-Lahav = wrote:

We have been to some extent talking part each other. = Breno and I spend some time talking about this off line and reached a = better understanding of our positions.
We have been approaching this from the wrong = direction.
 
The server should not be = broadcasting what types of algorithms it supports. Instead it should be = listing what kind of *tokens* it supports. Since a token secret = issued for use with HMAC-SHA1 should/may be different from that used = with HMAC-SHA512, it is the token class that determines what it can be = used with.
 
The server should indicate the = kinds of tokens supported for a given resource/realm. When obtaining = such tokens, the client will be provided with a new attribute indicating = the token type (which will dictate how it should use it to sign/etc. the = canonicalized request.).
The server should indicate in the WWW-Authenticate = header which canonicalizations it supports (with bearer token being a = special case).
 
The authentication scheme should = specify how to take the raw signature and encode it into the = Authentication header.
 
This means *are* going to = pick a few token types to standardize which will include the crypto = used, and allow extensions by publishing an RFC + = registration.
 
EHL
 
 
Some MACs require random pads in addition to keys. Those won't = fit into this abstraction but I don't think we need absolute generality = here.

Point = where?
I didn=92t mean new = spec for the algorithm, just for how it is used with the OAuth = authentication scheme.




-- 
Breno de = Medeiros

_________________________________= ______________
OAuth mailing list
 Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 03:10:11 -0000 --001636b2b4d122b31f047a43066d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Dec 8, 2009 at 4:17 PM, Richard Barnes wrote: > This isn't quite right. First of all, you're not constraining the types = of > *tokens*, you're constraining the types of token *secrets* (the private > part, not the public part; the key, not the key label). > Good security practice indicates that a key (the secret part) should be use= d with a single algorithm. Different algorithm --> different key. > > Second, there's basically only two classes of signature/secret anyway, > symmetric and asymmetric. MAC algorithms generally take any string of by= tes > as a key (possibly with a length constraint), since they're just going to > XOR it with data anyway. Public-key algorithms require the secret key to > have an relationship to its public half. The practical implication is th= at > you can use your tokens as MAC keys if you want, but you might need to ca= rry > tokens separately if you're using an asymmetric signature algorithm. > While MAC algorithms take any type of key, it is not good practice to use a key with two different MAC algorithms. So while technically it will work, i= t is not advised practice. > > Net of all that, I'll agree with Brian's earlier claim that OAuth 1.0 had > this basically right by having the server advertise what algorithms it > supports, with the one major change that we probably should use the same > base string for all algorithms. > > --Richard > > > > On Dec 4, 2009, at 3:35 PM, Eran Hammer-Lahav wrote: > > We have been to some extent talking part each other. Breno and I spend so= me > time talking about this off line and reached a better understanding of ou= r > positions. > > We have been approaching this from the wrong direction. > > The server should not be broadcasting what types of algorithms it support= s. > Instead it should be listing what kind of **tokens** it supports. Since a > token secret issued for use with HMAC-SHA1 should/may be different from t= hat > used with HMAC-SHA512, it is the token class that determines what it can = be > used with. > > The server should indicate the kinds of tokens supported for a given > resource/realm. When obtaining such tokens, the client will be provided w= ith > a new attribute indicating the token type (which will dictate how it shou= ld > use it to sign/etc. the canonicalized request.). > > The server should indicate in the WWW-Authenticate header which > canonicalizations it supports (with bearer token being a special case). > > The authentication scheme should specify how to take the raw signature an= d > encode it into the Authentication header. > > This means **are** going to pick a few token types to standardize which > will include the crypto used, and allow extensions by publishing an RFC + > registration. > > EHL > > > > > *From:* Breno [mailto:breno.demedeiros@gmail.com > ] > *Sent:* Friday, December 04, 2009 11:46 AM > *To:* Eran Hammer-Lahav > *Cc:* Brian Eaton; OAuth WG (oauth@ietf.org) > *Subject:* Re: [OAUTH-WG] Signature crypto > > I am not sure I buy this. For instance, RSA-SHA1 is _not_ a signature > scheme, PKCS#11 does establish a signature scheme based on RSA + SHA-1. > > So to delve beyond the level of abstraction of 'authentication mechanism > name' you need to point to a separate spec for both signing and > verification. > > I am not sure how much one needs to do beyond defining the byte > representation of what needs to be signed. > > > Some MACs require random pads in addition to keys. Those won't fit into > this abstraction but I don't think we need absolute generality here. > On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav > wrote: > Point where? > > I didn=92t mean new spec for the algorithm, just for how it is used with = the > OAuth authentication scheme. > > EHL > > *From:* Breno [mailto:breno.demedeiros@gmail.com] > *Sent:* Friday, December 04, 2009 11:20 AM > *To:* Brian Eaton > *Cc:* Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) > > *Subject:* Re: [OAUTH-WG] Signature crypto > > There is no need to publish a new spec for a new MAC algorithm. MAC > algorithms typically go through certification (e.g., NIST) and have detai= led > specs, including test vectors for interoperability. > > > For OAuth, if you want to explicitly support a new MAC algorithm you will > not need to change the transport and you just have to point to the > particular spec that defines the MAC algorithm. > On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton wrote: > > On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav > wrote: > > I am trying to avoid the need to publish a specification every time you > want > > to add a new MAC-based algorithm. > People are going to end up needing to write new code every time they > > want to add a new MAC-based algorithm. > Cheers, > Brian > > > > > -- > Breno de Medeiros > > > > > -- > Breno de Medeiros > _______________________________________________ > > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Breno de Medeiros --001636b2b4d122b31f047a43066d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 8, 2009 at 4:17 PM, Richard = Barnes <rbarnes@bbn= .com> wrote:
This isn't quite right. =A0First of= all, you're not constraining the types of *tokens*, you're constra= ining the types of token *secrets* (the private part, not the public part; = the key, not the key label).

Good security practice indicates that a ke= y (the secret part) should be used with a single algorithm. Different algor= ithm --> different key.
=A0

Second, there's= basically only two classes of signature/secret anyway, symmetric and asymm= etric. =A0MAC algorithms generally take any string of bytes as a key (possi= bly with a length constraint), since they're just going to XOR it with = data anyway. =A0Public-key algorithms require the secret key to have an rel= ationship to its public half. =A0The practical implication is that you can = use your tokens as MAC keys if you want, but you might need to carry tokens= separately if you're using an asymmetric signature algorithm.

While MAC algorithms take any type o= f key, it is not good practice to use a key with two different MAC algorith= ms. So while technically it will work, it is not advised practice.

=A0

Net of all that, I'll agree w= ith Brian's earlier claim that OAuth 1.0 had this basically right by ha= ving the server advertise what algorithms it supports, with =A0the one majo= r change that we probably should use the same base string for all algorithm= s. =A0=A0

--Richard=A0



On Dec 4, 2009, at 3:35 PM,= Eran Hammer-Lahav wrote:

We have been to some extent t= alking part each other. Breno and I spend some time talking about this off = line and reached a better understanding of our positions.
=A0
We have been approaching this from the wrong direction.
=A0
The server should not be broadcasting what types of algorithms it su= pports. Instead it should be listing what kind of *tokens* it suppor= ts. Since a token secret issued for use with HMAC-SHA1 should/may be differ= ent from that used with HMAC-SHA512, it is the token class that determines = what it can be used with.
=A0
The server should indicate the kinds of tokens supported for a given= resource/realm. When obtaining such tokens, the client will be provided wi= th a new attribute indicating the token type (which will dictate how it sho= uld use it to sign/etc. the canonicalized request.).
=A0
The server should indicate in the WWW-Authenticate header which cano= nicalizations it supports (with bearer token being a special case).<= /div>
=A0
The authentication scheme should specify how to take the raw signatu= re and encode it into the Authentication header.
=A0
This means *are* going to pick a few token types to standardi= ze which will include the crypto used, and allow extensions by publishing a= n RFC + registration.
=A0
EHL
=A0
=A0
=A0
=A0
<= span style=3D"font-size:10pt;font-family:Tahoma, sans-serif">From:=A0Breno [mailto:breno.demedeiros@gma= il.com]=A0
Sent:=A0Friday, December 04, 2009 11:46 AM
To:=A0Eran Hammer-Lahav
Cc:=A0Brian Eaton= ; OAuth WG (oauth@ietf.org)
Subject:=A0Re: [OAUTH-WG] Signature crypto
=
=A0
I am not sure I buy this. For instance, RSA-SHA1 is _not_ a signature = scheme, PKCS#11 does establish a signature scheme based on RSA + SHA-1.
=A0
So to delve beyond the level of abstraction of 'authentication mechanis= m name' you need to point to a separate spec for both signing and verif= ication.
=A0
I am not sure how much one needs to do beyond defining the = byte representation of what needs to be signed.
=A0

Some MACs require random pads in addition to keys. Those won't fit into= this abstraction but I don't think we need absolute generality here.

On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Point where?
=A0
I didn=92t mean new spec for t= he algorithm, just for how it is used with the OAuth authentication scheme.=
=A0
EHL
=A0
<= span style=3D"font-size:10pt">From:=A0Breno [mailto:breno.d= emedeiros@gmail.com]=A0
Sent:=A0Friday, December 04, 2009 11:20 AM
To:=A0Brian Eaton
Cc:=A0Eran Hammer-Lahav= ; OAuth WG (oauth@ietf.org)

Subject:=A0Re: [OAUTH-WG] Signature crypto
=A0
There is no need to publish a new spec for a new MAC algorithm. MAC algorit= hms typically go through certification (e.g., NIST) and have detailed specs= , including test vectors for interoperability.
=A0

For OAuth, if you want to explicitly support = a new MAC algorithm you will not need to change the transport and you just = have to point to the particular spec that defines the MAC algorithm.

On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton <beaton@google.com> wrote:

On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I am trying to avoid the need to publish a specification every time yo= u want
> to add a new MAC-based algorithm.

People are going to end up needing to write new code every time they
<= div>

want to add a new MAC-based algorithm.

Cheers,
Brian




--=A0
Breno de Me= deiros



<= br> --=A0
Breno de Medeiros

__= _____________________________________________

OAuth ma= iling list
OAuth@ietf.org
https://www.ietf.org/mailman/= listinfo/oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Breno de Medeiros
--001636b2b4d122b31f047a43066d-- From rbarnes@bbn.com Tue Dec 8 21:57:47 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4343A6ABA for ; Tue, 8 Dec 2009 21:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdRJxHfB5vZw for ; Tue, 8 Dec 2009 21:57:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 39D653A6AB9 for ; Tue, 8 Dec 2009 21:57:45 -0800 (PST) Received: from [128.89.254.31] (helo=[192.168.1.45]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NIFYJ-00016a-AK; Wed, 09 Dec 2009 00:57:33 -0500 Message-Id: <226241E8-907C-4CC2-88F2-C20C77717605@bbn.com> From: "Richard L. Barnes" To: Breno In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2-710692814 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Dec 2009 00:57:30 -0500 References: <90C41DD21FB7C64BB94121FBBC2E72343785183009@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E7234378529369B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936BC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723437852936D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293745@P3PW5EX1MB01.EX1.SECURESERVER.NET> <21D4FB55-A8EF-4619-8C5F-5F7E1E54CB8A@bbn.com> X-Mailer: Apple Mail (2.936) Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Signature crypto X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 05:57:47 -0000 --Apple-Mail-2-710692814 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable We're not talking about using the same key with multiple MACs (that's =20= an issue of how the keys are managed). Rather, we're trying to figure =20= out a taxonomy of signing algorithms according to some practical =20 criteria. "Arbitrary bit-string" vs. "Algebraically meaningful" for a =20= key seems to be an important distinction for this protocol (since =20 there's a question as to what the protocol should use for a signing =20 key), but it doesn't imply that you would use the same protocol for =20 all signing algorithms of a given class -- this idea is clearly =20 ridiculous for asymmetric algorithms, and has some risks, as you say, =20= for symmetric algorithms. --Richard On Dec 8, 2009, at 10:09 PM, Breno wrote: > > > On Tue, Dec 8, 2009 at 4:17 PM, Richard Barnes =20 > wrote: > This isn't quite right. First of all, you're not constraining the =20 > types of *tokens*, you're constraining the types of token *secrets* =20= > (the private part, not the public part; the key, not the key label). > > Good security practice indicates that a key (the secret part) should =20= > be used with a single algorithm. Different algorithm --> different =20 > key. > > > Second, there's basically only two classes of signature/secret =20 > anyway, symmetric and asymmetric. MAC algorithms generally take any =20= > string of bytes as a key (possibly with a length constraint), since =20= > they're just going to XOR it with data anyway. Public-key =20 > algorithms require the secret key to have an relationship to its =20 > public half. The practical implication is that you can use your =20 > tokens as MAC keys if you want, but you might need to carry tokens =20 > separately if you're using an asymmetric signature algorithm. > > While MAC algorithms take any type of key, it is not good practice =20 > to use a key with two different MAC algorithms. So while technically =20= > it will work, it is not advised practice. > > > > Net of all that, I'll agree with Brian's earlier claim that OAuth =20 > 1.0 had this basically right by having the server advertise what =20 > algorithms it supports, with the one major change that we probably =20= > should use the same base string for all algorithms. > > --Richard > > > > On Dec 4, 2009, at 3:35 PM, Eran Hammer-Lahav wrote: > >> We have been to some extent talking part each other. Breno and I =20 >> spend some time talking about this off line and reached a better =20 >> understanding of our positions. >> >> We have been approaching this from the wrong direction. >> >> The server should not be broadcasting what types of algorithms it =20 >> supports. Instead it should be listing what kind of *tokens* it =20 >> supports. Since a token secret issued for use with HMAC-SHA1 should/=20= >> may be different from that used with HMAC-SHA512, it is the token =20 >> class that determines what it can be used with. >> >> The server should indicate the kinds of tokens supported for a =20 >> given resource/realm. When obtaining such tokens, the client will =20 >> be provided with a new attribute indicating the token type (which =20 >> will dictate how it should use it to sign/etc. the canonicalized =20 >> request.). >> >> The server should indicate in the WWW-Authenticate header which =20 >> canonicalizations it supports (with bearer token being a special =20 >> case). >> >> The authentication scheme should specify how to take the raw =20 >> signature and encode it into the Authentication header. >> >> This means *are* going to pick a few token types to standardize =20 >> which will include the crypto used, and allow extensions by =20 >> publishing an RFC + registration. >> >> EHL >> >> >> >> >> From: Breno [mailto:breno.demedeiros@gmail.com] >> Sent: Friday, December 04, 2009 11:46 AM >> To: Eran Hammer-Lahav >> Cc: Brian Eaton; OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Signature crypto >> >> I am not sure I buy this. For instance, RSA-SHA1 is _not_ a =20 >> signature scheme, PKCS#11 does establish a signature scheme based =20 >> on RSA + SHA-1. >> >> So to delve beyond the level of abstraction of 'authentication =20 >> mechanism name' you need to point to a separate spec for both =20 >> signing and verification. >> >> I am not sure how much one needs to do beyond defining the byte =20 >> representation of what needs to be signed. >> >> Some MACs require random pads in addition to keys. Those won't fit =20= >> into this abstraction but I don't think we need absolute generality =20= >> here. >> >> On Fri, Dec 4, 2009 at 11:25 AM, Eran Hammer-Lahav = > > wrote: >> Point where? >> >> I didn=92t mean new spec for the algorithm, just for how it is used =20= >> with the OAuth authentication scheme. >> >> EHL >> >> From: Breno [mailto:breno.demedeiros@gmail.com] >> Sent: Friday, December 04, 2009 11:20 AM >> To: Brian Eaton >> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org) >> >> Subject: Re: [OAUTH-WG] Signature crypto >> >> There is no need to publish a new spec for a new MAC algorithm. MAC =20= >> algorithms typically go through certification (e.g., NIST) and have =20= >> detailed specs, including test vectors for interoperability. >> >> For OAuth, if you want to explicitly support a new MAC algorithm =20 >> you will not need to change the transport and you just have to =20 >> point to the particular spec that defines the MAC algorithm. >> >> On Fri, Dec 4, 2009 at 11:12 AM, Brian Eaton =20 >> wrote: >> On Fri, Dec 4, 2009 at 11:10 AM, Eran Hammer-Lahav = > > wrote: >> > I am trying to avoid the need to publish a specification every =20 >> time you want >> > to add a new MAC-based algorithm. >> >> People are going to end up needing to write new code every time they >> want to add a new MAC-based algorithm. >> >> Cheers, >> Brian >> >> >> >> --=20 >> Breno de Medeiros >> >> >> >> >> --=20 >> Breno de Medeiros >> >> _______________________________________________ >> >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > --=20 > Breno de Medeiros > --Apple-Mail-2-710692814 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable We're not talking about using = the same key with multiple MACs (that's an issue of how the keys are = managed).  Rather, we're trying to figure out a taxonomy of signing = algorithms according to some practical criteria.  "Arbitrary = bit-string" vs. "Algebraically meaningful" for a key seems to be an = important distinction for this protocol (since there's a question as to = what the protocol should use for a signing key), but it doesn't imply = that you would use the same protocol for all signing algorithms of a = given class -- this idea is clearly ridiculous for asymmetric = algorithms, and has some risks, as you say, for symmetric = algorithms.

--Richard


=

On Dec 8, 2009, at 10:09 PM, Breno wrote:



On Tue, Dec 8, 2009 at 4:17 PM, Richard Barnes = <rbarnes@bbn.com> = wrote:
This isn't quite right.  First of = all, you're not constraining the types of *tokens*, you're constraining = the types of token *secrets* (the private part, not the public part; the = key, not the key label).

Good = security practice indicates that a key (the secret part) should be used = with a single algorithm. Different algorithm --> different = key.
 

Second, there's = basically only two classes of signature/secret anyway, symmetric and = asymmetric.  MAC algorithms generally take any string of bytes as a = key (possibly with a length constraint), since they're just going to XOR = it with data anyway.  Public-key algorithms require the secret key = to have an relationship to its public half.  The practical = implication is that you can use your tokens as MAC keys if you want, but = you might need to carry tokens separately if you're using an asymmetric = signature algorithm.

While = MAC algorithms take any type of key, it is not good practice to use a = key with two different MAC algorithms. So while technically it will = work, it is not advised practice.
=

 

Net of all that, I'll = agree with Brian's earlier claim that OAuth 1.0 had this basically right = by having the server advertise what algorithms it supports, with =  the one major change that we probably should use the same base = string for all algorithms.   
=

--Richard 



On Dec 4, 2009, at 3:35 PM, Eran Hammer-Lahav = wrote:

=
We have been to some extent talking part each other. Breno and = I spend some time talking about this off line and reached a better = understanding of our positions.
 
We have been approaching this from the wrong = direction.
 
The server should not be broadcasting what types of algorithms = it supports. Instead it should be listing what kind of *tokens* = it supports. Since a token secret issued for use with HMAC-SHA1 = should/may be different from that used with HMAC-SHA512, it is the token = class that determines what it can be used with.
 
The server should indicate the kinds of tokens supported for a = given resource/realm. When obtaining such tokens, the client will be = provided with a new attribute indicating the token type (which will = dictate how it should use it to sign/etc. the canonicalized = request.).
 
The server should indicate in the WWW-Authenticate header = which canonicalizations it supports (with bearer token being a special = case).
 
The authentication scheme should specify how to take the raw = signature and encode it into the Authentication header.
=
 
This means *are* going to pick a few token types to = standardize which will include the crypto used, and allow extensions by = publishing an RFC + registration.
 
EHL
 
 
 
 
From: Breno [mailto:breno.demedeiros@gmail.com] 
Sent: Friday, December 04, 2009 11:46 = AM
To: Eran = Hammer-Lahav
Cc: Brian Eaton; OAuth WG (oauth@ietf.org)
= Subject: Re: [OAUTH-WG] Signature = crypto
=  
I am not sure = I buy this. For instance, RSA-SHA1 is _not_ a signature scheme, PKCS#11 = does establish a signature scheme based on RSA + SHA-1.
 
So to delve = beyond the level of abstraction of 'authentication mechanism name' you = need to point to a separate spec for both signing and = verification.
=  
I am not sure = how much one needs to do beyond defining the byte representation of what = needs to be signed.
 

Some MACs = require random pads in addition to keys. Those won't fit into this = abstraction but I don't think we need absolute generality = here.

On Fri, Dec = 4, 2009 at 11:25 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Point = where?
 
I didn=92t mean new spec = for the algorithm, just for how it is used with the OAuth authentication = scheme.
 
EHL
 
From: Breno [mailto:breno.demedeiros@gmail.com] 
= Sent: Friday, December 04, 2009 11:20 = AM
To: Brian = Eaton
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)

Subject:&nbs= p;Re: [OAUTH-WG] Signature crypto
 
There is no = need to publish a new spec for a new MAC algorithm. MAC algorithms = typically go through certification (e.g., NIST) and have detailed specs, = including test vectors for interoperability.
=  

For OAuth, if you = want to explicitly support a new MAC algorithm you will not need to = change the transport and you just have to point to the particular spec = that defines the MAC algorithm.

On Fri, Dec = 4, 2009 at 11:12 AM, Brian Eaton <beaton@google.com> wrote:

On Fri, Dec 4, = 2009 at 11:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I am = trying to avoid the need to publish a specification every time you = want
> to add a new MAC-based algorithm.

People are = going to end up needing to write new code every time they

want to add a = new MAC-based algorithm.

Cheers,
Brian




-- 
Breno de Medeiros

=




-- 
Breno de = Medeiros

________________________________= _______________

OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
=



--
Breno de = Medeiros


= --Apple-Mail-2-710692814-- From beaton@google.com Tue Dec 8 22:42:55 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB7F3A6AD9 for ; Tue, 8 Dec 2009 22:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXc-+PGvkjZl for ; Tue, 8 Dec 2009 22:42:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id CF00E28C104 for ; Tue, 8 Dec 2009 22:42:53 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id nB96gdYO005748 for ; Wed, 9 Dec 2009 06:42:41 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260340961; bh=XuSMSbU15RpXdk4USB6O7vxruQ8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ONhBVaDMHvZhGIS/Hl7Bfblg1yFSakBL/HoXfNKoAYJVLTlf4QVVGCUJ3Rlv+oYlX JsEAV8F3GMyaDULATW4Ew== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=YZZgHVXUwDjcnuvXbd2eV/8pRARTupSOI8we8cacY9l+fDfjn3jTZ1dFWsilMeTsF xHB3VA74/nkmQccJrBGEw== Received: from pwi15 (pwi15.prod.google.com [10.241.219.15]) by wpaz17.hot.corp.google.com with ESMTP id nB96gbDZ022878 for ; Tue, 8 Dec 2009 22:42:37 -0800 Received: by pwi15 with SMTP id 15so2178552pwi.23 for ; Tue, 08 Dec 2009 22:42:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.89.3 with SMTP id r3mr66973rvl.283.1260340956829; Tue, 08 Dec 2009 22:42:36 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343785293CC2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378529390D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293CC2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 8 Dec 2009 22:42:36 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Token Access Authentication Scheme Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 06:42:55 -0000 On Mon, Dec 7, 2009 at 11:52 PM, Eran Hammer-Lahav wrote: > Can you list the use cases it doesn't meet? This is largely a cosmetic rewrite of 1.0 > with the exception of directly supporting form-encoded parameters which is still > being discussed. Your reference is to a post about mostly non-HTTP use cases. There are basically two use cases for the crypto in OAuth 1.0, and one major problem. Major problem: people can't figure out the signature base string. The new authentication spec does nothing to fix this, which is a shame. It is solvable. Use case #1: security for people who won't use https. We seem to have concluded that this isn't achievable. [1] Use case #2: security for people who need to send messages through untrusted third-parties. The new authentication spec makes this much, much harder. Here are a few examples of places where people are using OAuth to send messages through untrusted third-parties. Every single one of these use cases is broken by the token-auth spec [2]. If we can't solve these problems, there is very little point in message authentication at all. For example: - signed URLs embedded in the browser [3] - opensocial identity parameters [4] - google-specific identity parameters [5] - intermediate xmpp servers [6] - intermediate sip servers [6] We should be trying to make those use cases *easier*, not make them impossible. If we push a new OAuth spec that drops these use cases, we've done more harm than good. Cheers, Brian [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00762.html [2] http://www.ietf.org/id/draft-hammer-http-token-auth-00.txt [3] http://www.ietf.org/mail-archive/web/oauth/current/msg00689.html [4] http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html#gadgets.io.makeRequest [5] http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAuth [6] http://www.ietf.org/mail-archive/web/oauth/current/msg00513.html From eran@hueniverse.com Tue Dec 8 23:13:45 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229B73A6984 for ; Tue, 8 Dec 2009 23:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KG2zuZ36xCVx for ; Tue, 8 Dec 2009 23:13:44 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D623E3A691F for ; Tue, 8 Dec 2009 23:13:43 -0800 (PST) Received: (qmail 26943 invoked from network); 9 Dec 2009 07:13:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Dec 2009 07:13:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 9 Dec 2009 00:10:59 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Wed, 9 Dec 2009 00:10:28 -0700 Thread-Topic: Vacation Thread-Index: Acp4nrAWMJo8eUSQSKKUIgHOcbTmIw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437852940FD@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] Vacation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 07:13:45 -0000 I'll be taking some time off until the end of the year. I will continue to = monitor the list but am not expecting to publish any new drafts. Happy Holidays! EHL From benl@google.com Wed Dec 9 00:42:33 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA853A6912 for ; Wed, 9 Dec 2009 00:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVtJD2NlSvgg for ; Wed, 9 Dec 2009 00:42:31 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 7254C3A688B for ; Wed, 9 Dec 2009 00:42:30 -0800 (PST) Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id nB98gHiH022763 for ; Wed, 9 Dec 2009 08:42:17 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260348137; bh=t5bNJXF71ii/gpA/tNDt9hQNftc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Opoj+apflHjPBb3pjRTz69aEvkZsBhwXN4RGJQpyLOAghuVIQY39z4SrVFcbE8ZZi mUGdHyvRtg/YEyR6ccJow== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=iAaLE0ZVrgV54r9iplTPiOeQ9DzqEyAp0le2n7a6q0BaIi4Is99Xm3ydtGakH++/w JvWUyEpP+r1vRmIs6hYYw== Received: from ywh42 (ywh42.prod.google.com [10.192.8.42]) by spaceape14.eur.corp.google.com with ESMTP id nB98gE8J023891 for ; Wed, 9 Dec 2009 00:42:14 -0800 Received: by ywh42 with SMTP id 42so6121534ywh.28 for ; Wed, 09 Dec 2009 00:42:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.151.21.1 with SMTP id y1mr16126740ybi.3.1260348126240; Wed, 09 Dec 2009 00:42:06 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 9 Dec 2009 08:42:06 +0000 Message-ID: <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> From: Ben Laurie To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 08:42:33 -0000 On Tue, Dec 8, 2009 at 3:30 AM, Manger, James H wrote: >> This means servers using a salt/hash today to store their users' >> passwords will have to provide that to the client in order to make this >> work (which takes away the ability to make this work without a >> challenge). >> >> So while this looks like an interesting idea, it won't work to >> bootstrap existing credentials in most servers. > > > I think what you are asking for is theoretically impossible. Given a user= -id & password: > 1. Authenticate a standalone request (with no real-time data from the ser= ver first); > 2. Don't send the password in the clear; > 3. The server can use an existing password database that stores salted pa= ssword hashes. > > If you don't drop 3, either the salt has to be sent to the client (violat= ing #1), or the password has to be sent in the clear so the server can redo= the hash to compare (violating #2). > > If you drop 1, you can use password-authenticated key agreement schemes (= such as EKE, SRP, PAK...; see http://en.wikipedia.org/wiki/Password-authent= icated_key_agreement). These are the ultimate password-based protocols (in = practise and in theory). An attacker can only make 1 password guess per run= of the protocol -- they cannot perform an off-line dictionary attack. Thes= e algorithms use the maths of public-key crypto. Patent issues have often c= louded the use of these algorithms [I know nothing about the patent issues]= . A TLS-layer spec exists [RFC 5054]. I guess an HTTP-layer version could b= e defined, but I am not sure it could adds enough value over the TLS-layer = spec. > > If you drop 2, you have BASIC. > > If you drop 3, you can use PBKDF2 with a nonce/timestamp chosen by client= as a salt (probably adding the user-id, algorithm names etc into the salt = as well), a huge number of iterations of a hash algorithm (eg chosen so the= computation takes ~1 second), then use the result as a MAC key. The "passw= ord" input to PBKDF2 can actually be hash(password||userid). The server nee= ds access to this hash in the clear. An attacker compromising the server's = account database can use hash(password||userid) to login as the user (witho= ut knowing the password). What about a Schnorr signature? Use it to sign a timestamp+nonce. If the server and client are synchronised (ish), you can do it in one round trip. If they are not, the server responds with an error and a time offset, the client tries again, and we're done. That gives you 1, 2 and 3, and also the better property that new passwords can be stored as g^x at the server instead of x, and so the server doesn't have a password equivalent. Replays are possible for a short time, if the server doesn't want to (or can't) store used timestamps+nonces. If it does want to, then no replay is possible. > > > > > > P.S. The following blog post (and various other posts in the same blog) h= as details about the password-based security in Office 2007 (and updates). > It uses a slight variation on PBKDF1: with 100,000 iterations of SHA-1 by= default. > http://blogs.msdn.com/david_leblanc/archive/2008/12/04/new-improved-offic= e-crypto.aspx > > > > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From James.H.Manger@team.telstra.com Wed Dec 9 04:28:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A7C3A67AF for ; Wed, 9 Dec 2009 04:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9-rJ5nTz7KD for ; Wed, 9 Dec 2009 04:28:31 -0800 (PST) Received: from mailipbo.ntcif.telstra.com.au (mailipbo.ntcif.telstra.com.au [202.12.233.29]) by core3.amsl.com (Postfix) with ESMTP id A5E643A6892 for ; Wed, 9 Dec 2009 04:28:30 -0800 (PST) Received: from unknown (HELO mailbi.ntcif.telstra.com.au) ([202.12.162.19]) by mailipbi.ntcif.telstra.com.au with ESMTP; 09 Dec 2009 23:28:19 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.ntcif.telstra.com.au (Postfix) with ESMTP id B4F24FF81; Wed, 9 Dec 2009 23:28:18 +1100 (EST) Received: from WSMSG3753.srv.dir.telstra.com (wsmsg3753.srv.dir.telstra.com [172.49.40.174]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 935B641D2B; Wed, 9 Dec 2009 23:27:54 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Wed, 9 Dec 2009 23:28:18 +1100 From: "Manger, James H" To: Ben Laurie Date: Wed, 9 Dec 2009 23:25:38 +1100 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp4q4jn3GmQohuRT1qeaQ0j9fEQ4wAG2Okg Message-ID: <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> In-Reply-To: <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 12:28:32 -0000 PiA+IEkgdGhpbmsgd2hhdCB5b3UgYXJlIGFza2luZyBmb3IgaXMgdGhlb3JldGljYWxseSBpbXBv c3NpYmxlLg0KPiA+IEdpdmVuIGEgdXNlci1pZCAmIHBhc3N3b3JkOg0KPiA+IDEuIEF1dGhlbnRp Y2F0ZSBhIHN0YW5kYWxvbmUgcmVxdWVzdA0KPiA+ICAgICh3aXRoIG5vIHJlYWwtdGltZSBkYXRh IGZyb20gdGhlIHNlcnZlciBmaXJzdCk7DQo+ID4gMi4gRG9uJ3Qgc2VuZCB0aGUgcGFzc3dvcmQg aW4gdGhlIGNsZWFyOw0KPiA+IDMuIFRoZSBzZXJ2ZXIgY2FuIHVzZSBhbiBleGlzdGluZyBwYXNz d29yZCBkYXRhYmFzZQ0KPiA+ICAgIHRoYXQgc3RvcmVzIHNhbHRlZCBwYXNzd29yZCBoYXNoZXMu DQouLi4NCj4gPiBJZiB5b3UgZHJvcCAzLCB5b3UgY2FuIHVzZSBQQktERjIuLi4gdGhhbiBhIE1B Qw0KDQoNCj4gV2hhdCBhYm91dCBhIFNjaG5vcnIgc2lnbmF0dXJlPw0KPiAuLi4NCj4gVGhhdCBn aXZlcyB5b3UgMSwgMiBhbmQgMywgYW5kIGFsc28gdGhlIGJldHRlciBwcm9wZXJ0eSB0aGF0IG5l dw0KPiBwYXNzd29yZHMgY2FuIGJlIHN0b3JlZCBhcyBnXnggYXQgdGhlIHNlcnZlciBpbnN0ZWFk IG9mIHgsIGFuZCBzbyB0aGUNCj4gc2VydmVyIGRvZXNuJ3QgaGF2ZSBhIHBhc3N3b3JkIGVxdWl2 YWxlbnQuDQoNCkkgZG9uJ3Qga25vdyBtdWNoIGFib3V0IFNjaG5vcnIgc2lnbmF0dXJlcy4NCg0K SSBhbSBzdXJlIHRoZXkgY2Fubm90IHNhdGlzZnkgIzM6IGllIHlvdSBoYXZlIGFuIGV4aXN0aW5n IERCIG9mIGhhc2hlZCBzYWx0ZWQgcGFzc3dvcmRzICh1c2VkIHRvLCBzYXksIHZlcmlmeSB3ZWIt Zm9ybSBsb2dpbnMpLCB0aGVuIHRyeSB0byBkZXBsb3kgU2Nobm9yciBzaWduYXR1cmVzLg0KDQpJ dCBsb29rcyBsaWtlIGEgc2VydmVyIGNvdWxkIGNyZWF0ZSBhIERCIHdpdGhvdXQgcGFzc3dvcmQg ZXF1aXZhbGVudHMgd2hlbiBwYXNzd29yZHMgYXJlIGVzdGFibGlzaGVkLCB3aGljaCBpcyBhbiBh ZHZhbnRhZ2UuDQoNCkkgYmVsaWV2ZSBhbiBlYXZlc2Ryb3BwZXIgY2FuIHBlcmZvcm0gYW4gb2Zm LWxpbmUgZGljdGlvbmFyeSBhdHRhY2sgaWYgdGhleSBzZWUgYSBTY2hub3JyIHNpZ25hdHVyZS4g SGVuY2UsIGl0IGRvZXMgbm90IHByb3ZpZGUgdGhlIHNlY3VyaXR5IGJlbmVmaXRzIG9mIGEgcGFz c3dvcmQtYXV0aGVudGljYXRlZCBrZXkgYWdyZWVtZW50IHNjaGVtZS4NCg0KUHJlc3VtYWJseSB5 b3Ugc3RpbGwgbmVlZCB0byBydW4sIHNheSwgUEJLREYyIHRvIChzbG93bHkpIGNvbnZlcnQgYSBw YXNzd29yZCB0byBhIGtleSB1c2VkIGluIHRoZSBTY2hub3JyIHNpZ25hdHVyZS4NCg0KSSB3b3Vs ZCBiZSByZWx1Y3RhbnQgdG8gcmVwbGFjZSBhIE1BQyAoZWcgSE1BQykgd2l0aCBhIFNjaG5vcnIg c2lnbmF0dXJlIGFzIEkgaGF2ZSBzZWVuIHNvIG11Y2ggbW9yZSB1c2Ugb2YgdGhlIGZvcm1lciB0 aGFuIHRoZSBsYXR0ZXIuIA0KDQoNCi0tIA0KSmFtZXMgTWFuZ2VyDQoNCg== From benl@google.com Wed Dec 9 07:52:09 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E615E28C0FF for ; Wed, 9 Dec 2009 07:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhn+b0k6OXx0 for ; Wed, 9 Dec 2009 07:52:09 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 1F4A328C12C for ; Wed, 9 Dec 2009 07:52:07 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id nB9Fptsa022978 for ; Wed, 9 Dec 2009 15:51:55 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260373916; bh=EbEVc0yXhPHTxTDJ53JmVMu7jL8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=H9XR/6SXoYQcOCgslsTmDTDten7sAW/IbFIwzYpZlgbRECuOoJOwP+Drua/FJqICD 6XFiKS39kRk788Yh3v5Nw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=O5+ePB72/mygFoeTsNm8UHhzmv4jQaiOycKP6Gns+CbAqb8PDX5DTUrfwwKSbh8wV h1AXSsqNch5X6bzoDoXVw== Received: from ywh11 (ywh11.prod.google.com [10.192.8.11]) by wpaz9.hot.corp.google.com with ESMTP id nB9FpqFo026039 for ; Wed, 9 Dec 2009 07:51:53 -0800 Received: by ywh11 with SMTP id 11so2460454ywh.9 for ; Wed, 09 Dec 2009 07:51:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.119.42 with SMTP id r42mr16703067ybc.68.1260373910242; Wed, 09 Dec 2009 07:51:50 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 9 Dec 2009 15:51:50 +0000 Message-ID: <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> From: Ben Laurie To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 15:52:10 -0000 On Wed, Dec 9, 2009 at 12:25 PM, Manger, James H wrote: >> > I think what you are asking for is theoretically impossible. >> > Given a user-id & password: >> > 1. Authenticate a standalone request >> > =A0 =A0(with no real-time data from the server first); >> > 2. Don't send the password in the clear; >> > 3. The server can use an existing password database >> > =A0 =A0that stores salted password hashes. > ... >> > If you drop 3, you can use PBKDF2... than a MAC > > >> What about a Schnorr signature? >> ... >> That gives you 1, 2 and 3, and also the better property that new >> passwords can be stored as g^x at the server instead of x, and so the >> server doesn't have a password equivalent. > > I don't know much about Schnorr signatures. > > I am sure they cannot satisfy #3: ie you have an existing DB of hashed sa= lted passwords (used to, say, verify web-form logins), then try to deploy S= chnorr signatures. Why are you sure of that? Seems easy to me (x is the hashed password, server can derive g^x from it). > It looks like a server could create a DB without password equivalents whe= n passwords are established, which is an advantage. > > I believe an eavesdropper can perform an off-line dictionary attack if th= ey see a Schnorr signature. Hence, it does not provide the security benefit= s of a password-authenticated key agreement scheme. I think you are wrong - I believe the attacker would have to know g^x to perform an offline attack. Although this is described as a public key, there's no need to make it public. > > Presumably you still need to run, say, PBKDF2 to (slowly) convert a passw= ord to a key used in the Schnorr signature. > > I would be reluctant to replace a MAC (eg HMAC) with a Schnorr signature = as I have seen so much more use of the former than the latter. Presumably because Schnorr signatures only recently came out of patent. > > > -- > James Manger > > From email@pbryan.net Wed Dec 9 08:32:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3A328C19D for ; Wed, 9 Dec 2009 08:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaMFxV1pYx3B for ; Wed, 9 Dec 2009 08:32:24 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 0858928C19B for ; Wed, 9 Dec 2009 08:32:24 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id 84EDC614E; Wed, 9 Dec 2009 16:32:12 +0000 (UTC) From: "Paul C. Bryan" To: Ben Laurie In-Reply-To: <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Dec 2009 08:31:48 -0800 Message-ID: <1260376308.6142.648.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 16:32:25 -0000 On Wed, 2009-12-09 at 15:51 +0000, Ben Laurie wrote: > On Wed, Dec 9, 2009 at 12:25 PM, Manger, James H > wrote: > >> > I think what you are asking for is theoretically impossible. > >> > Given a user-id & password: > >> > 1. Authenticate a standalone request > >> > (with no real-time data from the server first); > >> > 2. Don't send the password in the clear; > >> > 3. The server can use an existing password database > >> > that stores salted password hashes. > > ... > >> > If you drop 3, you can use PBKDF2... than a MAC > > > > > >> What about a Schnorr signature? > >> ... > >> That gives you 1, 2 and 3, and also the better property that new > >> passwords can be stored as g^x at the server instead of x, and so the > >> server doesn't have a password equivalent. > > > > I don't know much about Schnorr signatures. > > > > I am sure they cannot satisfy #3: ie you have an existing DB of hashed salted passwords (used to, say, verify web-form logins), then try to deploy Schnorr signatures. > > Why are you sure of that? Seems easy to me (x is the hashed password, > server can derive g^x from it). For my own edification: If x (private key) is just the existing salted hash in the database and y (public key) is simply g^x, presumably: a) The client needs to (somehow) be supplied y by the server—it can't be derived from the password because the client doesn't know what hashing algorithm the server used (nor the salt) to represent it the database. If true, doesn't this violate point 1 above? b) I'm wondering whether it would be acceptable to expose y (even if just to the client who would presumably already know the password in plaintext), given that x can easily be derived from it? This may be just more paranoia on my part than realistic concern. Paul > > > It looks like a server could create a DB without password equivalents when passwords are established, which is an advantage. > > > > I believe an eavesdropper can perform an off-line dictionary attack if they see a Schnorr signature. Hence, it does not provide the security benefits of a password-authenticated key agreement scheme. > > I think you are wrong - I believe the attacker would have to know g^x > to perform an offline attack. Although this is described as a public > key, there's no need to make it public. > > > > > Presumably you still need to run, say, PBKDF2 to (slowly) convert a password to a key used in the Schnorr signature. > > > > I would be reluctant to replace a MAC (eg HMAC) with a Schnorr signature as I have seen so much more use of the former than the latter. > > Presumably because Schnorr signatures only recently came out of patent. > > > > > > > -- > > James Manger > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From benl@google.com Wed Dec 9 08:35:25 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FFCC3A6820 for ; Wed, 9 Dec 2009 08:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O71nrzhlGCsp for ; Wed, 9 Dec 2009 08:35:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 08CC43A6AB0 for ; Wed, 9 Dec 2009 08:35:21 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id nB9GZ8To017492 for ; Wed, 9 Dec 2009 16:35:08 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260376509; bh=XI8aKGws5gqG4rEqsQnN9YovkQo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=PPBTXDLq0/+mP9ZGlQZ/KaCmfug9H31kqRwc8c6Gyfp8xXtY23VALcG+1yjMAmc1m iXsO4Lz4epduxPl9yclBg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=cyqUVfPkfSfgxzYcWaqZXGHJEp2DUOq8mQrtWFUaqgurpHfVgriRV3pMCmc1hG9i5 1cs0+v4fcaMyvK5471VUg== Received: from yxe27 (yxe27.prod.google.com [10.190.2.27]) by wpaz24.hot.corp.google.com with ESMTP id nB9GZ57Q031644 for ; Wed, 9 Dec 2009 08:35:06 -0800 Received: by yxe27 with SMTP id 27so6131981yxe.10 for ; Wed, 09 Dec 2009 08:35:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.119.42 with SMTP id r42mr16794748ybc.68.1260376505588; Wed, 09 Dec 2009 08:35:05 -0800 (PST) In-Reply-To: <1260376308.6142.648.camel@localhost> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> <1260376308.6142.648.camel@localhost> Date: Wed, 9 Dec 2009 16:35:05 +0000 Message-ID: <1b587cab0912090835n473d7acfw28990765f02fd738@mail.gmail.com> From: Ben Laurie To: "Paul C. Bryan" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 16:35:25 -0000 On Wed, Dec 9, 2009 at 4:31 PM, Paul C. Bryan wrote: > On Wed, 2009-12-09 at 15:51 +0000, Ben Laurie wrote: >> On Wed, Dec 9, 2009 at 12:25 PM, Manger, James H >> wrote: >> >> > I think what you are asking for is theoretically impossible. >> >> > Given a user-id & password: >> >> > 1. Authenticate a standalone request >> >> > =A0 =A0(with no real-time data from the server first); >> >> > 2. Don't send the password in the clear; >> >> > 3. The server can use an existing password database >> >> > =A0 =A0that stores salted password hashes. >> > ... >> >> > If you drop 3, you can use PBKDF2... than a MAC >> > >> > >> >> What about a Schnorr signature? >> >> ... >> >> That gives you 1, 2 and 3, and also the better property that new >> >> passwords can be stored as g^x at the server instead of x, and so the >> >> server doesn't have a password equivalent. >> > >> > I don't know much about Schnorr signatures. >> > >> > I am sure they cannot satisfy #3: ie you have an existing DB of hashed= salted passwords (used to, say, verify web-form logins), then try to deplo= y Schnorr signatures. >> >> Why are you sure of that? Seems easy to me (x is the hashed password, >> server can derive g^x from it). > > For my own edification: > > If x (private key) is just the existing salted hash in the database and > y (public key) is simply g^x, presumably: > > a) The client needs to (somehow) be supplied y by the server=97it can't b= e > derived from the password because the client doesn't know what hashing > algorithm the server used (nor the salt) to represent it the database. > If true, doesn't this violate point 1 above? The client would need to be supplied the hashing algorithm, not y (being supplied y wouldn't help, anyway). > b) I'm wondering whether it would be acceptable to expose y (even if > just to the client who would presumably already know the password in > plaintext), given that x can easily be derived from it? This may be just > more paranoia on my part than realistic concern. x cannot be easily derived from it, this is the discrete log problem, which is assumed hard. > > Paul > >> >> > It looks like a server could create a DB without password equivalents = when passwords are established, which is an advantage. >> > >> > I believe an eavesdropper can perform an off-line dictionary attack if= they see a Schnorr signature. Hence, it does not provide the security bene= fits of a password-authenticated key agreement scheme. >> >> I think you are wrong - I believe the attacker would have to know g^x >> to perform an offline attack. Although this is described as a public >> key, there's no need to make it public. >> >> > >> > Presumably you still need to run, say, PBKDF2 to (slowly) convert a pa= ssword to a key used in the Schnorr signature. >> > >> > I would be reluctant to replace a MAC (eg HMAC) with a Schnorr signatu= re as I have seen so much more use of the former than the latter. >> >> Presumably because Schnorr signatures only recently came out of patent. >> >> > >> > >> > -- >> > James Manger >> > >> > >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > From email@pbryan.net Wed Dec 9 08:40:30 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C9B3A6AF1 for ; Wed, 9 Dec 2009 08:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imn9-P3A1TIF for ; Wed, 9 Dec 2009 08:40:29 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by core3.amsl.com (Postfix) with ESMTP id 36A413A6B01 for ; Wed, 9 Dec 2009 08:40:29 -0800 (PST) Received: from [192.168.0.4] (S010600095baae0ff.vf.shawcable.net [174.1.50.199]) by maple.anode.ca (Postfix) with ESMTPSA id BDA63614E; Wed, 9 Dec 2009 16:40:17 +0000 (UTC) From: "Paul C. Bryan" To: Ben Laurie In-Reply-To: <1b587cab0912090835n473d7acfw28990765f02fd738@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> <1260376308.6142.648.camel@localhost> <1b587cab0912090835n473d7acfw28990765f02fd738@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Dec 2009 08:39:54 -0800 Message-ID: <1260376794.6142.653.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 16:40:30 -0000 On Wed, 2009-12-09 at 16:35 +0000, Ben Laurie wrote: > On Wed, Dec 9, 2009 at 4:31 PM, Paul C. Bryan wrote: > > On Wed, 2009-12-09 at 15:51 +0000, Ben Laurie wrote: > >> On Wed, Dec 9, 2009 at 12:25 PM, Manger, James H > >> wrote: > >> >> > I think what you are asking for is theoretically impossible. > >> >> > Given a user-id & password: > >> >> > 1. Authenticate a standalone request > >> >> > (with no real-time data from the server first); > >> >> > 2. Don't send the password in the clear; > >> >> > 3. The server can use an existing password database > >> >> > that stores salted password hashes. > >> > ... > >> >> > If you drop 3, you can use PBKDF2... than a MAC > >> > > >> > > >> >> What about a Schnorr signature? > >> >> ... > >> >> That gives you 1, 2 and 3, and also the better property that new > >> >> passwords can be stored as g^x at the server instead of x, and so the > >> >> server doesn't have a password equivalent. > >> > > >> > I don't know much about Schnorr signatures. > >> > > >> > I am sure they cannot satisfy #3: ie you have an existing DB of hashed salted passwords (used to, say, verify web-form logins), then try to deploy Schnorr signatures. > >> > >> Why are you sure of that? Seems easy to me (x is the hashed password, > >> server can derive g^x from it). > > > > For my own edification: > > > > If x (private key) is just the existing salted hash in the database and > > y (public key) is simply g^x, presumably: > > > > a) The client needs to (somehow) be supplied y by the server—it can't be > > derived from the password because the client doesn't know what hashing > > algorithm the server used (nor the salt) to represent it the database. > > If true, doesn't this violate point 1 above? > > The client would need to be supplied the hashing algorithm, not y > (being supplied y wouldn't help, anyway). Okay, sorry, I had the parties reversed, right client doesn't need y. It needs x. So, to have x, client would need to know: what hashing algorithm server used to store it in the database, and what salt was used? This still doesn't seem to avoid violating point 1. > > b) I'm wondering whether it would be acceptable to expose y (even if > > just to the client who would presumably already know the password in > > plaintext), given that x can easily be derived from it? This may be just > > more paranoia on my part than realistic concern. > > x cannot be easily derived from it, this is the discrete log problem, > which is assumed hard. > > > > > Paul > > > >> > >> > It looks like a server could create a DB without password equivalents when passwords are established, which is an advantage. > >> > > >> > I believe an eavesdropper can perform an off-line dictionary attack if they see a Schnorr signature. Hence, it does not provide the security benefits of a password-authenticated key agreement scheme. > >> > >> I think you are wrong - I believe the attacker would have to know g^x > >> to perform an offline attack. Although this is described as a public > >> key, there's no need to make it public. > >> > >> > > >> > Presumably you still need to run, say, PBKDF2 to (slowly) convert a password to a key used in the Schnorr signature. > >> > > >> > I would be reluctant to replace a MAC (eg HMAC) with a Schnorr signature as I have seen so much more use of the former than the latter. > >> > >> Presumably because Schnorr signatures only recently came out of patent. > >> > >> > > >> > > >> > -- > >> > James Manger > >> > > >> > > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > > From benl@google.com Wed Dec 9 08:45:37 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DD43A6ACA for ; Wed, 9 Dec 2009 08:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnU0c9NDQr6n for ; Wed, 9 Dec 2009 08:45:36 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 71F933A677E for ; Wed, 9 Dec 2009 08:45:35 -0800 (PST) Received: from spaceape23.eur.corp.google.com (spaceape23.eur.corp.google.com [172.28.16.75]) by smtp-out.google.com with ESMTP id nB9GjMCn022025 for ; Wed, 9 Dec 2009 08:45:23 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260377124; bh=RMcFGAmaghfq7r/MngkfI+dWdfA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Nm1kcD7j/fmbruBGvr1eq8TOuQxO8+etx9rNn56dEdQfrf97TvvgXrmeCSJbGd8Ac fHdhz77LzGGn0EmjYXcFw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=NABrLqrdUhdpBH10Em1JNgLu7F9DDS+cVUWcUQujfHKv5KOOg1p9B1y8uGYIK1uIe dT6oANMcW5OaUR5sbtWTg== Received: from yxe27 (yxe27.prod.google.com [10.190.2.27]) by spaceape23.eur.corp.google.com with ESMTP id nB9GjIYO003482 for ; Wed, 9 Dec 2009 08:45:20 -0800 Received: by yxe27 with SMTP id 27so6142229yxe.10 for ; Wed, 09 Dec 2009 08:45:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.179.12 with SMTP id b12mr16902815ybf.156.1260377116449; Wed, 09 Dec 2009 08:45:16 -0800 (PST) In-Reply-To: <1260376794.6142.653.camel@localhost> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> <1260376308.6142.648.camel@localhost> <1b587cab0912090835n473d7acfw28990765f02fd738@mail.gmail.com> <1260376794.6142.653.camel@localhost> Date: Wed, 9 Dec 2009 16:45:16 +0000 Message-ID: <1b587cab0912090845o1cb2d173ybfdf8da7a207aa64@mail.gmail.com> From: Ben Laurie To: "Paul C. Bryan" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2009 16:45:37 -0000 On Wed, Dec 9, 2009 at 4:39 PM, Paul C. Bryan wrote: > On Wed, 2009-12-09 at 16:35 +0000, Ben Laurie wrote: >> On Wed, Dec 9, 2009 at 4:31 PM, Paul C. Bryan wrote: >> > On Wed, 2009-12-09 at 15:51 +0000, Ben Laurie wrote: >> >> On Wed, Dec 9, 2009 at 12:25 PM, Manger, James H >> >> wrote: >> >> >> > I think what you are asking for is theoretically impossible. >> >> >> > Given a user-id & password: >> >> >> > 1. Authenticate a standalone request >> >> >> > =A0 =A0(with no real-time data from the server first); >> >> >> > 2. Don't send the password in the clear; >> >> >> > 3. The server can use an existing password database >> >> >> > =A0 =A0that stores salted password hashes. >> >> > ... >> >> >> > If you drop 3, you can use PBKDF2... than a MAC >> >> > >> >> > >> >> >> What about a Schnorr signature? >> >> >> ... >> >> >> That gives you 1, 2 and 3, and also the better property that new >> >> >> passwords can be stored as g^x at the server instead of x, and so = the >> >> >> server doesn't have a password equivalent. >> >> > >> >> > I don't know much about Schnorr signatures. >> >> > >> >> > I am sure they cannot satisfy #3: ie you have an existing DB of has= hed salted passwords (used to, say, verify web-form logins), then try to de= ploy Schnorr signatures. >> >> >> >> Why are you sure of that? Seems easy to me (x is the hashed password, >> >> server can derive g^x from it). >> > >> > For my own edification: >> > >> > If x (private key) is just the existing salted hash in the database an= d >> > y (public key) is simply g^x, presumably: >> > >> > a) The client needs to (somehow) be supplied y by the server=97it can'= t be >> > derived from the password because the client doesn't know what hashing >> > algorithm the server used (nor the salt) to represent it the database. >> > If true, doesn't this violate point 1 above? >> >> The client would need to be supplied the hashing algorithm, not y >> (being supplied y wouldn't help, anyway). > > Okay, sorry, I had the parties reversed, right client doesn't need y. It > needs x. > > So, to have x, client would need to know: what hashing algorithm server > used to store it in the database, and what salt was used? > > This still doesn't seem to avoid violating point 1. You are right, you have to violate either 1 or 3, still. Not sure why 3 is a requirement, though (or, at least, why one can't violate 1 in order to support 3 for transition, so long as after the transition 1 is not violated). > >> > b) I'm wondering whether it would be acceptable to expose y (even if >> > just to the client who would presumably already know the password in >> > plaintext), given that x can easily be derived from it? This may be ju= st >> > more paranoia on my part than realistic concern. >> >> x cannot be easily derived from it, this is the discrete log problem, >> which is assumed hard. >> >> > >> > Paul >> > >> >> >> >> > It looks like a server could create a DB without password equivalen= ts when passwords are established, which is an advantage. >> >> > >> >> > I believe an eavesdropper can perform an off-line dictionary attack= if they see a Schnorr signature. Hence, it does not provide the security b= enefits of a password-authenticated key agreement scheme. >> >> >> >> I think you are wrong - I believe the attacker would have to know g^x >> >> to perform an offline attack. Although this is described as a public >> >> key, there's no need to make it public. >> >> >> >> > >> >> > Presumably you still need to run, say, PBKDF2 to (slowly) convert a= password to a key used in the Schnorr signature. >> >> > >> >> > I would be reluctant to replace a MAC (eg HMAC) with a Schnorr sign= ature as I have seen so much more use of the former than the latter. >> >> >> >> Presumably because Schnorr signatures only recently came out of paten= t. >> >> >> >> > >> >> > >> >> > -- >> >> > James Manger >> >> > >> >> > >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > > > > From James.H.Manger@team.telstra.com Wed Dec 9 23:41:10 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9523A69D7 for ; Wed, 9 Dec 2009 23:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5eLPDYqxOpb for ; Wed, 9 Dec 2009 23:41:09 -0800 (PST) Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by core3.amsl.com (Postfix) with ESMTP id D358A3A68B4 for ; Wed, 9 Dec 2009 23:41:08 -0800 (PST) Received: from webi.vtcif.telstra.com.au (HELO mailbi.vtcif.telstra.com.au) ([202.12.142.19]) by mailipai.vtcif.telstra.com.au with ESMTP; 10 Dec 2009 12:18:27 +1100 Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 96A7D1DA82; Thu, 10 Dec 2009 12:18:26 +1100 (EST) Received: from wsmsg3756.srv.dir.telstra.com (wsmsg3756.srv.dir.telstra.com [172.49.40.84]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 3028941D40; Thu, 10 Dec 2009 12:18:02 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 10 Dec 2009 12:18:25 +1100 From: "Manger, James H" To: Ben Laurie , "OAuth WG (oauth@ietf.org)" Date: Thu, 10 Dec 2009 12:18:24 +1100 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp454yV51zcYJV5RFeJavib7rueTAATxPaw Message-ID: <255B9BB34FB7D647A506DC292726F6E1124AB83C38@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B1CDA67.3050800@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> In-Reply-To: <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 07:41:10 -0000 SmFtZXMgc2FpZDoNCj4+IEkgYmVsaWV2ZSBhbiBlYXZlc2Ryb3BwZXIgY2FuIHBlcmZvcm0gYW4g b2ZmLWxpbmUgZGljdGlvbmFyeSBhdHRhY2sNCj4+IGlmIHRoZXkgc2VlIGEgU2Nobm9yciBzaWdu YXR1cmUuIEhlbmNlLCBpdCBkb2VzIG5vdCBwcm92aWRlIHRoZQ0KPj4gc2VjdXJpdHkgYmVuZWZp dHMgb2YgYSBwYXNzd29yZC1hdXRoZW50aWNhdGVkIGtleSBhZ3JlZW1lbnQgc2NoZW1lLg0KDQpC ZW4gc2FpZDoNCj4gSSB0aGluayB5b3UgYXJlIHdyb25nIC0gSSBiZWxpZXZlIHRoZSBhdHRhY2tl ciB3b3VsZCBoYXZlIHRvIGtub3cgZ154DQo+IHRvIHBlcmZvcm0gYW4gb2ZmbGluZSBhdHRhY2su IEFsdGhvdWdoIHRoaXMgaXMgZGVzY3JpYmVkIGFzIGEgcHVibGljDQo+IGtleSwgdGhlcmUncyBu byBuZWVkIHRvIG1ha2UgaXQgcHVibGljLg0KDQpnIGlzIHB1YmxpYyAoc2FtZSBmb3IgYWxsIHVz ZXJzKS4NCnggaXMgZWl0aGVyOg0KLSBhIHBhc3N3b3JkIC0gd2hpY2ggdGhlIGF0dGFja2VyIGNh biBndWVzczsNCi0gUEJLREYyKHBhc3N3b3JkKSAtIHdoaWNoIHRoZSBhdHRhY2tlciBjYW4gY2Fs YyBmcm9tIGEgcGFzc3dvcmQgZ3Vlc3M7DQotIEgoc2FsdHxwYXNzd29yZCkgLSB3aGljaCB0aGUg YXR0YWNrZXIgY2FuIGNhbGMgZnJvbSBhIHBhc3N3b3JkIGd1ZXNzIGFzIHRoZSBzYWx0IHdhcyBz ZW50IGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50IGluIHRoZSBjbGVhci4NCg0KSGVuY2Ug YW4gYXR0YWNrZXIgdHJ5aW5nIGEgZGljdGlvbmFyeSBvZiBwYXNzd29yZHMsIGNhbiBjYWxjdWxh dGUgeCBmb3IgZWFjaCBwYXNzd29yZCBndWVzcywgdGhlbiB1c2UgdGhhdCB0byB0cnkgdG8gdmVy aWZ5IGEgU2Nobm9yciBzaWduYXR1cmUgLS0gYWxsIG9mZi1saW5lLg0KSXNuJ3QgdGhlcmUgYSBm dW5kYW1lbnRhbCByZWFzb24gd2h5IFNSUCwgUEFLRSwgSi1QQUtFIGV0YyBhbGwgbmVlZCBtb3Jl IHJvdW5kLXRyaXBzIHRvIGF2b2lkIG9mZi1saW5lIGF0dGFja3M/DQoNClRoZSBvbmUgYWR2YW50 YWdlIG9mIFBCS0RGMitTY2hub3JyIG92ZXIgUEJLREYyK01BQyBzZWVtcyB0byBiZSB0aGF0IHRo ZSBzZXJ2ZXIgY2FuIGF2b2lkIHN0b3JpbmcgYSBwYXNzd29yZCBlcXVpdmFsZW50Lg0KQSBkaXNh ZHZhbnRhZ2UgaXMgdGhhdCB0aGUgY2xpZW50IG5lZWRzIHRvIGtub3cgdGhlIGNvbW1vbiBwYXJh bWV0ZXJzIChnIGFuZCBxKSB0aGF0IHRoZSBzZXJ2ZXIgdXNlcywgcGx1cyB0aGUgUEJLREYyIHBl ci11c2VyIHBhcmFtZXRlcnMgKGl0ZXJhdGlvbiBjb3VudCwgc2FsdCkgLS0gbm90IGp1c3QgdGhl IGFsZ29yaXRobXMuIFBlcmhhcHMgdGhlIFBCS0RGMiBwYXJhbWV0ZXJzIGNvdWxkIGJlIHBlci1z ZXJ2ZXIsIGJ1dCB0aGF0IGNvbXByb21pc2VzIGl0cyBiZW5lZml0cy4NCg0KTmVpdGhlciB0aGlz IGFkdmFudGFnZSBub3IgZGlzYWR2YW50YWdlIGlzIGNydWNpYWwgKGVnIHRoZXkgYXJlIG5vdCBh cyBpbXBvcnRhbnQgYXMgZWxpbWluYXRpbmcgb2ZmLWxpbmUgZGljdGlvbmFyeSBhdHRhY2tzLCBm b3IgaW5zdGFuY2UpLg0KDQpNeSBndXQgZmVlbGluZyBpcyB0aGF0IFBCS0RGMitNQUMgaXMgYmV0 dGVyIGluIHByYWN0aXNlLiBJdCBzdXBwb3J0cyBjbGllbnQtY2hvc2VuIFBCS0RGMiBzYWx0IGFu ZCBpdGVyYXRpb24gY291bnQgdmFsdWVzICh0aGF0IGNhbiB2YXJ5IGJ5IGRldmljZSBhbmQgQ1BV IHBvd2VyKSB0byBtYWtlIG9mZi1saW5lIGRpY3Rpb25hcnkgYXR0YWNrcyBhd2t3YXJkLCB3aXRo b3V0IHJlcXVpcmluZyB1c2VyLXNwZWNpZmljIGtub3dsZWRnZSBmcm9tIHRoZSBzZXJ2ZXIuDQoN Ci0tDQpKYW1lcyBNYW5nZXINCg== From benl@google.com Thu Dec 10 01:49:09 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961F23A688B for ; Thu, 10 Dec 2009 01:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0wcpGGb2IB3 for ; Thu, 10 Dec 2009 01:49:08 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 99E9D3A677C for ; Thu, 10 Dec 2009 01:49:08 -0800 (PST) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id nBA9muRI032694 for ; Thu, 10 Dec 2009 01:48:56 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1260438537; bh=izVqsZ+C2N9j2SDOFjf5caIGlR8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=GzuEAJg/kPbnCPjSxp5AMw+UUFPBmEHULKRR/uWuVswXsAqTJYc8qtLCoO/riXzB1 0DkzZAH6vB9JY2qsW4CuQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=XSzndEKHy7ZdJ4A/q/VWiNYcZ45QAY1nbO4EDfk3mKQ0uxsXqfOrknsSmVfCqmkBu 2deY5vtyjRfDfEL6iyoWg== Received: from qyk26 (qyk26.prod.google.com [10.241.83.154]) by kpbe15.cbf.corp.google.com with ESMTP id nBA9mbXV026741 for ; Thu, 10 Dec 2009 01:48:55 -0800 Received: by qyk26 with SMTP id 26so3716731qyk.5 for ; Thu, 10 Dec 2009 01:48:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.92.203 with SMTP id s11mr1378860qcm.19.1260438535064; Thu, 10 Dec 2009 01:48:55 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124AB83C38@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB83C38@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 10 Dec 2009 09:48:54 +0000 Message-ID: <1b587cab0912100148n18be4450if1de9ddc313e589e@mail.gmail.com> From: Ben Laurie To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 09:49:09 -0000 On Thu, Dec 10, 2009 at 1:18 AM, Manger, James H wrote: > James said: >>> I believe an eavesdropper can perform an off-line dictionary attack >>> if they see a Schnorr signature. Hence, it does not provide the >>> security benefits of a password-authenticated key agreement scheme. > > Ben said: >> I think you are wrong - I believe the attacker would have to know g^x >> to perform an offline attack. Although this is described as a public >> key, there's no need to make it public. > > g is public (same for all users). > x is either: > - a password - which the attacker can guess; > - PBKDF2(password) - which the attacker can calc from a password guess; > - H(salt|password) - which the attacker can calc from a password guess as= the salt was sent from the server to the client in the clear. > > Hence an attacker trying a dictionary of passwords, can calculate x for e= ach password guess, then use that to try to verify a Schnorr signature -- a= ll off-line. > Isn't there a fundamental reason why SRP, PAKE, J-PAKE etc all need more = round-trips to avoid off-line attacks? Yeah. I should try to get over jetlag before I think about crypto :-) > The one advantage of PBKDF2+Schnorr over PBKDF2+MAC seems to be that the = server can avoid storing a password equivalent. > A disadvantage is that the client needs to know the common parameters (g = and q) that the server uses, plus the PBKDF2 per-user parameters (iteration= count, salt) -- not just the algorithms. Perhaps the PBKDF2 parameters cou= ld be per-server, but that compromises its benefits. > > Neither this advantage nor disadvantage is crucial (eg they are not as im= portant as eliminating off-line dictionary attacks, for instance). > > My gut feeling is that PBKDF2+MAC is better in practise. It supports clie= nt-chosen PBKDF2 salt and iteration count values (that can vary by device a= nd CPU power) to make off-line dictionary attacks awkward, without requirin= g user-specific knowledge from the server. Neither of these are different to PBKDF2+Schnorr, AFAICS, so why is it bett= er? > > -- > James Manger > From llynch@civil-tongue.net Thu Dec 10 08:03:26 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6573A672F for ; Thu, 10 Dec 2009 08:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoBnkRaey8GG for ; Thu, 10 Dec 2009 08:03:25 -0800 (PST) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by core3.amsl.com (Postfix) with ESMTP id 3430D3A6A09 for ; Thu, 10 Dec 2009 08:03:25 -0800 (PST) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id nBAG39ng032543 for ; Thu, 10 Dec 2009 08:03:11 -0800 (PST) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id nBAG39XB032540 for ; Thu, 10 Dec 2009 08:03:09 -0800 (PST) (envelope-from llynch@civil-tongue.net) Date: Thu, 10 Dec 2009 08:03:09 -0800 (PST) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: oauth@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [OAUTH-WG] Interesting paper on Anonymous Delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:03:26 -0000 may be old news to some of you... Randomizable Proofs and Delegatable Anonymous Credentials http://eprint.iacr.org/2008/428 or http://cseweb.ucsd.edu/~hovav/papers/bcckls09.html Abstract We construct an e cient delegatable anonymous credentials system. Users can anonymously and unlinkably obtain credentials from any authority, delegate their credentials to other users, and prove possession of a credential L levels away from a given authority. The size of the proof (and time to compute it) is O(Lk), where k is the security parameter. The only other construction of delegatable anonymous credentials (Chase and Lysyanskaya, Crypto 2006) relies on general non-interactive proofs for NP-complete languages of size k (2L). We revise the entire approach to constructing anonymous credentials and identify randomizable zero-knowledge proof of knowledge systems as the key building block. We formally dene the notion of randomizable non-interactive zero-knowledge proofs, and give the rst instance of controlled rerandomization of non-interactive zero-knowledge proofs by a third-party. Our construction uses Groth-Sahai proofs (Eurocrypt 2008). - Lucy From James.H.Manger@team.telstra.com Sun Dec 13 18:03:42 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DD33A698F for ; Sun, 13 Dec 2009 18:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=-1.881, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZIDMMWnTu35 for ; Sun, 13 Dec 2009 18:03:42 -0800 (PST) Received: from mailipao.vtcif.telstra.com.au (mailipao.vtcif.telstra.com.au [202.12.144.27]) by core3.amsl.com (Postfix) with ESMTP id A17693A698C for ; Sun, 13 Dec 2009 18:03:40 -0800 (PST) Received: from maili.vtcif.telstra.com.au (HELO mailai.vtcif.telstra.com.au) ([202.12.142.17]) by mailipai.vtcif.telstra.com.au with ESMTP; 14 Dec 2009 11:40:34 +1100 Received: from mail.cdn.telstra.com.au (localhost [127.0.0.1]) by mailai.vtcif.telstra.com.au (Postfix) with ESMTP id 7BE8D1DA86; Mon, 14 Dec 2009 11:40:34 +1100 (EST) Received: from WSMSG3701.srv.dir.telstra.com (wsmsg3701.srv.dir.telstra.com [172.49.40.169]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA20770; Mon, 14 Dec 2009 11:40:33 +1100 (EST) Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 14 Dec 2009 11:40:32 +1100 From: "Manger, James H" To: Ben Laurie Date: Mon, 14 Dec 2009 11:40:31 +1100 Thread-Topic: [OAUTH-WG] Request for proposals on bootstrapping usernames Thread-Index: Acp5fgTJyQXsWynDTdyAhSkngCzSfAC0cJSA Message-ID: <255B9BB34FB7D647A506DC292726F6E1124D53D750@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA9506F@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E723437852939CC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB83C38@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912100148n18be4450if1de9ddc313e589e@mail.gmail.com> In-Reply-To: <1b587cab0912100148n18be4450if1de9ddc313e589e@mail.gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 02:03:43 -0000 SSBzYWlkOg0KPiA+IFRoZSBvbmUgYWR2YW50YWdlIG9mIFBCS0RGMitTY2hub3JyIG92ZXIgUEJL REYyK01BQyBzZWVtcyB0byBiZSB0aGF0DQo+ID4gdGhlIHNlcnZlciBjYW4gYXZvaWQgc3Rvcmlu ZyBhIHBhc3N3b3JkIGVxdWl2YWxlbnQuDQo+ID4NCj4gPiBBIGRpc2FkdmFudGFnZSBpcyB0aGF0 IHRoZSBjbGllbnQgbmVlZHMgdG8ga25vdyB0aGUgY29tbW9uIHBhcmFtZXRlcnMNCj4gPiAoZyBh bmQgcSkgdGhhdCB0aGUgc2VydmVyIHVzZXMsIHBsdXMgdGhlIFBCS0RGMiBwZXItdXNlciBwYXJh bWV0ZXJzDQo+ID4gKGl0ZXJhdGlvbiBjb3VudCwgc2FsdCkgLS0gbm90IGp1c3QgdGhlIGFsZ29y aXRobXMuDQo+ID4gUGVyaGFwcyB0aGUgUEJLREYyIHBhcmFtZXRlcnMgY291bGQgYmUgcGVyLXNl cnZlciwNCj4gPiBidXQgdGhhdCBjb21wcm9taXNlcyBpdHMgYmVuZWZpdHMuDQo+ID4NCj4gPiBO ZWl0aGVyIHRoaXMgYWR2YW50YWdlIG5vciBkaXNhZHZhbnRhZ2UgaXMgY3J1Y2lhbCAoZWcgdGhl eSBhcmUNCj4gPiBub3QgYXMgaW1wb3J0YW50IGFzIGVsaW1pbmF0aW5nIG9mZi1saW5lIGRpY3Rp b25hcnkgYXR0YWNrcywgZm9yIGluc3RhbmNlKS4NCj4gPg0KPiA+IE15IGd1dCBmZWVsaW5nIGlz IHRoYXQgUEJLREYyK01BQyBpcyBiZXR0ZXIgaW4gcHJhY3Rpc2UuDQo+ID4gSXQgc3VwcG9ydHMg Y2xpZW50LWNob3NlbiBQQktERjIgc2FsdCBhbmQgaXRlcmF0aW9uIGNvdW50IHZhbHVlcw0KPiA+ ICh0aGF0IGNhbiB2YXJ5IGJ5IGRldmljZSBhbmQgQ1BVIHBvd2VyKQ0KPiA+IHRvIG1ha2Ugb2Zm LWxpbmUgZGljdGlvbmFyeSBhdHRhY2tzIGF3a3dhcmQsDQo+ID4gd2l0aG91dCByZXF1aXJpbmcg dXNlci1zcGVjaWZpYyBrbm93bGVkZ2UgZnJvbSB0aGUgc2VydmVyLg0KDQpCZW4gcmVwbGllZDoN Cj4gTmVpdGhlciBvZiB0aGVzZSBhcmUgZGlmZmVyZW50IHRvIFBCS0RGMitTY2hub3JyLCBBRkFJ Q1MsIHNvIHdoeSBpcyBpdA0KPiBiZXR0ZXI/DQoNCg0KQSBjbGllbnQgY2Fubm90IGNob29zZSBh biBpdGVyYXRpb24gY291bnQgb2YgODAwMCBvbmUgZGF5LCBhbmQgOTAwMCB0aGUgbmV4dCBkYXkg aWYgdGhlIHNlcnZlciBoYXMgc3RvcmVkIGdeUEtCREYyKHBhc3N3b3JkLHNhbHQsaXRlcmF0aW9u cykgdG8gYXZvaWQgaGF2aW5nIGEgcGFzc3dvcmQgZXF1aXZhbGVudC4gVGhlIHNhbHQgYW5kIGl0 ZXJhdGlvbiBjb3VudCBhcmUgZml4ZWQgZm9yIGEgZ2l2ZW4gcGFzc3dvcmQgdmVyaWZpZXIuDQoN CklmIGluc3RlYWQgYSBzZXJ2ZXIgc3RvcmVzIHRoZSBwYXNzd29yZCBpbiB0aGUgY2xlYXIsIHRo ZW4gYSBjbGllbnQgZ2V0cyB0aGUgc2VjdXJpdHkgYWR2YW50YWdlIG9mIGNob29zaW5nIGEgcmFu ZG9tIHNhbHQgYW5kIGR5bmFtaWNhbGx5IGNob29zaW5nIGFuIGl0ZXJhdGlvbiBjb3VudCBpbiBl YWNoIGxvZ2luIGZvciBQQktERjIrTUFDIG9yIFBCS0RGMitTY2hub3JyLg0KDQpUaGUgb25seSBy ZWFzb24gTUFDIGlzIGJldHRlciB0aGFuIFNjaG5vcnIgaW4gdGhpcyBjYXNlIGlzIHRoYXQgSSBh bSBtb3JlIGZhbWlsaWFyIHdpdGggTUFDcyAoZWcgdGhlcmUgYXJlIG1vcmUgaW1wbGVtZW50YXRp b25zLCBBUElzLCBzZWN1cml0eSBhbmFseXNpcyBldGMpLiBJbiB0aGlzIGNhc2UgU2Nobm9yciBv ZmZlcnMgbm8gYWR2YW50YWdlcyBzbyBJIHdvdWxkIHByZWZlciB0byBhdm9pZCBpdHMgdXNlIG9m IHB1YmxpYyBrZXkgY3J5cHRvLiBJIGhhdmUgbmV2ZXIgaGVhcmQgb2YgdXNpbmcgUEJLREYyIHdp dGggU2Nobm9yciBiZWZvcmUgdGhpcyB0aHJlYWQgc28gSSBhbSBub3QgdG90YWxseSBjb25maWRl bnQgaXQgaXMgYXMgc2VjdXJlIGFzIEkgYXNzdW1lLg0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K From recordond@gmail.com Tue Dec 15 07:30:52 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D093A6A89 for ; Tue, 15 Dec 2009 07:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7mk57prv3J2 for ; Tue, 15 Dec 2009 07:30:50 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 436123A6A7D for ; Tue, 15 Dec 2009 07:30:50 -0800 (PST) Received: by iwn33 with SMTP id 33so2816728iwn.29 for ; Tue, 15 Dec 2009 07:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=pZ2lfLMxHBdzgt38n/Qo1P+O3JMBL45bs2kljmapsqE=; b=jQiXH8BSJ/e9lGFzOoDss6S/SNw2qId+tuMvNcwD9fCKI1msqEMe06oBuxXLyXF1qg xNiXcZjASsq3ZKr6aV2hLEDZLv2MiLpwEgIyPxyv8aaIkoeNao9fCq1ZBXpeeEfjuwcw KOGjSzOgQq5UQ/jkfKaloKoZ8Bcnv3fcn6IRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=S/qn4ya6Kz20xFqfsKpTvWrw5QIvYdDybwQb7PyTf1Nu5YpVOoWTpCruE5Q62KMVPI UVABCBB62gZ7zycqS5PCXQL0tD4EGPUU5PoQdNDGNEMQG12Ze1Mz/vHut4MVNNFiGFkl bUUzIb34zKyMDGY0vPM6nznTD09e4CmPXL1S4= MIME-Version: 1.0 Received: by 10.231.158.205 with SMTP id g13mr158795ibx.30.1260891033579; Tue, 15 Dec 2009 07:30:33 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Dec 2009 10:30:33 -0500 Message-ID: From: David Recordon To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: [WRAP] Fw: AGENDA: OAuth WRAP Discussion at Facebook: Dec, 8th X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 15:30:52 -0000 Forwarding these notes to the IETF WG as well, thanks for posting them Bria= n! ---------- Forwarded message ---------- From: Brian Eaton Date: Tue, Dec 15, 2009 at 2:51 AM Subject: Re: [WRAP] Fw: AGENDA: OAuth WRAP Discussion at Facebook: Dec, 8th To: oauth-wrap-wg@googlegroups.com On Fri, Dec 4, 2009 at 3:00 PM, David Recordon wrote: > Sorry for the late notice, but we're hosting a small meeting to go > over some Facebook Connect driven use cases for WRAP this coming > Tuesday at our office in Palo Alto. =A0We're really limited on space, so > please let me know if you'd also like to attend instead of just > showing up. :) Sorry for the delay in posting the meeting minutes. =A0I blame David. OAuth WRAP for Pure Javascript Clients Meetup Username/Password flow for FaceBook: - only exposed to trusted partners - only recommended if partner cannot open a web browser, e.g. devices - examples: xbox, FB iphone app. - main reason for not opening a web browser is user experience - requests are signed with md5 and API key - FB would be willing to give that up, replace with sending API key over ht= tps - some risk of password cracking with this API - Y! and Google have similar interfaces for similar use cases, but sometimes require CAPTCHA for rate limiting - the API key can also help rate limiting, but not if every device has the same API key Old Token flow for FaceBook Direct user to http://facebook.com/login.php?api_key=3DXXX&next=3Dhttp://ww= w.app.com/callback User approves, dialog redirects to http://www.app.com/callback?auth_token= =3DYYY Use case is mainly for old desktop/mobile apps, and some web sites. Very similar to OAuth 1.0. Passing control back to desktop app uses various tricks: - desktop app runs a web server on localhost - desktop app reads URL from web page Above use cases very similar to rich client app profile in WRAP. Third use case: if app really can't get token back from FB, there is a flow where the desktop app creates a token, then user approves token in web browser. =A0WRAP requires that user cut and paste verification code back into app instead. =A0This has same security problem as OAuth 1.0 with session fixation. Security: requires API key embedded in client apps, no good way to protect the API key. NetFlix Type Flow There are use cases where entering codes/text on devices is hard, because input tools are limited or non-existent. =A0For example: - user turns on television, plugs in new device - device talks to NetFlix server, gets verification code - verification code displayed on TV screen - user visits netflix.com, logs in. - user copies code from TV screen to netflix - user clicks "OK" on TV remote - device is now authorized to fetch user's data from NetFlix. This flow is basically OAuth 1.0, and has the same session fixation attack. =A0But it's a major usability win on some devices. =A0We think we can find appropriate messaging to make session fixation attacks unlikely to succeed. =A0Seems like a useful WRAP profile. FB Connect Flow Used for both desktop apps and web apps. Direct user to http://facebook.com/login.php?api_key=3DXXX&next=3Dhttp://ww= w.app.com/callback&return_session=3D1 User approves, dialog redirects to http://www.app.com/callback?session=3DYY= Y Use same tricks to pass control back to desktop apps. Web apps can use server-side callback URL, or they can use browser-based cross-domain communication via URL fragments/window.postMessage/Flash. =A0Server side callback URL is http://www.app.com/xd_receiver.htm. Requires preregistration of next URLs, tied to API key. Security: comes from next URL validation rather than API key, no need for API secret. By default, session expires in hours, but refresh happens automatically via background javascript pings. =A0Session expires automatically when user logs out of facebook. =A0There is also an option for apps to ask for "offline access", in which case session token never expires. Slightly simplified version of OAuth WRAP Rich App profile, but there really is no equivalent in WRAP. Callback URL validation is complicated, see Brent's note to oauth-wrap-wg mailing list on this. Two risks from callback URLs: one is spam, the other is leaking session tokens via open redirectors or referers to third-party content. Spam is dealt with reactively. Session token leakage is sometimes prevented by passing tokens in URL hash fragment. =A0Developers have incentive not to register open redirectors as callback URL. Default behavior is to use xd_receiver.htm, which gets the security right, no leakage in referer or open redirector. There are use cases for both identity and data access, web site can call session.getLoggedInUser() to figure out who is at the browser. Identity messages are passed back via browser, signed with API key. Relying party can also make a server-to-server call to get identity associated with session. Interesting user experience optimization: what if the relying party site knows the user-id, but identity provider does not? =A0The RP can pass a hint on the user-id to the identity provider. =A0The identity provider can optimize the user experience by prefilling login boxes, or selecting automatically from multiple active sessions. General consensus: passing session token back on URL fragment is a good ide= a. Should this be a "javascript flow"? Should this even be a "javascript flow", or should it be independent of javascript bindings? On one hand, we want people to be able to use ActionScript and other client-side languages. =A0Thick javascript bindings may not be reusable across service providers. On the other hand, standardizing best practices is a good idea. Should we document best practices? Should we provide standard libraries that implement best practices? There is general consensus that we cannot standardize cross-domain transport entirely; there are dozens of ways to do this in the wild, with more being discovered all the time. =A0This is a technical problem, and there is going to be lots of innovation. =A0Maybe someday we can all standardize on window.postMessage, but browser support not prevalent enough yet. We can standardize bootstrapping trust cross-domain, though, if we are willing to require that relying party sites host a single URL. What is API key registration for? Main point is to get developer to agree to developer terms of service (TOS)= . Also used to get contact information for developer. Also provides a point from which to start building up reputation of apps. =A0(Apps start up with no permissions, then build up users and trust over time.) Proposed WRAP Profile to support JS clients (maybe based on rich app profile, maybe web app profile?) Client does full page redirect to authorization server: =A0 /authorization? =A0 =A0 =A0 client_id=3DABC =A0 =A0 =A0 callback=3Dhttp://client-site.example.com/somepage =A0 =A0 =A0 state=3D =A0 =A0 =A0 scope=3D Authorization server authenticates client via callback URL, asks user to approve. Authorization server redirects back to http://client-site.example.com/somepage# (parameters on fragment): =A0 state=3D... =A0 access_token=3D Client server uses token via various tricks, e.g. jsonp: =A0 Security risks here are basically around how long token is valid, and how it can leak. =A0 - referer headers =A0 - open redirectors =A0 - browser history =A0 - unencrypted http connections Existing WRAP use cases provide security via server-to-server calls via long-lived refresh token. FB security model is mostly around checking that the user is still at the browser, the browser cookies fill the same role as the refresh token. But FB also has an off-line access use case. General consensus is that it doesn't make sense to combine permanent access with pure javascript clients, pure javascript client can't even run if the user isn't present. =A0There are different use cases/risks/etc. How should we signal this new profile? - maybe we should define different URLs at the authorization server? - maybe we need a standard wrap_profile=3DX parameter? - Simpler for developers to know about a single URL? Can we standardize on a mechanism to refresh the session via browser cookie at the authorization server? Goal is to extend the lifetime on the session, but - only if the user is still logged in - without user interaction Does not require passing in old active token. No huge objections to doing this with iframe redirects, maybe a special parameter ispassive=3Dtrue or openid mode check-immediate. How do we pass back identity parameters as well? - additional signed blob in authentication redirect? (e.g FBConnect) - embedded signed parameters in access token? =A0(e.g Simple Web Token mode= l) - unsigned parameter in authentication redirect, only for use in javascript= ? If the first thing every developer does is ask who a particular token belongs to, why not just pass that along? Developers don't understand the technical differences between delegation protocols and authentication protocols, and they need them to be the same protocol. UX requirement: a single user approval page for both identity and delegatio= n. Does solving identity also require solving discovery? - probably not. =A0developers tend to hard code configuration for particular identity providers and service providers. Some security concerns about how identity is signed that aren't present for delegation use cases. =A0For identity, better to have public/private key signings. =A0For delegation, doesn't matter, most people are using HMAC. =A0Key management is much harder with HMAC. Do we need signing at all? =A0Yes, because in some use cases the authentication message is bounced through untrusted third-party (e.g. the browser). In other cases, no. =A0Just use a server-to-server call instead. =A0(e.g. client sends access token to Twitter, asks what user the token belongs to.) Not everyone is willing to pay the cost for a server-to-server call. Options: - pass it unsigned, but know it is only trustworthy for client-side display purposes. - make an API call, server-to-server, to verify it - sign it as an extra parameter (beaton says we need a standard way to do t= his) - make access tokens non-opaque, sign them -- You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group. To post to this group, send email to oauth-wrap-wg@googlegroups.com. To unsubscribe from this group, send email to oauth-wrap-wg+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=3Den. From benl@google.com Thu Dec 17 08:27:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB2E3A63EB for ; Thu, 17 Dec 2009 08:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.559 X-Spam-Level: X-Spam-Status: No, score=-104.559 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G68VV3CgLjA1 for ; Thu, 17 Dec 2009 08:27:30 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 5F2673A681E for ; Thu, 17 Dec 2009 08:27:29 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id nBHGRDiu017544 for ; Thu, 17 Dec 2009 16:27:13 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1261067233; bh=8xBCMGgL2zcHQK8LSKZRr3BL7Qc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RVHdy/3j9LhdjrUAwuft7031ygiWFjIRE8Ur1HYgMUuKnaTcU8/1vBpgYqAGYz9j9 h9e6NgHP/lDKfbe33VFWg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=OuTipn03TX/6xTSpBhjN52AArbN/W2d7xU29QDDxYpsAmDeXyYI0DDFwUi7T9yRtH aXM6i9tmhVo+HmEewPARw== Received: from qyk3 (qyk3.prod.google.com [10.241.83.131]) by wpaz17.hot.corp.google.com with ESMTP id nBHGRA5t003802 for ; Thu, 17 Dec 2009 08:27:10 -0800 Received: by qyk3 with SMTP id 3so975229qyk.1 for ; Thu, 17 Dec 2009 08:27:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.13.142 with SMTP id c14mr1526897qca.33.1261067230465; Thu, 17 Dec 2009 08:27:10 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1124D53D750@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95401@WSMSG3153V.srv.dir.telstra.com> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB83C38@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912100148n18be4450if1de9ddc313e589e@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124D53D750@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 17 Dec 2009 16:27:07 +0000 Message-ID: <1b587cab0912170827p4fd34d08w9045b88d07bf9a43@mail.gmail.com> From: Ben Laurie To: "Manger, James H" Content-Type: multipart/alternative; boundary=0015175764664f4f75047aef1891 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 16:27:32 -0000 --0015175764664f4f75047aef1891 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 14, 2009 at 12:40 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > I said: > > > The one advantage of PBKDF2+Schnorr over PBKDF2+MAC seems to be that > > > the server can avoid storing a password equivalent. > > > > > > A disadvantage is that the client needs to know the common parameters > > > (g and q) that the server uses, plus the PBKDF2 per-user parameters > > > (iteration count, salt) -- not just the algorithms. > > > Perhaps the PBKDF2 parameters could be per-server, > > > but that compromises its benefits. > > > > > > Neither this advantage nor disadvantage is crucial (eg they are > > > not as important as eliminating off-line dictionary attacks, for > instance). > > > > > > My gut feeling is that PBKDF2+MAC is better in practise. > > > It supports client-chosen PBKDF2 salt and iteration count values > > > (that can vary by device and CPU power) > > > to make off-line dictionary attacks awkward, > > > without requiring user-specific knowledge from the server. > > Ben replied: > > Neither of these are different to PBKDF2+Schnorr, AFAICS, so why is it > > better? > > > A client cannot choose an iteration count of 8000 one day, and 9000 the > next day if the server has stored g^PKBDF2(password,salt,iterations) to > avoid having a password equivalent. The salt and iteration count are fixed > for a given password verifier. > > If instead a server stores the password in the clear, then a client gets > the security advantage of choosing a random salt and dynamically choosing an > iteration count in each login for PBKDF2+MAC or PBKDF2+Schnorr. > > The only reason MAC is better than Schnorr in this case is that I am more > familiar with MACs (eg there are more implementations, APIs, security > analysis etc). In this case Schnorr offers no advantages so I would prefer > to avoid its use of public key crypto. I have never heard of using PBKDF2 > with Schnorr before this thread so I am not totally confident it is as > secure as I assume. > If you have as a design requirement that the server should store a password in the clear, then indeed there's no advantage to Schnorr. I thought no-one wanted to store passwords in the clear anymore, though. > > > -- > James Manger > > --0015175764664f4f75047aef1891 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Dec 14, 2009 at 12:40 AM, Manger= , James H <James.H.Manger@team.telstra.com> wrote:
I said:
> > The one advantage of PBKDF2+Schnorr over PBKDF2+MAC seems to be t= hat
> > the server can avoid storing a password equivalent.
> >
> > A disadvantage is that the client needs to know the common parame= ters
> > (g and q) that the server uses, plus the PBKDF2 per-user paramete= rs
> > (iteration count, salt) -- not just the algorithms.
> > Perhaps the PBKDF2 parameters could be per-server,
> > but that compromises its benefits.
> >
> > Neither this advantage nor disadvantage is crucial (eg they are > > not as important as eliminating off-line dictionary attacks, for = instance).
> >
> > My gut feeling is that PBKDF2+MAC is better in practise.
> > It supports client-chosen PBKDF2 salt and iteration count values<= br> > > (that can vary by device and CPU power)
> > to make off-line dictionary attacks awkward,
> > without requiring user-specific knowledge from the server.

Ben replied:
> Neither of these are different to PBKDF2+Schnorr, AF= AICS, so why is it
> better?


A client cannot choose an iteration count of 8000 one day, and 9000 t= he next day if the server has stored g^PKBDF2(password,salt,iterations) to = avoid having a password equivalent. The salt and iteration count are fixed = for a given password verifier.

If instead a server stores the password in the clear, then a client gets th= e security advantage of choosing a random salt and dynamically choosing an = iteration count in each login for PBKDF2+MAC or PBKDF2+Schnorr.

The only reason MAC is better than Schnorr in this case is that I am more f= amiliar with MACs (eg there are more implementations, APIs, security analys= is etc). In this case Schnorr offers no advantages so I would prefer to avo= id its use of public key crypto. I have never heard of using PBKDF2 with Sc= hnorr before this thread so I am not totally confident it is as secure as I= assume.

If you have as a design requirement that t= he server should store a password in the clear, then indeed there's no = advantage to Schnorr. I thought no-one wanted to store passwords in the cle= ar anymore, though.

=A0


--
James Manger


--0015175764664f4f75047aef1891-- From recordond@gmail.com Thu Dec 17 10:30:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1FD3A69CF for ; Thu, 17 Dec 2009 10:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe6Vz-mbW8+Q for ; Thu, 17 Dec 2009 10:30:38 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 6998C3A67A4 for ; Thu, 17 Dec 2009 10:30:38 -0800 (PST) Received: by iwn33 with SMTP id 33so1619930iwn.29 for ; Thu, 17 Dec 2009 10:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=3kXKR9OfzQI3IFiIG/z9E2y5VXliBipCmgzh7H++F08=; b=V7BLv9OJD6TFyTrYV4/SicK1o9AOLpm78DFNOf2wcWa4YDNbHDv/sOl/dsuiy/PXVw Aaqz6pYL3mD4G5hFM/x+v7G9Wvs7h1FiwDfBk24gpr60/YQQuerwWgfyNF3Glm/kbzNZ eAWxevYLADvAmmL2NvbJhC8j3iQzLT3u3+GTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=IovrSMafGgLkFQ9h7ocsinYolBVbbD7f3N73hM0An9PvT3y2p9jvAFmgEWjRCfwfgf 6qO476XJWDGXPRioJm8FRY1HnPu7/P2ttv+La0pZjdMfY/FPRyGuMRNnotgpVZh62rFZ zWZYErFOj1a4I0FHiqs8B4f1g/sxPIHyn0l04= MIME-Version: 1.0 Received: by 10.231.5.90 with SMTP id 26mr2680218ibu.42.1261074619744; Thu, 17 Dec 2009 10:30:19 -0800 (PST) In-Reply-To: References: Date: Thu, 17 Dec 2009 10:30:19 -0800 Message-ID: From: David Recordon To: oauth@ietf.org Content-Type: multipart/mixed; boundary=001517740988bec4f0047af0d033 Subject: [OAUTH-WG] Fwd: [WRAP] Proposed OAuth WRAP Client Only Profile X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:30:40 -0000 --001517740988bec4f0047af0d033 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We'll be discussing this on the WRAP list, but wanted to share where we're thinking with the working group as well. --David ---------- Forwarded message ---------- From: Luke Shepard Date: Thu, Dec 17, 2009 at 10:22 AM Subject: [WRAP] Proposed OAuth WRAP Client Only Profile To: "oauth-wrap-wg@googlegroups.com" Last Tuesday, we had an OAuth WRAP community meeting at Facebook. The main purpose of the discussion was to answer the question of how applications written primarily in JavaScript would interact with OAuth WRAP =96 specifically, we=92d like to figure out how to make products like Facebook Connect work without requiring server code. The outcome of the meeting was that we would create a new profile that doesn=92t require the Client Secret in order to make calls. We=92ve focused mostly on applications written entirely in Javascript, but it should also extend to other client-only apps such as desktop and mobile. The proposed addition to the spec is attached. It=92s the same as the Web App profile with the main difference that the Access Token is returned directly on the callback URL without requiring an extra round trip. Examples Thanks to Bret Taylor and the Friendfeed team for providing a great playground to illustrate the profiles with working code. - FriendFeed has an OAuth WRAP provider prototype, with the following endpo= ints: Authorize URL: https://friendfeed.com/account/wrap/authorize Access Token URL: https://friendfeed.com/account/wrap/access_token (no Refresh Token URL yet) - Web App profile demo: http://friendfeed-wrap.appspot.com/ (source: http://github.com/finiteloop/friendfeed-wrap-example ) - Client Only (Javascript) profile demo: http://open.lukeshepard.com/oauth-wrap/console/ (source: http://github.com/lshepard/oauth-wrap-demo ) Both of these examples do the same thing =96 get an access token and then fetch and render your Friendfeed news feed. The first does it on the server, the second entirely in JavaScript. Discussion In contrast to the Web Gadget Profile proposed earlier ( http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/cfafaa4ac= b5cf1e1?hl=3Den ) , this profile leaves all JavaScript specifics out of the spec. Sure, we need to use things like postMessage and whatever, but those can be handled in libraries and reference implementations. I also chose not to add a =93wrap_profile=94 parameter. I=92m a little worried that if we start identifying a bag of behavior by =93wrap_profile=94 then the spec will be less able to handle new profiles in the future, since each server will have to know about each profile name. I=92d love to hear ideas on how we can customize behavior between profiles while supporting future extensibility. Looking forward to all your feedback! - Luke -- You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group. To post to this group, send email to oauth-wrap-wg@googlegroups.com. To unsubscribe from this group, send email to oauth-wrap-wg+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=3Den. --001517740988bec4f0047af0d033 Content-Type: application/octet-stream; name="OAuth WRAP Client Only Profile (draft 2009-12-16).pdf" Content-Disposition: attachment; filename="OAuth WRAP Client Only Profile (draft 2009-12-16).pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: 0.1 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVXWnTJMdR/t6/om1ke9ayWn0fGGxW+66MLmzhBQNah0Is JsJGFtgiwsG/58mqJ7O7avrI2XAQgfRhdnq6s/J48qisqn7/UH5e/qFs5rIbqxr/teUwjeXU1uUf f1P+qvymfP/Ft0355tuyDv9/+wZ311Xby73x0vptqcupXqq+L978vvzgVdkP4Rl+vPp9+f6HTdWU Tfnq38vbd56Vr35XvnyF8euqq5e57hb8a6iHeW57/Gvqm2Yah+JqyHFuq64t45ADnsT//AhDtjrk F4UM+l5b3r6Ljyaw8Ovy1ceRiWOxmnqu+qYfy+1Ixc5IXVVTuHIV7oRuM1cziVJjO0RX9svbX0T2 34nsfy9+fD9+/CB+vL49K0S218/i9x/iAxK/m3zojz+KV9+LH1X8eB8fIBCoFzeOhUE8qmrbvmqm aUhUpdaIwhWpUQKjBgQXxsZhrHrYu7iA2BfR0EvUW1OXQZghijYF87/Xl7egv7q4iQJHKO4m8uPm oCRcEA3gIVEkPkSRoChAwrP8TXQVCYqSigDqE7sPTTX0U1eqIMe+UgRfgSBiqXVYjOexRjN21VgP sIZozOGUGEiwsFGVYAI64PABGlDND4GxRBcubpapatqR3NBfkxARoWEhAtzUwk23GpDab3zyt21b 1W3zkPw0LOUWhxNtpFZvxcWCGgIkCIKVt/AjKRwBRdATtFrcvNIsdTV2iNSHsMn0tw2xx2hsl65q mnlyk13RGD1HPchchProoLvZoBPUEcMJkGNOBtmDtqAmD4a6fqiapekfQXRmSkJ5NY/HZbsR2XEZ TpRUanozl2XAoDb6qA2CxOnA3TxUM9LhI+IScGob9WdGN45PBx4iU3xkzygC00yBqS+8R19gCOSP HG0EfRBYw6N8Iy5S9YTngiuo83jgMNR91c5I/n9elxjqsZpObJ372eTJ9kPTomya/eHP576ouca+ qWpJiHd5JGMUnqtJzWxNSxECNN8ccUFXWfCtGQomSnNz3OuxUdN3yHYLwpay6cjbfxmBcwHMHwF7 a1L8sbC5xmqC7q+iKMSwia3uYQMVAk37OdUKXXgTq+TmvwblNTXSvxnSf4LfwBmhTmoko0OTpZ/i VkREiOrRZjv3VTcha0Zt+nL632CIjWbSwKwB4ntQJmoYIoCaP3V93qpq4b1BSqumVnIe6bqprlAY NStWAOkiqREszsZKG5Cmoc12KhC1TmkDI2EC4GGkr9tqriXXKmgdvsWRjJEMkApmKcy3deYPoHh8 v9K4i+1hqeZFSqzAtg8dLdGxE5BLqU0YkAsXA0hYUy/1/6HeYMDiYB54XKT081y1XY+8f0j3PtbR 39bs45FA4mk7VOPsU57a2IyuFasqLmi1WCMLY6o+R//QrykIhKiH52aYqrmtgdYHOE+Hui90ZeDL mcw0VXBXmCUMvJeCzF+tLnoukOIEcw049NbdikG1Q2UxUl1EdspnhklDus5k6Hx2l5qPoOGIeNZj h3YZqnZA9HrADJaAtvNJhlKK8A4CBDLEimPJPoov43x9xsNqh3ZP20vl9ACvmrlsTLLED0Z+VS3j CVWYws0o4LKL3Rlzx/kxgCu3NLwNSUUFvgpN0Y9pr8fEcpg7hLkN7q/yFIe49zQxZxKEbZpE3amt VyblEdYYvCctNXixeuaL2stYDc2IBtdGnLvuXRK1UbVo0+Ykai9LhellqqaUbha1fTXvUDfVNKNV ueX3VP3S8bvmd6iBsr5WPfgygNrzLNsUa4809EytfyrZpqkrhO6d6t1Cp5U630ckkEIuh7RW9eRh 1/OYePgbJ4DmFFnc0+B5X6uE2iX12kPpmnGu6q6BnZwyFmtvQau4zGuMYaqAEn+AnIJcQhnDM+ZE 9oi6Ucr9YTe77dCNXjoEncC9Dw2qxwwVuUXCbIOikWmmMwqkvL6AYGiieFmWMDlOyMcPsHyk4W0K dBfOKAaqcenR2zw0eebyawWfRjIFQGpoMmuNi6DIvPBW5W3zUnnLqgjSNciEIpzav4MMKdEtMhuR J3voO/BSxGdSJnM5jyqe8goinkTYT8jbixTCXgvffKF6Wqp6QqvVTxfKuA6pCHADpqyjs/v8556p 0shEVmq+YNO4JLRXT/HmJDFbw58EN8Z7bzRSrsSscVSQcgCgbBBiUIGzKxoxp/cEwkVYNtrM/xOu TSQClNgmS/QzK1IDsLXAM8DzZo151Fx2dbUBcV7IwuNRYuxmLF20E8FzkR0LWU+Eoa7h2M1Ynlxa LHIGUO7RvQ9PDN7UTGYVSkmZqf+o4cJCjlMjYSn2SCN9P1cTsulD/vTE6XsCiHU5hRa0bg1F3Mmm BhMzuqIIsm0C12EtIIFgRDnoqXSktH31u6vJJyZb9dA3i4euTT5pPTpP2pTnRRqL7qagNrm14U1U aFZJTUwcMKev0BdvJ2HTfWyv5p03PsNOLFFGDkmdQ67znJDC+CDdeS8gHNuSrCGBbUx66KPovFdt s8BJzwy7nTYg1+cFEtndoEl0pHglQ8Rlw/L3saJIprrjgNR2zOa9z2fBiwyYfsJkfVX8tqGHXg+r Zj4EoHi02SEDt/0yrGxKnxxzg3oJey3q8tWbdO6UzQ9u78ZMH268WILuUCj2iw3mqG19MzOJr8s8 qq4ddAEJ5ktVZwpgKhE63RZoKbrpivzIc9ZuYyUkMppzx8Vj03PfxS0SaJRPx6VXapKkNLjqAYFE yaGrltanucxNOFYWkmrxmt019DCXTAOX6mJlW9yRcSdtRDG48XnTiqKf10mIcUxtjLvjTDZ38Kj4 1cE35dE9a9ToaSHR9lO1dM1Ive5l/I0fSSUBRD4xbRJm/KAoZDmNBegveOzboj8+tNjo9IiVTbVp OklCps12k6s2CaExjpasPKx3UOTYYi3GzXpM41e7q7qhrcYJ+w/cdGEgWsRwGZbQFFxWkgUnp9VU L0z5DCskYBrWu7KcrInHKG9jSgoEJtxd5EQGC633eatGCoYR8vvYsiBiOTpXUhw+ED2AWVmkNOEB Eg8QJEZ1M7bc+WJU5raUUm1FYC4SDtDjplmoZ35jNKC6+BvVxOd5MY5lvpBaJgULf4NLeWRuZtn/ 0WPe8IDkNmvaoiWH0E5rn6zxziOIUivb5OPu0oSgWPczxdkLivcl0UsGxQ8jbDDf8mgOG76wvQhd tEc09zMZCrsW/1Y+sTbKIT+Sr1g5+jj8XOjl+NXdJOsaLO+NWCSNHEF4x4aEBGAWVlNjhm93s22n V3XiuAs2mbq5kizlmPGO2F07LP1D+t+NXoQlP5xzhA6O07ZYWjCx7hbSkX63cwRfq75bsIdyHpFI g0P6EGyR7iSRrpNjxpuQMIpsXwR/03TBKMSYlNU6aarhnhUih78ZYxuCHueSUIylqGX0heJ00E2O 24x1OIFv0HDsxwUhMIy4p/FNIYUt3tLMp2L25Dut7ORHewhrtBsGD6ejzdBjIaWFX58xuIUaGNRa maZjsM3ZzmpaWp99Xv2RJHSCSxqa/kwardk5FNxJhLtqdrQdNlZ0UjieCRc32Mdmh6/v28J9hqZG 9XVIN8sEvokgkNljv++g+/KTPTwZRZjhE0R02RbKmTN1R7yqCqlg/GhwKI47iE2DlI0wccJHhldf C7Fpm2qpscLxiHzM0nR3CqLOTjEptOIn3FtotyjTgQXhUFqQgEGMlOx7rDDzupPMKBd8CNg27Z70 Z1tZKZ6Q1qMWGH/QrWhis+K6W9FgQKQvT7ei7ZAbu2VJB0sglZoyzOCucyNOseDkST/56a5Tj/M5 oStgIS3isAQ2mR0j6a1yYzshN3Zoch/TvfdAA8thbnTBAjsJ6glN3gQWZ5aCRhPE22qIIt5wud3r qblLgymtkT1DrzPRFOovMNvAoirdMI35vHiRw8PEKbidTTbuRiHjdE56mzLOYdYpgicJ9AOmXf0y nhjW/MA63hxfVcOBbQE1BBCGE73HRInqLfTsiyZLSOYBg+QAnM1CAb+zueEegaoaZtcUh1Sm2psM B2Fs3c3Y3qQRD5842oWVlRZqDdw+VEupyqhWsvkp0hkA9uA5ERevSKq1rPA/wutLmS+tO6NVPQQ+ WeeuukwgKNrDVivbMtHJeYgtKuuJ3B1MOsKuZNqbT+SNixQq6uWfRSPwmYguq+MzrzDobCAuNehZ aDLP1wE5UkY6RcbfibCY0fKqZuZMFdod0U/+/HM8jIYN7WY8qz1ZMTDqcQT0kTwG7Cc5KoV9BVuP Pd9SBaY0xZ4e4CzlAOfhtEKCBE6nIajtBIkYzbYnIKXmlhaAQAD2EcVsvsJcHmEb2aTST6gnwsjH Dv/ogU6JIRckt8JIpBPuJarBrgIc+ap4EtBjV4HsQEAwCd/WmwQEcjMv61c4kUsDcpYMDUM/u6E2 N3u7zmn2CAqzc+NHCm0mS0M4Ec8JFx3MfqV38CHVHr/yZn5jbgkX7/z3RVQ0yfFBjYckkAYi9c98 F3HOIUObcUwX5UgrFV1HjGsjiV9vj90IWNbK4WIiHQEk4f+BSYg23p4TZWGJrgheh7HJt6qGSk0X 03mPiRwjHau7QjdHZTZjzMqCMOmT4t2GnO1RVDU+DcBHPoEUmF0qWY6S3RtYuVu85b0GwBB1yJAS ULoYbeN7pxGvld3XxxFvewT2wSJC0HC8ASnPf2olzrspphlNSzLelriEkeKPTwIVoExLtOTmpJsT UE7Lf4CnJoMDn+FvxoYqmiOl4pFnQ1+YJvDiuogiamHZoLClac/YX5u5xgspb9nP28H77FuZes7+ NsOTNXXGJ2r4F8iBj3khAcsAwBhGkYwvSka1fJ6Zk0KlN2XIv2piSa5HFxH7+A9zvSJfmocZglJ7 3YWB4OK8RwETKJiApGemhHo3/nrcV8TCZ2i9Rd6PqwXlXVaQs5gOvlxDjTh21mKx3j3U7e/XKuyk Fyadhhn1TtC+T4LU0siNLgFm1BUTFpYeGYnQIixpJVqSXKSZf+PBHqbaBlsApM2i2NONNYNzY807 4MLbqsILMNoJ73Z4RAH0c4V06q102vel8EV45Y+sKDjzIYHn4rOoCV/Sd3+JT1SOzilAi6WaYRwe QMm2FXw6Bbh8h4scdB9PwsJaNUdvFin3pwDIAx5M2BQgjnzsEm8xBbgiuQrDxSYIIz6AaaH4AD62 0aNpeHoQ5xtCRYhMJt0b2dLD2zl/0KfkDB3MHuIcHhJYyVfJ8f1KC4fWA1j0KaUtnS+hzcf0Z46h d4F4mJiLt4oxNtfDSYwj6oJmWdkNlYU8hyOOUgDo/UqPw1FAKXaR8TTdqGT8VZ+RWBG0FSQtb+Ic 4jKZCJocNpc9iJH9eT3OMrmt+xYzJjn/PDgX806rGQ0lPObDCLuXHa2a5z2qHX5lNA7f8jKN5MQK gBljUFYbp1fX2jBs5tM4HuwplmK059ihNrSIt+WEuJFHdGsOByIFspYXMSnHpMgntRWzdkZdqMBR tLnH+nY03V5hc9/pNHkVgplhMlMg94oDMwdSweRazUUK2q/ir/o1I/hj5hLjQ+/bf4x6UmutxERB VzVfLwdNcVbyREFZz3qbVY5Lmh4Ll3gPQnNC917xmSRUGqV+HsJHDKrAM38MgCpud+eSPeBAvdsN OBLsQ4XOkAnhO+PQz7Z8Ba/7deF4hVm74LUReBPUIT+ZEVDCZp6swZfaUuDxLk6/iA0idnevgz5o qPbla/S9uw5HM4MAx+l6W4PT2qZIcp6A4P/DLPYVgImkn8bZE7RaLH4SROPNZmvYDdWFOrIpxht2 WTzEsBtzK3Wq3LwMI5Y3Vp5pk2rbnT1ZuO/xjicc7p0cWA0HY2WqSNwlpjU1ZFdTrw+FC0ouKsPW ulh2m440RK7RL9QWj6FYAkKHV3Q4m6KaHuhjNBO/aW/m3dgNoJBpdCBk/gFWQf8LtvJErQbz3abD +4/crPoiNt79VuIw8LHvYvsOX5/4J9ektsPG4RrF50pU9h/EDQgHhyXWIf741X+5J3UNtij3suVj HWlnSXul/aWLfbyrpcYBpg3RB9h/8/Vvf/PNf3/5n998/T+pGCeO1XYNmv5TKyPupaSYAlYxymeF NvyP83AztmWL4DyftzNtOVojxIfAJEr6f5SAgfmABpBPIlSzuz7mXaGfF2aAHiCjkVItOO13wt99 icDunLoe/YnTbTq/xgx+DffYTh1GxCzo0Gl5df8ejoU6zyUd3tu31F13Ih0Mmm13Y0DgSAwo1jrd 6T3ygZgyNvFfUwrDZFYckDCHodD6SPhxfdXbhS5cIauvcRYQVSZ1cRxituXBk4AKMwjalh/kmXJz UZw8csplOWF/3Zk3q0oIEi4RkTwHo2aoxHXmIemez2m5BKqGihMfD+6IbQxowV32WKVPiTeESMNB SwKyRxFSM1Il6hmmBeVwfYGYMXq6gazGzhD0JNtDbjPndG5olH2M2CiT0D1dyIYWKO+vBBFoStBZ aRbFbdCNNZO1Kf+czzBuECIkqCX9qtaNag4XiFpsosILkYdEBKzUhkVXfujbJmMFdPvUk3G6ukYf FFnYrfIAkFAzEgobXWwkOWydd82Cth42tccRHX55+8wliXRZZ7yn2k8XqeM6mXWt7K6Biv10Yelr uqj7EJ2qyVX8+N4dLWbcknygdvgTap8vWUD89t8C/9yFeX6SDq+r7nFIJw57HF5CARGO5PskkQKi 79H3OiCZpbCXDNtvUUAUEkJYCV8uCK4ttPAIwzE9WbtOaT7/JFLXyG/3xjzDe0lorSG269d0M7Dp ci+kvW7ErivT39VJFl+lLnBtsU537K/bItGB/xB0NhQfButXX3/9r1+9+Y8IqIfAKqMeAAu75VWO 4ubHKl4OO/7fFrturKaJi/lLkxC7MSw9vCtHG3d5oufFhG+ZkIPqMCwTrDzIsii9YM2IsiahSVR9 +5cYKXQ8Q+ODjxhFJledkWvtEhzLXuimV3kzaejV7fDrcV/NbuHmB9b+Pb6K15rKzmj4asDPsWtt S1RyrSFD1krumi9Ftt2DIeSoqPfwKkUk3rKNlwr72FRLkE9anB80QFr/aojkE2mhmRbHewbMu3bP RTEo3Ig9WpdUSUDxSbiaG4St4LyHv2lspvp3ye0BylzCw49CkWOSdWMkbPHQWls/KZF5QmpkVSpp GIdx4TiFPEdNEL9OA2wADkgzfRDX/PjsNTjdWJv8L1xNofI5PULloJCcipDDNOk/ZY+YmqJv3Yse 8rNzLSrSoAF2NvoUt9RklCY1vk4tlNNfgON1v48pICAkV8CuQ+WAiFxuzWjIzbSRgkb9nCyQgILz nyKbHUCC2M0f01hw5IPbaP9c7ANfjrmg0FYyZdCu55Z5m8KrS+FeN/TkeOxJWb4TjXWUVDeqhTTO 0dq0imFL4Uq7U0np/D8o2QLdC2gFWiUhPkdjkREDRrJWTr31e1ZRNlJJNPoZtyRMSqcdg4uiOQKP bAd6hR790+BFXrSpwHtVgdynyK+p4D/19c16vOQTb5EeyyaY/qA23E46fEVzSJpdf7C7LetlYGL9 EXFuak6tufbspfpTxwkSW41DJ1AzEhWpNUl1H7QEK+moezvdR072DzMmhE2Q2lEq+E6sy/E1HITv /HShTaZzflAFVAg+GA7O57d4oVgnR9WjPAfA0L9hFSa40NT15D90xxvsHDmmm6FDtjZd0+1q/OEW OYK5pYumkv8I5mvZIoOBPGcwO2mmT1hvd1sbVqEd1JkZQRRn9GLuUUnLxQTw1qDTIEvArva1v1xw 9849JcRHrOzbphxzwYRROy+rvpMGX6eXyGv75rp+AM2y8+ra+j1Ou+MlFooqh/fBHlTCRVIO+ds1 P0zXd6mfNby7dibIXANtwosXA9r60Z0RJDwSCByZ+erOqsyhxFuabV9KNMZiwIf4RK2leexncnnz IhItzXjbR8iqUqt8zNt4Wb8S71kIphFWNYkEh1nVU8h0OIyNBduFinRgwYexDguGeEk8fD4YyEH3 bTHmknLsseMH4e4QLVkYBTPPxTBWTNq+BKfvdnhJ6Iy/p/GQ/Bpw0jT8z0QI1we+C+AAZj/HVXxw opB6k8E3L7+SPRwBTBapCLg7RxSE8aKGOAZChgItIXRnWMo8EevUWiiEkJu8L7HT8MpR6Mt6lSL9 CxSGdapPoTCUwV9EvX0Wv71+jU/8mEqvgvJq4oRWVvPH5yCwD5Pom4G8GYQPxWRk706lytL5nTKR O3tiQ1O2a923w9rHiBdQlE3Q8UGZktSvT56EIs6OvxWIaHxI996/Lsou7gt1ebecm8Sfj+Twjljj rJJwpAKrOZOfLsKGmZpZkBZSawYAYDGcs5E83+gclTjJAkLmhyEp5dNvUqRH6LD0DCWfejkRxt1A OpsiCyZPis41sngsJH6NP8MzjHXdOMyzpgLln8xkCliXjSUUElAaj8iheUjoBzNmZXTCPWGFxyMM /phQOBOiAu25UQZ33zSw7fBmVXm1Wkr5dAV6S/nz/wUPEMakCmVuZHN0cmVhbQplbmRvYmoKNSAw IG9iago2MzQyCmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jl c291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KPj4K ZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg L0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjQuMCAxMyAwIFIKL0YxLjEgOSAwIFIgL0YzLjAgMTIg MCBSIC9GMi4xIDExIDAgUiA+PiA+PgplbmRvYmoKMTQgMCBvYmoKPDwgL0xlbmd0aCAxNSAwIFIg L04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBhZRNSBRhGMf/s40EsQbRlwjF0MEkVCYLUgLT9StTtmXVTAlinX13nRxnp5ndLUUihOiYdYwu VkSHiE7hoUOnOkQEmXWJoKNFEAVeIrb/O5O7Y1S+MDO/eZ7/+3y9wwBVj1KOY0U0YMrOu8nemHZ6 dEzb/BpVqEYUXCnDczoSiQGfqZXP9Wv1LRRpWWqUsdb7NnyrdpkQUDQqd2QDPix5PODjki/knTw1 ZyQbE6k02SE3uEPJTvIt8tZsiMdDnBaeAVS1U5MzHJdxIjvILUUjK2M+IOt22rTJ76U97RlT1LDf yDc5C9q48v1A2x5g04uKbcwDHtwDdtdVbPU1wM4RYPFQxfY96c9H2fXKyxxq9sMp0Rhr+lAqfa8D Nt8Afl4vlX7cLpV+3mEO1vHUMgpu0deyMOUlENQb7Gb85Br9i4OefFULsMA5jmwB+q8ANz8C+x8C 2x8DiWpgqBWRy2w3uPLiIucCdOacadfMTuS1Zl0/onXwaIXWZxtNDVrKsjTf5Wmu8IRbFOkmTFkF ztlf23iPCnt4kE/2F7kkvO7frMylU12cJZrY1qe06OomN5DvZ8yePnI9r/cZt2c4YOWAme8bCjhy yrbiPBepidTY4/GTZMZXVCcfk/OQPOcVB2VM334udSJBrqU9OZnrl5pd3Ns+MzHEM5KsWDMTnfHf /MYtJGXefdTcdSz/m2dtkWcYhQUBEzbvNjQk0YsYGuHARQ4ZekwqTFqlX9BqwsPkX5UWEuVdFhW9 WOGeFX/PeRS4W8Y/hVgccw3lCJr+Tv+iL+sL+l3983xtob7imXPPmsara18ZV2aW1ci4QY0yvqwp iG+w2g56LWRpneIV9OSV9Y3h6jL2fG3Zo8kc4mp8NdSlCGVqxDjjya5l90WyxTfh51vL9q/pUft8 9klNJdeyunhmKfp8NlwNa/+zq2DSsqvw5I2QLjxroe5VD6p9aovaCk09prarbWoX346qA+Udw5yV iQus22X1KfZgY5reyklXZovg38Ivhv+lXmEL1zQ0+Q9NuLmMaQnfEdw2cIeU/8NfswMN3gplbmRz dHJlYW0KZW5kb2JqCjE1IDAgb2JqCjc5MgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCAxNCAw IFIgXQplbmRvYmoKMTcgMCBvYmoKPDwgL0xlbmd0aCAxOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4Kc3RyZWFtCngBrVxpl93EEf2uXyHWPEMsa9cTJMDA2CTMOSEThvAhkIkzDCdOgg0zzkl+ fm513yqp9bS0jO0PGkm91HJr6erW+zm9TH9Oi2NatVmOf2XadG3alXl6d5t+kz5PH312X6Q392nu /t/foHWelbW09Y+Guz5Pu6LIijK5+TH99CqtG9eHl6sf00dP6ixPi/Tqh/SQPkiv/pk+vnLzD2O4 MW38ogQt4yHzLC8KP/fVzfoE/717+tP1zb+f3T5/eX3/8unLWzdhnl7dJBuzltUxK4tjxanTNW6S Pdy0Zdr2bda3c0MmTkAQnxfQX9LD5w/Sh0WZHr7EtU8Pb/rLBS7N8PL30qhID+dyzdPDV7gek8PH vtUbuNTu5Xfp1Rdb4i5LyLfvi4DKZEaNYyoLTsypvj3w/l1ef40rqL90t8nhIR+/7x+zV427Y3pg 2/dwBxbnm2Z42aaHtx4kjl924VMOV6KNCIMDve3H45RKMLu8g5ddcmDPCncDIdqUL5Ug1yU9hCxw OPDvCWOfXkgBM6STpOjA7DT/8g2MBOVxtrAp70ISOAw78EKFJAeyRgpCuXGcD4VYyA20x+ClEEAf i6xdNvgxUnIZvUoPpIAsvDXMKdxmYNqp11PCtuSFMv0VuqANifbIOoGL65JgPNc2tIcLPIROvn3g X3LYCUHTqZ0ydgB12t9ZoreK5BCyQPbI0AQcH4BICGaeyPchLlgXX56jqehPgTrhyGyTs5PCT9Gr E4S6odiH76yLEsWZPkIfzEuKOR6F4x4ai+zwOyENSjuTK/wVB6BTY6NQKqTkIegSpvhyREg0RttI j0umOTGJ4p1JInzs4ZuoJPhyjwO6gkQGM6fR6wA0UzoyXh6JDCERvqRh/wZP4bpIwZmTc3J4zLYu LqQSF2KkVvY1wlRRp62KbjUMyKTb0Rz5QVuXCO7L7mJnfoBg2uZF3r3ucSXvCEjdm3fc37z46dYS Dhd3k+XEqehL5DXGxlx2kAbpUxKZPol/Lo9ZflweEg7a5zC/KOFwwHrYWBilWatvp5sgNOO8lDmQ qZdyjmenl3KebcZLmVchaeqllMQ/wnoG9+rDo9m6hg8SqI4pZJY2OuuRk4M5FdL2yrwmmibQGcjA MYZeN31Wl3U14CSZz9zHgVxTu5DTmdB4ku4x0FHaKsCpFPA6hnaXfhRl1q0sOMZkEzPzoFSH+x6i DVIDKoIcqmqjAkMAB0u7JjmtZlqDCGM4Lps666qiT9tYtuM8s/i75thl5XHZNY8lec6golzolaw7 MSUqQ9OuSjGMacSCYoovaQ/uLjloEk1pUQ28Y1NC62uQBv1FQqiskL029TGe+x0C7Yqsj4Fm5JBw 5k3skHDmqiOVegPBDOkBxfwhc6s5BZoRxCowWJCNFZjuUaBLdy2QkM7Qbyi1BIC6kcDwLDdVFokz zZ1Ccay6BpWkJqKTxiaeXT7cC0uVQ+I2s2qLV+M8biWzqNsc7r2qiJzVNMDVHZzgt1O5ui2zvnDV IgH53LiTekYcyJEiNnWbwSBnii6TEYHxSZpBAIRg4V3oM94l7in32Y58OAGbaozjuUbm5IlW+noO zpYGEz6Ooes7n35w8frX4O7a33E0tQFikJMNnjOkZT4E/gEjyhKNZqWW4rom5k/UUeuVI+ttSMCw xqY0GV45xRjFK4XFqjlmVZMjRsViY4y2PKvy/phXPQqXTd4cj2WNv7q6KLq2Sbcqmk1ZrIbFclSw E1HI2lZgyRX76Pa3PqvZqj4WRZ21ddenfuY5Q/CLgSrLd1UfJcY7ZuaG9LY1ZkZALNVHF3vBlIMU ygQdmRRYC3eS2SJFFjgDOx/AsHCnRqOd+Fb7CEikr0MtJCVLV1nQKog4ZkErnTzWXg7FGGU6qgAX pHBOjvWRjAXyJc9DGNQxJAxITUqnEJiir95KNi2Ehfz4ZBvNpjPrqGKwIjsd5hO5B6UqS31egigh RmqmoE27n0lzJDHkQF+r5LXZUZqBdrKkPg0Mx+SSdYXM+dgW8aBw9GlsiNsPgNFmcCk3P0asKhzX EJIKx7EtwofLHTGULG4WwHBqqNjmXNiDGBJZyzLotOiVuITiHR0XVze80yjwGVTgkipXHKT715f0 jHwqOBRuBDOAjrpg45I0vA1IQPWfopWrye1Y7YZcXLr5llZgpIIkOkSBKI5gNGne7ZpZLVVJp4A4 xrCAcgk4BcU2KhKb1slLI0yYi1FeGHak9cVNp6qtsCTqkME7qMWtX+YkNVRNSfM70ARUYCQ7n74i qRhq67LMqgquYA+1FPAEOKH0z8S9wXjEZYBoviSfLR6OK4zuToU/1XkuI8GrzI401KJjuEU2V/d5 FrmoXOXv3KFZdOQT50ljQyy5Ifo2rMgPpdikmONzcHZweB3sbELZvAGQPnoaIp49WdKn/LeUH6OH 8lhldVeW0dqQKr06+uWyZQndNmV/jB4WGfsGqgSmGsdCIw07qs4oshVZWbWOggRny4bCNksbVR4v bDSvZ778ErMgDZraVqhhat8eui6aaXCgx8S9+SSfKEjCIMFEzYEThZELQ8SgQ6y0a7KYSgUUSKxy pnBCqoGOc15OIdbZZiJwrp/cxWK0+qvQ7zEAk38OPkEHe0wKARS7eY55csPZhhi3XSQcXKWAekJZ oOXEUp4pXjT+akpEmk/gbmpeKQVUVYOjGVhEOWXPrQH8skLTowTKno/0ZxEmFErXlEi8mNBVUxpW 6RcpB2V/rJpkgSh2ob4uzT68nfAxBUfiPkYsiS8V1h1OhZRYRC3Kb1KfGK9Bl52oWF/dZzh0E1Xx uABjoFnlNZbMurpsg4CioLw4gOKRL1UtVEcoPe5QUojzEInXhmWVob2sjn4+0a419g7a0EUqyMVG MuCBopyTyd3JwOwGksGfXmDs37j6E2euXnBFqTbS2W4btJ1h0814u19XJ3w5iMHlihSwCXZKoZc7 YYKX5o9WijoC/AortjjcD543ZnXhiPZdEnW9odA1mlAj9EtzW+jpaAvdrdbJvGqL6DIMehxNJRS4 IfcSm388fmJiDUm0x5OZVDcMfUSqhggyRD3yTh0pNURaecemzjcavthR/YJe2UVvv45TdYWyXdse G6/wiCVavOsschTLlkfceZ5A9sHq8ZB79/1v7+5e3F3f3T69f/Hctv+3Kn523tBPPWcQtv2/q+KH HaMKRyS6mPo8ov1jutUnuCJ5/bPcooh1RldzgStCz6TVF67V9MDhN+xDGBHY6mSIItoIDYixGXCO 8R5lU2R5hcMpAYMr6vLBecDDf+5v766/Nx1tHo3EWqetq4LzEXEr85nGeN719vmz2/jpqrLCdMc6 nG7tJGa0yVRdif2V12oywZA7ZPIajuj6qV+vychuwy82mRgQF9hyP+Zll7oNjsgF2JoZWoxnFVEj zHY08lVkyUJoq7RKZ6qJlGDHxUuOR5OlOc+3mcTF8LzizJGRkzJc6CV0EvfUcsf5JJTOR73OhBIL ry7+2WmFnVmiyzQYQSmHS5aodF4+prBIxSJXMbip2x5VRDgHh9RlU9alXArnHm4lhnfYSuS0iXwN sFRgr3scliiwmeznXTY6N28ip/zB5nYdCZlghc2I4+ymL/xo8ujJmJMLH4f2YPuM4YiVCWqEaqMq iBbNo/TKRoYWQnZfkU4qAFOQeIPyILEiVQiSV1oS+Vx8Fex2smMD7H6owOTs4G4oQ5PKuOxFwbo8 1TjU0cL+FD6p5jvLCJyRoUkUSPMa+705QLoGKXyKMoAUJG2DVHKzvMOnG8vjvtL6v8ZJrqZtYcwj elcP28KYz+mO16twrlQYmU/VNU6W9fjmZUzGyQc2E0t8E2QgUTTb4PKJ6lNNAwZRTq3DvnePsySe gjivRtzoVLouCadc3DEUx1PIqbcNVyYfLEHqPCBPWPJizFMXjJsngI4RQYHTaGXX9qQqTgShlXD6 MMrolk74UoMmzXTiMahEvhyW39uFT3a58G5aVTIBhZvNgq76chLItrP+eUbV4l1lJ12yF8o9XEnv X+wn/jsqHmuOPk5Y1XlWNBIhR7BaNeZxhNw+qLKG5FIOka8geXy2Q2oGslsoBgzhicZGt4gKUWjV gyp+5mW04qDK3o/+toYcMyO63j6o4jfo4K3EXrDVLbEVdwpPZ8bYOOVbgadIRCAoVwdQSMofVBkK 9hK+MYqCUpMGPtZeesiEg/Otb5wcZHd2dAhETG10QOXkkAcIchs/3vVKCQl0SYwtisTY4Zjn7vFA vnKp7CmB+lxPmOgWnL53rgJiEPuE7MiHcmtCijxzXmHZk3dY9kRr+RVOnsCP4guWZVC+Qkbp6qX0 bmeUrIjiZL+dbeiLVEx6dW5tdPQ/zJ0UkBxj1StzJLrLSyGJ0JArH5NCDrSRUo5ZdOAZjTchxQKf o+I0pRxXl+nXrYvaC5ncrLLbtyDsoFX2M2qBAzAfYSPSRTGoXLkyDl8ydpND9p/wy3H40s+8vqkS E3Y4CSTj49fW3DGOGWlN2UZ/lamhfSNyOnVGlsmdAwuRFtSwT9btW1yLi3O+CM7HQORifKL1Cnsc zDS4ZrcKsfqI2iKZpiHxLrpabsOxo2JMd5on0EO1fMd+o5QAG1RwY1U5ziSW1/CCjQonplY841Aj jf5GPxhybwEwugZb4FulPG/qkIMd0z29ubm9v79++eJft8/Hs65WPaw675lcXio4ubmqR5zcRLdF n6HIO7Pze1r2eEz3/gRXpBy/pDpPP6kLgNCzqdtfWFu6M3GMKTRbDmcWOL8MlDOxfredKed3yfYv EmAln9V1U61Lyq/m7TPGCz9T6M0ZgkLKJzJVV6iLic9F5NgB0XBD0etPLnzB13yst1NnFixMQqJ4 p4oYaIxx83XZ4/gVyoAeRRGpTpyLkIPB+BpVZR4xbnRFwoFnF2rQOEoW+F65kO2ZaFmAZhU7vXeY h3Hirb072TEsUXLCNwXzVqyVJtQQ5EQN55okQLRAyfWR+mtwIhyYqrCng8ywcEbK7ZK+yYBmi5Pn E8CF1XjrxBk1nJE6PqX6rLHGZe5Dk0xtxS1uDqGxmW9VATaWr4bKssv9CERorNYqJMSlAdNsFz0N NmtnouqC7iVWhfIB/XaxsEI1DWeF4OAXx32lYiGid3GER5xd5k93OOOiEPAbDDmE0yTqF3bGMfX6 9n8/Pbu7vb9+9nwcXtPLNRWgrnqscvzqzSJj4Vbqjm/fi7Zd2MnzQ2INaEHjczrzL3FFeGVMYyjR l+r5NUZ+5Q3WhTY7OrEaXYlWmrbaDs2D1sklyiQNVYtSi9e+fH5i2Y4NGqXSuxDT3RI2NLbZmH5S xOfc5Gbia8Y2uLKrVOHsad+Wfeq1FRduKDDyY55BKfCey1ZnYerxN69h6xS6E45MV0xv1svqDMmL eubQ54Qrnad++L/7y01wgbxish75sL1o8oUfijrFLjkg6Upk+JTqZRsVFFETntg1yWgrdqK2V7y2 qw7hWKX53hW9lw30XjXrjI43HOKyF3GRJWr6c+H41T3kaMS9DvLu9ge4xH+crjpWf/msRAQ5Fn3l mVk2ir2LNUFWgYLsypmpcWVMHd+GV/TVZPUyY69oS+RVr/gYVuJLVq7MoK5tFsEKP6Jx1lFJOuBG UgSHHuATm845SXoR2rrmIGODMd++5GWHbGMF8ZWsX7G7Fa8BOWwVkW20jayL4UF3aJY2vSFqK0rF WHTVN1lXIBP2dCxboCFMwuw2f3WOs14ddunG467uqiDRNic2vxolehzCLKxdEhcKAca1WRhygBNA ONjxpa4nw6A/74LRJUbGst7ou6w94qcal72CCRiCCIurxHrIEn9zLYxjZJ4MkiM+pG3woRoZRW7V Pb5WabITzUyLo2EoZRcTkccfaZhVB/uHnxCa8pU05kEn2mKS5PZQKJptZZk3IEeka7JcCqWp7Kow TKzuQ8hZWWv+R4GFHOp449A8fINGwiY2rnOTQ8paPYDJjDaB1zGArBv3RWNjqIwxexhGhNnjdFPR t91k5C3D39affYU2jwrK2zQUJQaxy6NswEbbpa6FQ5OaRDdapumGOiOJZJXanjbSPJCNmeOxcaR2 yxxfDjaogSlvXrtbOpj1MhP78KZpzoJimOVsFamWYcwe7gqLOoB2DKbxTSN+Vw5rUuU6wtMe/hSD aSx0kdXja+UdI8OHrzoaSkc/BQxtH4lPDMdycOHYNoOeYzjGxGrFl/8HCaTpxwplbmRzdHJlYW0K ZW5kb2JqCjE4IDAgb2JqCjQ2NTAKZW5kb2JqCjE2IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJl bnQgMyAwIFIgL1Jlc291cmNlcyAxOSAwIFIgL0NvbnRlbnRzIDE3IDAgUiAvTWVkaWFCb3gKWzAg MCA2MTIgNzkyXSA+PgplbmRvYmoKMTkgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjQuMCAxMyAwIFIKL0YxLjEg OSAwIFIgL0YzLjAgMTIgMCBSIC9GMi4xIDExIDAgUiA+PiA+PgplbmRvYmoKMjEgMCBvYmoKPDwg L0xlbmd0aCAyMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1Vxrkx03Ef0+ v2ICJFznMZn3nSEUKezdBGIgmKyhAjbGbDaFAZvE6yr4+RxJp3tGuvPou+WiCvuDPHekVnfr9EMt jb/PH+Xf59WQN31R4k+dd8c+P9Zl/vom/0P+Kv/4wW2VX9/mpf97e43eZVG3rm/4aXqqaowsx6Jt s+uX+f2rvO38IDZXL/OPP6uKKq/yq2/zP+WHi3v5R1WZHz5J2h/hucsPBZo+O/DpyYG9KrYfoh3z w/to0PkdNG1+eC9++WM89vnBd80Oo3uJvh+gxUhPX5/Y9V28O+aHx2gC1af51Rf55ZVX0ySqF13V UDdV0XftYJfe8Xv19z26TqH92BblYFCokWRf20nO1ki03kExg6qba/DJvSxayPkC5ucuYCBFyvMF zM9ZwJ+AzzYTWJAaF5dYEdgRDk/uYQjAQuZFYL4VETn2Y/R10I3VQUT9kC85lEMu+OtHVFbSWfFN kcnGfYwCHikAx/AdhgRlCa+c6WcYA3xzetJr8SMWLv7xU/xImGf7MG/7uhgruIiAyXzLyDNv5DZM toPAfIlkFvuNOcmyaMpxKJsRLqkru2GoW/zr2FbVse/yTV81lnnfD8WwYVn1zFU5zVZVfvgBWriZ 00fnJrIdN1FVbdG3x5EzLwmbe2GboqT+crOb8MIskQz6mwvj8QlhHIwAeGcVaMR1Orw4UT0gAT1v F5D5Uwe2eurnTADDPkIDsMnoGo+A2ZFEkp+F1vuk1YfebJLOJCVjLh1JzO9swPHn7QntezQC8G3y 1cehODYASlh+g8a8BsRZG8Kgg1bXFAij1y+znSg4R/N6YHUU66FoakMYgM92IMWSiBuit4id30xr bhXV+yRekNE19mQpwcyZROJNORu7PgjrLH6K5GQI3RamziJe6Ln42gHNuVxSXmRJJngHlMATvabg SloKRd6awNuah3WTZgchHCsxceExCbIdT9aCsckLs4vwRXnJl2QrpBq/9FSzJPzoIgq3pJ+wGWvO i59JGsW52UXogIDFtNqmLrq+OQurZJFCyoQpMiTQiabIH3US6z0Wb0EnmUUWZ3IVwp0z4vVUNnhp mJzkA5xcTI+cEQNiW5RZWQu/a7KyuVzLVhBbSuk8YnPiAMhFrB/DZFlicvFkRExsGLJO7Mop3wVf CCh8krUmB1TKH2GN8EfbePBDMnVwiU5IKbZrmY0vo/VSzVOIGE+xgLKGsaFMePV+p3SuCgvATomO yQInE6goGqiz4p4Jp23bIeFpjttozWYbr8PvLDlF245FVUGIdStIEjNYQerr5hnnpCKfQVEnlDo7 /DR44QQbT57YPE9XVsXYVgjq3mYZJkvsaDu/US3zq+vN3ejhU6wKYrzvuJPGwTV047Foels0/tqB AXmLLrCgg7L6xDwTq+Dq++2LbrMIFaUgoYEUCCjVpWCUvyfw4yDSjEkQ+WK+kiSwL+nJ7Owcb4FE uMSAgWZn1jFHKg9/TiyCJGIf4rtmBxp3/E4gRpnE5Ck/jZFUCVW6JDIgzG/a7bI6yVesVbJ3svWy BKC2HhF9msaONVsu6YJ027k6jxXDLpmX9Hc9R4UPKsZ6ONrpwmFQ7wJYBQQVR6VyPYfgIriAgkLB 6lZ0U8sAQYvunYUPtS3yy/xkkpyvSSRcU3Avi8ZXWpLglhiXACGU0zqYKk0KC7G1Cqa1G+nA4VpU UVd90YzYs0IhNn9H0WReYT8ySo24G8YUtpanGf8cGy7EZq6CEcssGlSZOc1c6/mBZkk8eZvXPJg/ SpoQgwtVE4vqmq5DABoHo+ps5uug2fVIs22L8RA2A/UIHGMF4MnJsVu2KAGBI7bcYWKDWRwuLR6j QqxuXOqyTvc0xSCMRCCCgb8SBQI5yuerrNm656pa1Fu6Ep7WK3ZTPl+7ztwOe98jVu1QtFXZb9A9 lU8hu5wQcQEZoOaoz7QEkzoK4pxjkiApj/OEI5PSuCgysl312nGUJGfi4GhAHcxzKheLOZEeh4gH 5RAKxYZdA5up21BlkdKqN7GZK3K6oYG5nmFfFy65Q1FCtiAJB2QwO3BNqLKdom4gKU6MsqGoazHW tsY5zogivwHMunulksnkSboyy9y4RsKboIf1FtHC0topbKiidO0ehOj+AQAznc1AdsvSOafYliub 9VMboxBUbOxCRDKqRKKYf8y0yGXkq2qQw1UDgqeVO1fVtHiWvqgH5zlndLOd0zamE2woX2xsFGs3 IBxRTe7KLbFCHRuHfaxj2xzm8Vh0iAqRWPG27XQxFUfLDnN2wmE5yCvbYqhxHBEUa4uxl/QBVOla aPK1D/GodASCNoKfiEyMjL+Kq2mCS91ZR1f+ZB14U0PqUskRAcE5E3dGCfmSXcntCLZmh6uxKDHV RHh2/Y1TI/aINDWJFXwr0kuwkJavv8RguI009GEt/L6TM8Zp3DzkaQZJEaldys/hUOTJeZvVPdVd sVhKPAX0r4IjdKcfLrKQZ7JA9gQ35M8rIXNZlx/CTmtA9AeKAkT2jRfognLaXMYe1Kbq+a+DaFwz lPos2qvhRFsc1uSd06HNJJ9iIsCBxv9nfTLNh/Bf4RpDNJ8rJY3GUtI3rmplrCXVPfYIA+zGKpyT aT9A1P2xGLqhtZPFmhjIHnHi2nZw0PaloBNK8EYITCD3u7h9kE93AOh2Yq/vYexdmmWlG1fjLOFz vDhLef+pdS775q+d5aHGR2HZ0Cn543j1s3G68cgNnOWPsTnOzVvvq6gXog7ZaVnBFwn9pLPSIldc gPsYtXHpILAsPghsUNmZu0q0dkfG5WiVe7mkZ00XeDcoO9jvMFyBWQS72INNrtCnkyZXSH1y8U6j pqc0k9rN+nOnXxxCy3xf4Xna7yT5MLVb0bvGQZ9g+dwRBJIoP5mZspiZsw0rrpVjsn93fDGxUMFF VGKGyFchAgpitSu8QpwkmsmZLIJOwNDGRn+WnFtnCsRidUn8J1eUmk+yCeX85Mo/6VaMjD9W9G7e 8GqHCjWQDn56huHNjNtczmkHFGTXwxpufwWjOJjvgswpInBVlQ9cK0cgE/1/v37+3bPrf764efXm 2Ytv5iFs07DrypU5utzPum7cMk9mlANb2BZ3Wnb8hW5hxQA/g/0g8v+eZiT2+RDPqIMlvb5gL29e 6qFpc8sOdYpYniAxSqBNFjM/7eDcslc+6esPPElIbGROVyELOzKFtRI5xRFRel1/SVyzY7VtC1xz XDgSDxRlkXPjIuN+YzsnOaE1Wz6wmyaYo/X25vr1zZs5YjeNucaUQzU2nPvt2Z7DbIMUyVgpT9C4 iNkpqyeyI8xqUcWAWa1tz7GV680WOkn66jj8ch+goeUOJZp6rIsSh8pU0DqE9IKwHZSoT3cbm6sJ M3YPOid5Lihf33z7+ub2b8/e/OsfN6/uAEo/91sFZQPlb4QYVTlO5P4XmJw5sWwtXawbFOXbAffS He9LcDnNGYV3eljxpQpbHxnehc9HbivenXiPk7616wjsrFlOSIGYdMQGJEnMh0j2EI84KwnEHNG6 yDWtMy7CJuVv9pFwA6ozla5m4M2ISxKoDQeVrgNM4WCzQHdJvel7VF8NJIGwCxd0seWReCgthfJq /P+69W+W/gyFdviiwKBPI0UEpsZIcbZCgq/4hgfhLhfil5ZPbz5pTi+kOJgpP81BrpnwpTmX13of rcsX9DSNI7XY8oTbxEUkBsW3IiLZlIpkrI7EGXAohwjW5Wg+6azqochk435wURSAY/gOQ05qkG5P GAds0oudCH+c9pJPz7nz7/Gz6YdZ6ofo+5UkVAManFSh9rKQS8Kzzy+sAZFJekNdTEtrcX/YBuHi S1NxYoNxYWLZZlJ3umASWzwnmlnFi39JR3fGlkTrHsRPgpeY/s5WJMCEFEjvIVjCNiixAjHOBGn6 PYyvzXFuKoL0CFEhIHT5dolBLVfImJjBGMZp3ukDuA7wVy0JBaFm0RtFoEBhJXWPxV8JrSRLiEc+ 4vpKlUeH+pMesglrs4Cz7XD4jNuW60aRbNmATco62YZpIpRwx2Zsz7ICkXAyOOdyKKHoiCe34MrC h3MAMMjFveSp/ceKF+OLf11bMr8V59qsLpnPCRVZvqAoYFabp4CxEgR42ismksCTgH4fPhxmKGqV mcCkRXV10+FARNX3dj4xqd31PRQMAlmDc5xnHpvfYWV732HVqK2hWrEcCPDJ6PTpUojtrt7qQA8I OhOYPcLTWhSo32GFmdeFxRbk3NrbHslJmNzfeXaZsC9XQqilr6Gyg/OiKCmzcUkIDklliMMXHr1F QB8ur3LVYwslGXPJMQ64TpcXbOehz/0u/c/9DsyyIvWIfWDZVblZfXf4KKvGJsW4C34IHZxem6Pl i9kaDuLFU8kQ5r3xybP3GNPXDHRV9O5+NWYHRHQv4nTV7dAXen+THXYyyLABE9fFmeLQS3rx90r8 kQNi90vGRFK+lDm86jL3WbUNDn0xlLiG4ZdsyTMk0XDujDaPoOoG33yuE7xDqWhO8YxK0S+urn6b 1/iE/ktgzXhYXI1D0Vf4Vt/Pue62zpQCobhGLr5VtbwDRVzurCw7WCQyUivx4D3JK4g2fkEgwF+2 EsbXuKJCs2XjyfkbnK4uo/YTnyMLbDk3GUt+3bTb2Dg4t7hUnVUo0jxioWS/qb0lT+AGdNrInXko aOJGL+JQB3vcsBtVrzyLhFw+bhgShc6X5mT9Y6UEj5pNC0eXykbnTTAlbDyAYw/ns/RDm0dbsIxq XCsun9YfZXkpJCHAp40zybSO8Tikh9CoxVlW7bGomuNxg9W7essKB3DLX0De+bgnInmGv/THPc+v r29ub88trMPl44yyycPUb81tViiqVR1OktYpaiUVTu7SpVUI5MhRVw8o38Zhz4WfR7+Q2nWFWlxR 00ldYSgkTN7GAsoaHxeN3dAFDa0HXNWQOYJX+L9WysUDgbtjck7yjpg0B3GkuYBjPeZBEIJnmnX3 mN4fKz27+c93L3DK9OzFK51579qu3283Jf7/nbm8C7eGEe1Zy7MdmDlDwGdCOKxZ2MMlvgeW8LlD KDYpXwZLYP0CaZBLueXlL10n2Y3AbL7C85DJjT4Gm6n0Mb/3yJeMCAw1kokzmjAc8WXim0lADULG 8vckBZ/qHi4MB/PL5QPFs81v5+iJDEs4I0eMn5RtCsFxpVjSB/aeDNrx/ZewGCozgxcnoIznfIEX 73GeB/J/dU12uA5PbDCHxaV4f4vvfGsjzCgBlSKxOf41VlzQqn79wpdUgWpGdE/CfC15qXYLGyGt K07atshad7hTU1dwEjOBzdeNHv0XCffBHQplbmRzdHJlYW0KZW5kb2JqCjIyIDAgb2JqCjM5NjkK ZW5kb2JqCjIwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAy MyAwIFIgL0NvbnRlbnRzIDIxIDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRvYmoK MjMgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3 IDAgUiA+PiAvRm9udCA8PCAvRjQuMCAxMyAwIFIKL0YxLjEgOSAwIFIgL0YzLjAgMTIgMCBSIC9G Mi4xIDExIDAgUiA+PiA+PgplbmRvYmoKMjUgMCBvYmoKPDwgL0xlbmd0aCAyNiAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvVhdb91EEH33r5jy0Tq02eza668WgZK2UMEDDbrV FaI8VCGIIiVVm/DCr+fM+qzta66vN1CRPGxs78zOx5kzs3kv5/JeXCtlbSx+CqmaWprCyodL2cq1 nDy9cXJxIzb83lxgtzWF1739q/HJFZC0nfE+u7iSs434Kghx2VzJyTfOOHGy+U1+lvzZkRw7K/mT 2foZnivJDZY6y/n0Oucux/UR1k7yL7Bg8z0sXvL7ux8f4LGWPGzN8k4/Yu9DrJAM+ocnbv0c3xrJ X2Hptf4im+/k+SaEaXQ1uD6EoSidqSvfpnuv9m7+WNPbWak7b2ybEM80jZqij62yLtJVTrIe81gh 1O2QQGb1yVG2A40pJOSukOhVUfMUEnIXSDyGnT6LQKM2woXoi0AmwF4fQQTwo/HRYX6NLlL2BHu1 GHbDQYx+yo8Upcgzvj1msGabh4qhyzTjDFJAOB2gDL9BpA9WtJUnfQUZVAyPpz6Pl0jc7suv8ZKF k60Xjq8L0zmQTo9JOUQbWaCNKcytKW3X2rIDI1W2atvC46/GO9fUlRykKq2sujXtgcoqJkylYXBO 8k+wgmVmj98eibJEtsISznlT+6bjycvOlsbSWUlhiVDTwZl9KrNAu1NnWnWmlFzTqE4VWJHHwI54 rPtHLpFQw6Ys7lWwAthRRNGDx4B3hEcp2RVpmqLMc8ooHtWogG2s8fxobNyvONMz7hOwtOgYrwHU KEXXmj5Ba3Rb2tLULaCTDI3gcuTxhA6psKtK09QJhA6qVLjBm/+z+lPanau98Z1r6Ms+1MnmKttt 9v+aUe4hwwDVC004QHaqK4BBSmKIyFN7KSlyW2Dj7C4EG0AJTibFRT4n/z2EYcgOW0BMEi2hXQMH fwmzR7KMwRjYMrj4PfaAO+Mx1DRjddqy7PA4Me22n7K3YIn3EVV4Gg0L6rPBFAoxkhy56Hjoi0P/ XrI2SwGWlkfZGr+AqH587KlxMkhozavts6OH0DNdNP4Mu2P7y6JMhMh8xmSUk9pfphRIgSSwDjAK Rc5o9syFyM9NibMFT7DqNEicls98xybGO9PxfnFubSrTFFrIq1EXl2Fon3bfZbWaxtDrFvIIZsBQ 218D8vQWN1VpjXUu3EGyzcW+e8Z4wIvN5qV46/qDrGD/WqNuK+Nth7CEI8nV45GqYs/VZjzy1fWb P29/f/fh7V+Xv4YOzlMPJwOsWhc6n08dXTonZCMpdpoNi/5ff7RsQCOGrX3q+mFjescjc0RemaF4 Btspt2X5TwpxtHhSKZcf8BasyzKIrEtJnhZP4dsHIGrUJu50KSTk2sbY0uMinORjcklUyC8G1D0j bh+1ET5JadWpb0fliM/Vkthut1NYHrzbOl8ZzNgIR7B/eXAZ7Qchx5lomSRcVaDIfLmrd3RitchO UWKX17dvL97cXj6W7Y+nL3uf1PuVAi8aZ4qinAVwf6ndZRLXwqgcxrt9We5HojFKSVlWjWVj9ir8 Z7GxRGZFwVLRWVjbJLs3G0cokWzo+yxIiiS1MdbcU6jHgPOoH4qoPZY99e12vHMaFPs3q5WNMFgy v27HrTPeGJrlf2/1cfiipkFz/N8Rp9GZATSdbp6qYxhR6cnAQkn0U1aVsco+mvblahs4NscMuV5t ZdWY1oHQktXCl3W1Ck+nvSXF0InG878BSwHIsAplbmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjEy NTcKZW5kb2JqCjI0IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNl cyAyNyAwIFIgL0NvbnRlbnRzIDI1IDAgUiAvTWVkaWFCb3gKWzAgMCA2MTIgNzkyXSA+PgplbmRv YmoKMjcgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz MSA3IDAgUiA+PiAvRm9udCA8PCAvRjQuMCAxMyAwIFIKL0YxLjEgOSAwIFIgL0YzLjAgMTIgMCBS IC9GMi4xIDExIDAgUiA+PiA+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlh Qm94IFswIDAgNjEyIDc5Ml0gL0NvdW50IDQgL0tpZHMgWyAyIDAgUiAxNiAwIFIgMjAgMCBSCjI0 IDAgUiBdID4+CmVuZG9iagoyOCAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIg Pj4KZW5kb2JqCjI5IDAgb2JqCjw8IC9MZW5ndGggMzAgMCBSIC9MZW5ndGgxIDI0MDMyIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZV8CXxU1b3/Oefe2Wcyd/Yts9yZZLJM9o3ABHJD ElCQHSQBImGTRShEwL2CWgVBhbpVRCutS+sGIQENoEItblWLrdStvkJ9aK2K0v7RajEz/++5M8EE n32fl8nZz93O+e2/372EEkLMZD0RiLJgxbxV9FW2FD2v8bTgsjWRx3IWOQmh9xCiu+XiVYtXND8/ /VNCDHmEaJYvXn7lxfvePP4YITlbCRl935JF8xb++5YVOwmZUoLj65agw7iTPYL2QrTzlqxYc8WB pAvVKRuR3bd85YJ50Z/VagmZivORySvmXbFKHKYrR3sN2pEfzVuxaP2LLX9D+060C1atXL2GHRb/ jfYzaK9ademiVc/s2BImZBquZ9yNPoof/zMTLTmEMkJmZ3t477l/TO0QiEg0qOE+zv7pztZ4RT+k ZVBbxmyfCdcixIKUQ6zIpWz/QGFDxU4cxElcxE08aHmJD7mfBJDnkiAJoQzjTmUSRS1G8kg+iYt4 avF2EkAZEubzOelj2fRB6lqMYTzVn06zt3HM9GxCodamk7vQhx+dkCnJQnKUrCA/JT9DXzX9PXmU KLjb6egVsGRtpIHcQS4nfyIz0v9Ar0weJF+QEjKcLEmniI2sIyn6Y/IgZYThqHryJllEtrIGISF+ itUtphXC4/R6UoqzTCd34xmP4IzFaSPavSzIGnDUdPKqMFdfkq5I/5MeEl9Jzye/pA3sLXEnIO0k jYokdUN6c3p7+j6s4mkh2P/bdGV6BY6aQTrJWnIN7mA9+Tl5nbazkexg+mbcUxvuYR15mrxKEyIR O7HGUzH7J+Qeso88R46Qd8iHlFIrLaTr6Zv0qIb0H04dTp+fnp9eSVrJRDKZrMdokObTJjZLmCU8 Kbzd/9+p4+kQzj2dXEauIFeTLWQreZy8Td4lf6YCM7LpbIbwJPZtJJlF5mM178A9PUpeIceontbQ EVShN9En2GWi0H8Y+CRix4eT83C2hZi7HWv6MNlFDpM3yB9wzn9gTQXqowk6g86hP6Y30tvonfRh +gTdST9lGvaOIAjXiS+Kn6beShvT96YfxXUDgJcIKcLO1JMLsJ+vk0/wfMW0hDbSP7IEKxGoaO5P parTY9Pr0i+k3wY0FWDuSNKCZ55AZuKuryQ3kAPkRRz7Ovk9+Yj8C6skUCO1Yy0iNEan0ml0Le7i SfoF7Wdu7F89W8562FEhIbwuzhR39u9JuVI9qS9S6fTj6e70b9Ovqftbh+s0Ywc6yCqyWt2xvbjO C+QE+Tv5EtfQ0jDu9Tw6Hs97D85/jH4LcNKza9kTLC2MFLYKr4g+8Z7UxNSK1D2p3nRNegJgSwBm +kgNfiMATTNIO859PVbzQfIYdqYX0PMW+Zx6aYhW0PPphbSNdtIldCVdRbvo1fQarOqjdA89QN+i f6afM5FpmQvrlGAL2PXsDraHHWZvsRMCEaYJbUKXcLVwh7BHeEP4WJTEErFCnCB2ileKV2mIRtC6 9a996/l2Rf/8/nv7f5sqS7WkLkltTv0m9Vbqg7QpfTD9IehHBe6xnSzGPf4YsHkTuY08APh4DPf4 V/I38in2/J9YC4EaqB93HFb3rRn3PQF3PpO204vxW0KXYf3X08dpD32GHqK/oa/QV+kf6fv0C0Zx 92X4JYEFM9jFeIZ72eOsm72L35fsGyEulAhVQrUwSujE02wQNuJ5fia8L3woMtElVorTxHXiSxpB s1Bzt2a75rDmZc0nWkk7GxCa+WXoh5oLr7HfiKOE5WQHmcwE4RP2R9ZAf8zO0F+xIP0NrhYUJguT WTNLEkYPAMpXEKduu1bWysxJJF0nPwnbxkqFmWJcMJM1wDfCZrGbWCd5hD5DzrDzAGmXCa+zHWyu sF28XRxF3ybrcE3CLPQr0kSa6Cjs3ZukCztUKuwSf8/PqNEL32pWMEt6g/g3DRP+CDo4kjLhd3QW PUknMzdWK8luIzG0JXoS5fnAwHcB+fvoTFIvHhduYePYn9G3nNxBf4NnPECWswP0l9iXeuDjpXQy vU+oJNfSLqzIcLKM3UmibBWLAp5nkP9Hr6cuYO4Z7E0eu5iIgoUtIEdZO3b9DWpnZfRawOkKsplu IiW0nx4ir7Gfkjq6SHjuW19/IaPfnqS7hfPIbnpGfEV8hYk402+wmhWgHgog5EHQiBnATFmIA2rq iYaVAP47QAEvIDb2Jb2GLSdL6T3C3+nDrIlMIouE1WwMvTv1pdgkVGPF9oOaNGuH64mmQRMUa7Dj fyOjAI2LwdqWiMc01/O68KZwOt2ellNzNTmp98lVWJ3zQN02A5fOI+9RN72IThHTbLyYTl9IHme7 xPfTHmqmMvlDGhiW2ksbaF46QrvSJjoFEH6R9tH+beJm8UZxrXgN+NMZUM2byO3kXvI8uMlD4FsF WMcLsJpzQHuWgkdUkCpSi6cbRUaDKp2PscnkQtDTTlDJi8mPSBco7/3kCbIbHGo81uMiHHcxWYb+ 1eBQV5Nrgf8byC2gAXeTR8gf2GPsAUFmG9kL7DJILu+R94SXBIVeSI6KN4vryDRw0ynUgSsPwy6F cdwt6TdxtSISAPWvAZYC8tOfpt9K/7r/CM73CO79du1o8qm2mRSSSfQr0U81StN0pXHUyIbkiOH1 w2prqqsqK8rLSksSxUWFBfH8vFhUjoRDwdyA3+f1uF1Oh90mWXMsZpPRoNdpNaLAKClpjY3pjHTH O7vFeOy880p5OzYPHfMGdXR2R9A1Zuic7gg/bh6GhsxUMPPic2YqmZnK2ZlUijSQhtKSSGss0v16 SyzSR2dNaUP91pZYe6T7pFqfoNa3qnUL6rKMAyKt3iUtkW7aGWntHnPZkk2tnS2lJXS3ydgca15k LC0hu40mVE2odXtiq3ZTzyiqVpindcRuRvQWPGK3P9bS2u2L4VCcRshvnbewe/KUttaWgCy3l5Z0 0+YFsfndJDa625pQp5Bm9TLd2uZunXqZyNJuPA3ZHNldcmjTLX0Smd+ZMC+MLZw3p61bmIdztHbb ErhuS7fnqhPe75o4ub25bcPg0YCwqdW7NMInb9q0IdK9Y0rboGMDMj9DezvOgWNZ/pjOTWNw6Vuw U+OnRXA1dmN7Wze9EZeM8CfhT5V5vkWxVt7TuSzSbYiNji3ZtKwTW+Pf1E2mXin3+P3KvvRx4m+N bJreFpO7GwOx9nktubudZNPUK3t9SsQ3dKS0ZLdkyyzs7hxrtmK2DK4swqJnxtSaOp3Xxk89u7KU 31Hs/G4FELUggjtpi+GZ6nm2qJ5sWlCPDcBfO8VR3QuxI0u7Dc2dm6QRvB+PSLs1+VIssulLAgiI nfxsaM+8bI82X/qS8EEOJ2dBrZvOG6h3JxLdxcUcRHTN2FPc4yi1XVtaclkfWxpbJUVQYPnIZKzt vPYR5Vh+WeYbvLlPIfPR6F4/pS3TjpD5gR6ilCfau1knHzk0MOKawUfWD4ycPbwzBkjeAyGCEFe3 Pn723yq5Ha1LRnRT938YXpQZHz8tNn7KrLZI66bOLNSOnz6klRnnC4p1w1i21u1obhMCDH28xgKC OgqgnDPr7BQ02szdYj7+tSpQL+zT6QGVag+NjOmWOs/L5O1GWc7izP92UF/6FD9KLb47LPsY3SMS 2RvN3HZ3ckh7yO2ZNwnjp4PksPHTZ23aZBwyNgbEbNOmMbHImE2dm+b1pdfPj0Wk2KZ9EEDim1a1 ggxldrQvvX9zoHvMLe14lCV0BOCWkdG7Y3TjlN0K3ThtVts+aEuRjdPbeiDaNHeObm8vhSwJfiUu hkImEB0Zs1ur66PmPSChGpFXBGLUalB5ShCY36DjfU9R4tNPutqbmCidbpjQ3zBR+qphgtTfQBob +ht4qqyotsm2fNkmLxbJtxHh0LeKhpwhEfEQQIOS/UwnOtg6XM+vmMkhRvwa5hMXPM5PeEL6iJRP OFlZQV1yrej49lds3RVX4B4/TH8gfKzhsmk5fbLXzoyx/el/EiF9uqdUX9RkQL0wfZoUpP9F3Eiu 9L+eys0x5Ohz2P7010RK/7MnmFPKjyhO/1OJFWlyc8I5UfsKfSjXTspogcYSjeXII+0lIzV2jcbi H0n62GtPVeaNzPFV/GI/1RIvLbmRP+6Ek9JXJ0ljo3RSOmkfPtxmH27j2fDKiuYrlVmsTIp7fR6f 2+fyOX0abW4gGAgFwgFRWxAvjBfFi+Oi1mQ2mg1mvVln1miFeNSWp5CIw6/QhDZfIaViuUJjVlmh AR+yuLlEIWUMWQJ/lGeJYvwlriP12T86UFFLALjisoUcvkZnyOZptPHMHQrZG6N96TOKgkqBM9eG LCAh81mReXIaYzwrcLotqCETnJgnhOymxlIjMjevBZ0+mZ/kM8WDitXpCfOjwo3MKNlGeXiWuTv1 Fs9m/LbbqUvSaWPReEEc/7W10rC66iq3x41/XQ16CuKxKHO5nGh73NVV9lrh4+sW3TvuhrJgq9WD 2vjry0Itknt6c7GvcPjYW3c0J7yFw8+7ZQf78xupf/z8mmStfPvIC1e/QSVej97ecOG6y18fGfPF UscP7bv89yOjvjwqc7AD3J0AiH8sfg2tbnePXR/oS3+tWG1aojcElMBk++SAaLDuZ48SM92uGCSz 2So9Z9Az3qNBj51qNIw+p8+KHDp7wLkftgAbW/w00Rj0Zh9zHmDXQZf1sN8rRrLYZqOLiUSlZ9kq KJG/gAlAhSHpq46TDVL/Sek0wKih8eRJarN7hhOpf6R9eLmXSl+ePjykUVlBOvjWUptcBVFHG5Oj 8dqaumrZpuGLWlszrG4Y20ojIb8/1L+c5zSS+txpsPqMep/49Zk5Hofd67U7PGLFhVqfzWrRc2sK hS5HhLeBTwka2a1lzdPbng6YEhoRpqc+Onuv0ewcGdWQxpON/fz2KisC+4BXf1FKAnk151mvyrmp 4KbCm4oeKXyk6IB5T7HBYje6a831xWJRrDiUcBaECmNmp4lDi+UT+0n3v+39brFQP7CW7z+dXUrN s/QEMRATtRBKZ+8xGIxmfx/9Zo967QN0NjFB1Zm9R/9X28j8JgtbCWHWg94Q5pvYCoj8Px3ATOmr 0xwxkWFVT55sxAqfkE7S7KoSvqoqhuaG8+xed34k7pK9CnHEbAr1hJ0Ktechy2LYdddlVhyLTrpo V6J9mMwXHKsPipQ3bBSrrQHIanX4qRtQp445tVod0fWzG71Y72+PUvLPrunhnVf/6DGf1mCWbJ6l ++bd/0F89mWpd/ZPl/k2rb3mo89XLplUuPyRazu8OqNHqnjoovc2jZi3ek3q/V9weGXQYrFH4t9g sYI2oFhALyMsJGuC4Vy3r49+9FQw+Jzb6rL30U7FnpPznCsiy4uZ4GRMYHIYoufspwVB1MghSwj1 Hhh6+hjoYDCXL62bWNHndgl97AbFSjU5i4PBMLGGKJY3tJ/9iMh0tmLCvlBfVBRdZlDBPwKC825M gPpRUMKuCf1fdXQ1NGCpG6QTRGo4ySufN0gAb3TybttwzYayxI+lw17CN+PLow0DpbWyoovKtbTa xtcVUB0bqGTBu9pmi1FB6H+TvrlrTNjvD49R89TLvH5/SWomnTtPKPj2NQ7dqS8HYJzOZcf6Zb52 9HXwCyrMh50wQCoVg7XHbdL3EK39AHWDh4jUvddk8vlyV+yjIZJlZJymc5DnzGfgtlRkcwxpsRl5 9ZOnDBuaCfMnD0tO5Kl/y6T6ERN5UvcQ1kjxIOyKxWAzTymJOttw+/DAqJJhpWPt5/svKBlTCsLj nuufWzK59Otia4IUF5eUUcZKjVIfe0hxW7ZYHrCwYxZqKbJZLJItaLTZY0V8KCcery6Ox4uKg7Hi EgO2EV1abTXTagUWNLBSn0PtcrsvtLvdDnvQZ7dFc3nXeWESXh/eGhbeCNNwUSAcBpeKBvz+kuLi UMDvDAT8dpstxEoBR6V5sRh0KkJDCWtZGIaQMoOvtCTud8T9PubfD6NjCR2lOIvjAcVqaCQ2agWz Ox44FRADfbTkqQoWt5XG7fvpKGJLH+q1GRttfelDioS5Vhsltkm2L2xpm2jD3N7y1uVelDcmQCC7 gIoclTPVfpVScugCoy3vUEUMwNcGjQpaG8q8iQ0/BoTpz5LQf3R0lYOKDur4PzXVo3WAYZ4ACh1U FrIAMACcNIP41fIAnAwMCEJMEK7uf6frFxzFUy/yvImu/lqly7+i9zap3S9xIN5xx8fhv9INqdcH gFf4xONweM48P9CmG9iC/vs5rb4EMLQSMNRMn1fM9l+4d5b3ug+WixkQMVkSWcjwQ7gHEEhBGkzI wWBEDvpLqtQuyEzlRdXl5VXVwZKG0bxLsjaCeTcmmhsbRzcHGzLwY9ImsuCTAR6TuygLO4l89TzW QlqYyCsszM8LJpK1vKuZ1NP6RE19fW1NMBmLhkAwDL6qeElJIhL358cTiQysNCSTRgBSdSivJpTX rOSGax5o3tXMtjQfa2bNfeyAEmi1h2TZFqpgCtvKhEnsDcasbC5bCVr2DIxGLWQcfQuIKp3u6OgC hQH/7OhKgOZwLgpiA7HzJAoONMg5oABOzkLElx1DuOrQ1pChIY2h8/5Ti7MXAArEr32kHCBusDob 3QqycgD80zkONJBxuaidyt8jdVloGqAyEJ3P7TkH/oQb+t/sUkHpfZ7PreEA9Q2vdrHSVSG/L/wN 76mZOzDHF17F6lKhAdDKgBoHt9QFdA8vefrWPTAOmGsHzG0DzI1mC5UOb6m3zt+UV11bPaxurDy7 abG8vOly+ZqmTcqmpm3K9qZdTQeaXq12WElddWv1zBrRGk3Ujalpqr2w8nDjb5VDTfpANFC5NLq0 8s6aXaWP1n0c/ab0mzpj1WhCKg1WDkYmc0IVuIIGX1iFNJJLc6sjubnhSNBXXMG73JHSraWsopSW lm6tLC2tqAwWVxI9y8zWUE21KlQE9V67ekJXwuZy2W1Bb1GMtyfHrfFwvALqUiIaB/sOFkXlphql TmwcHa2EKyMkR52yHCVyZVSM0Ip4cSxeXFTkq4xGI+G4z2ePe1n9sPioxka9XoorIIl97Ko9suw1 VPXRtqcjo0dXktHxqv301zBfXqV4lMmVnZWrKgWwnsrJlcLxylOVrLJp2AFQzAhppHWKrUWOgKza ICGegpDoax63n04/q2WAr0KtamjwSaf9/V5Aepcfsg3hYO33qdB90tvo54xW4uRQxQe1wbkwxj3D wXe5LuAjSqihkSi5w5D5qpB5SpE5CxtVjSLRvkHz48M4r2e4dxC57OD08jvkGdLgWDBoanlH1/eG Bx+pywERzQiY+0g0fbzXl1cj96WP96DELbRztOkioPg/hBRZqTdmG6C5A1hCuQbhGWixeAG9cDsH +tQOFQ9U9KCdvGc7a5nDy3/xgWiqavHGxrzOpbznlz/Zs4H+LrVpAO6/w4v+M0wzgBepBcXXrmk6 xSfRpUeKwdYhmy1JHxOXiE9CvvDRb5X0K9YXfMz+kfsj7zfSN/bT7tM+7Uvud6V37W+53/b+Xfq7 XeeX/HaX2+0VX7L/2/qVQ7jfcJf5Ifao5lHDQ+bfaX+n19/AbtHcql9vvtlxs+tOtl2jH6Ydpq82 NJhHSNX2avcIr76YJczlUr49313uTTLdM9aDUo+9x9Hj6nYf9O736Z+07pQetv/S8aDrIfcu72M+ /UzHFHeH9wHpLscd7vu823z6Vkerq9U9znuBb5Z1ljTVri/yjrDWOYa5hnsnWsdJrXa9SWvUB7QB fZG1wFHg0mldPirqHVaLSHSefNFgyzcKOfnc6RqBYXkHnEWXO/N1vl5/81WqFDXhZH9HRohS9Rqu OtAu9a+D/5Gujg7A5V63EVqovS/9VS9KCYpYr93b6OYKWY4z0Oj2uoONXp4ZACq9Vh8f+oSXmr70 W2fbJjtvP9+LEvPU0sFLi63RxY/LlKeVHLPU6IpY7KMcIWS0L/1xLxRkS7ZkvJRcjeZs6e2DhcBi c4yiOcjMUV47q9CerWTQJ9FOOqiTQQ8gNokAFu26GsbVWScadnHJxi9ufjX1Kq199ebPb57x+bO7 z1Ddw89+zsb8OvXXHfA+5cAi3rYj9cGjr9MxqVfe/yT1Nm3lsNUL2jsbtDcGheeU4hX9YkAXImFH wB7OD9QGWgP7EsZie0Ff+nNFWuv/iZ8V6Iv1d/jvCrNzqWmGPpo0dUOIY+VZ4lhij/u8LEZC+XZr XmMey8vzGvT6onwryK+/vBQESvKVfXVlRjL7ztrTMYGzXS6NEU5lrHkK9iAPXA+Zycr5XLsqpg1m wUPIxDkNTgW4tgU1F5RgqKJbPcAMM92q2pUvV9XVcTVMpt0Z1TcVGIT1Hz/557FV4yePuDD1DTV3 PDj+setTf6LHU2uGovlrN0+5Pr/e75g+7YpRC37O170N6/4c1r2UDKO/2Efk9GFlYkQelXB6vKNm 115cubZS0CVGVI6rnOVvq1wTWVNyRe2ttQ8XP1Z5JP6n8JuRY/E/lX4Rt1njhsrW8Bj5ipIbw5tK fhr+Zfjxkpcjr8gfJSyhAzBGGYh1CMcb2KOhDCz53R6FI8UJWRstLYmFy0hdlhuVklB5GV92ZNbG sjI9GF28uNiA7QvvZ1eRUrYDGiMeJCRV5+eSOI330Y6963K35LLcPlqIsSidHN0RfSN6KipG+1gQ phBFouXSKYlJvvpxWWkce64yo46uEx0nOiBdgS2pFjDObk6qEjlQYYAJgUHZh/8vBo0hjAUbX0/G d9unje/Og9W3J2yO7IcZT06f3pMw17rDoBA9NZFKYL9q3gKM1LfTrg5gHZT1/8wydOAPg7hDfvVZ kJnxfT7x7f1v33jfrPW3KhyKVt33+MrUlx/+qHfKo1emXmXG1LihgPPSj2c9UDvqvn+qDMHzXO30 ycvrp98DmWkL4KdBxdvblGKrwVwrSUFDNDdcF4sFc5leU0tpUO/wuevsUMdidmhbDNsFVX7lU5Jk C0HUR1WJSLnluZ25R3JFa25j7qTcubmrsGu7co/l6nP/nv/8SgjBUJFOZ/Vu2JCw+hRyMNevs2r2 0BYW+XtLJdugdEO5hayZrbCt7/GH71e55HupX/OnE57kPFAc9Z1kKHyS+i/OOenlqZvVMobnngZe eA2eu4JGD5BcgHg4/XVPWMrlptcAaHr08sAJ7Ue5n4S/YV9qvwx8HT4TMZiYqKUBU/jGwHat1u7l MppEXJKLuap9LpfXF7RnxL4cAomviEDgI8Fim1GV7SxFBovFaAjaMrLd2Hh1VqaD3AbBrajIG7cb 43YbC4JjReUQpSuxN8wKF+5cbnSu8vlDev0kw1zDSsM6wxaDxuCrHHHJWSLXoRqzYdTuyNS4TYDL VRzgOQb8gKVuEGB/T1XgXJCb8WC2pZkFx9KrQj6soWdFHCfsn6BrQwleTOj/7Ferdl41NuTPMYdo Hd+k7c9dP+3mxdt5NdMhjuofvfvU/JeuYM9hxyxGvm39ozc/f8HPF6g9qnwPuYUi0omID2GvCtk/ MmKZ4nV5mduj0Ypg9IV+pzYeMTNDHnMVZRCZg1cDgCxrB1SmrfSvDKzMXRnc6L7Jc0hzyPmx29Ap ddo67Z0O8QijklvyKG7FI3pZwBPyhYOhwiJPHatzV3rGsDHuJk87ne1u82z0/NrzCnvZ/Z7HaVEt FTZpMgThWqckOZxBi9MlF/C9DuVF8lblMZIn5U3OO5T3Rp4mb2thXl5BYVAuJGatOsVgNYQNzGo4 aDhm+MKQxnZu1RgMWk3QrBEjfj7FGZwLpbjWFwz6fcGIz0vwwJG+1L+VGpcoRJwaUQy5nE4YoQsJ CXl9Tq/XB/+IQENeD+oe6KBUCLncmOFmcU8fu0wJeeNQdQVXXBD1BXHZz/8jEUfcoo1bzDATUx6P 56UdsDUR2qFUHfHRsI/6lOJan1JTV+NbX45KLK/Gp8QLanxxxVoYLpxbuK5wS+EDhUcKvyjUFx5g V4IleWiJ4nHjMLdSjoRD3Yq/1ur+ws3c0Dz2MCVeCx3oyh5NxPUsLudEeFkJzFuliivspIec1BmX NHDlTNJs0RzRiLC4lsAV36rqGgszxpaTICaf+6QTfqk/0d/FJRzvRz6pv8vvPamKO10dJzDqlT4H y89iAYqMvt1wsv8kN8ToYeRD6f2uwjsyphmcb7DGoCoXgzSI7xlrvt8BdQQINL47DjZRDDbxNFvP /B6/269iVDtG/FkGso+w9Gc9TO+BO263W8qOqwpGR0e7DONMTMjq1gNY53BUOxzn9Alv/+Tzv//k mrCKYPWczh1e+d/X/X3FCxmM4x1hofFbxOsM6AjfRoXyb/8g/GWgreIa6T8ivp6KQUew7NHNpiax vJyUc+vigA1ftX2Kd515kJ9X7Aj7fP1Hzp6Bka2gqxcK6xEXUUfnK1Me0z0UfqxMiOvyw0lxjeNy /2WB9c4b/bc77/I/rtvhfMi/s3yv7pmc3c49/n2hV3NOV7qMCFAppsK9tjv97OqyTWXbyx7Lebzs hco/VX5YqS8E19+p+PPL5fz8qBwttAcdnqI6mdQVUaHabCip66PHlVl0YyExVsuCySCTEqlkVYlQ UpQ0mwud90lyUMcHLCQSkRWLu9Eq03K5UZ4kz5UfkHfJB+Vjsl7213u2VMhaPr5S+4D2oPaYVtT6 hhUf+I7c0sSE/o84uYXdj+u9qg0W3rXyk+UdsMY2NpzmKi90VBCk4RAwbEPdJfCQjO/2ZQHgINGB 6dSkT5FaJF/6dK9dX6bPCA8Q1rsw1YSpTkDRARLCFEf6UH19O/QS2iHXZg36EBs8qpE/a+GHi0W1 8Q9wUYFbEKAaqfR6mND29Bs/e+z42yM2Tlq/fv7uiEHyGHMW3Df5gZ5VHFBeSP7k/KcXT7z80hUH Flx577aVVz1llTa2Xjzc6LXbjFZ/8f0L+o+qksQvbdKk5NQLlsycy2XRUuz9TNj+c0khzdvNSeRO xSSVq+Qxasl187bDV+7y+dyuaG5IJ1BTJG7uMPXRBXvjsiEiQ5ZYoBQLufAh6AymoGzFyjOtvzg2 nZgjLic32FqdK53HnILTV3TRbYO3g2/CCb4hXMxvbIQZ4oQXKO874T3BdwDpB5mguhnm7GYo05cZ aIWpIm9s4YWFCwsfjT6c9zTdZ3om9FTBYc2r+qPi+/oTmk/0NrdYSas0I03NdJLp/NCFdIamQ9dh Wkgv1iw3rWVXG68OXRm+ObQ//Gx0b74b+tupHpNUCJlwd8jNd5ZvXlc7tWGPCDSvWLTAlcXns7oD VV02mQ2jxfe83Ue1qX/tff8OFaG7VFuB8PP3br/9PZ7Ev/W/+WLqy+cPp069+LDqOhulOnVefuC/ /usBJBW3H8f+jAduFpNTe2UjRHConF8pJai85Ho//92C4+Hj8qf5nxTo8lwF7pbIhPwJBTMiHfmz CpZZl/mW5t/sM0On/aey2uFsd1zouiT/4oKv/Bqt3ye5/EVSkT3fv0naLt3tvcv/sOthzI1BnLH6 nAEEaOpzfLkeK7xBNhPZaJOLdKZeUZv7S48cM+Uk9e07wnRr+FCYhf0lThmMxdC4I0658WsrjF++ xOFBOw18m3BSRbwJ3MYOvxl+2GIP32KV+/Pd5g1sK5dfIMRwwXvAHabl+AK3LrxhWVzIuMI42pDa GujAwgtYPy/1OGwept1154Hn33ps/qtTXfCHLXrw5VdTZ6jp1d8IllyOJ8+F/Z7A2PWf/OzBo+dN dnpsidGXUOGlVykP9gY+XIv1fhz4EMKK//Wp84uXFCOUlSNBDryzmnJVv43qQxAkdypSoNwTCHg9 0ZDRHS00dBiBCr2FMlYcKBGJys4QMZucOr6PnrAhsp5HLVPqL8mX10ME6aO39CaK12cQQvqqK7tC XPEBaYLrH0IgnIsnTnNc+AFEgABYWTG+251FhN4cvR1EqB3UZwA39iES4bOeiLOAC8nx9N96Y/o8 31k6dVZgj6k0iXt8sbSeAcnQMQicRZYhM7f/9dI/XHnlH1a/f7faXvXOXXe/887dd70j/u3MCk5f fvXylccvv+LYVS/T9zLQvOP993dwaGZkPda2HLDsg1HnDWWp0b3NxarYaDYVUbsvshcdv/O9Z3/P 937gv70fhv/ttvhyi3NrWH1oXOCC8JzArPDKwPLwtYFbAttyt4We1ljXuvfnHhYO21/JfSWk1b9g 80ciEJVsQdmjE2WbyTzdn9xB6CrIon30Q8UTjSRpcoeTrnQedB4BORIRaVD8xHfkqGvCSdURdPKE yhfAFiCQSuCigxazx+3UgizsCTjDIdhzPlPXkZN7GBep7HZDrM5QcKeOw2wGNolOhVydWPrtr90f PnrR75scOZJXqvjyundSx6j15d9T40zfn+6446if3v/gS6OqrT6bTaqaSQOvPA3q8f+u27zziVs5 bFJEqBJxFmCzhryq5CvmyZr1mhvM11XuMPeY9ySeTxxNGD16qIMvS1LUUFNGKmllHxOfIiRaBqWw jyqKn9KoPq8wSvI7iuQgXl+I+MpKvVqD3hgFNCrGOvjZIv4jKnDepVjKXYprlesNl+jy1a7dR1/L ODA7JpzmzrEGBNBwpbAB9cb+EyrPHHC7ZsqO7/ywqlM8pzgRwJaWhEkiUBSmCAlIXHcdvBk/ZIip VvEfERzccRvl8RtauMYzflxWTlVq2r+SizSvPsXzp5647fIN1S6vU+/42ZIfXU5v5p2CpX8sB0tO X9k+DpHrlt3n1rvtdo/gWd66jvfwtZ2BtV2Bta2nlyql2/xnIkykLrpQu1a7ld7JdtCHWDftZcaH tY/o9mj26l7UvaM75tf59TaI6aAEVmfYyZxzvE7YcKK2onLeaSqZU1FSUl4RLZKgT3IKAvfqHFWl jEoZqciUPycrFdXDg7ZTidWWV9bWVlVG62mkKFcWiwoLAQz1RNRJRr0h4jvmpaA8DyqmEUSOVB6s OFLBKvrop73Dx84boCN8b2BMQZ4lIqoFxfaDJGSIiWyoQnnu0IB9ncLJigANcMjjPTZ/1r6OuCTJ H9DotPkBjS9M/brczBZjj4FBA5aXfUSbPr03Yg47Mzy1HboEiL1NDW5wuwYknwE/p40TIJjivtef Zbx06uQ7Zs+/ec5FEGnDqS84fb/ohrVzmsqXZ1xSn3MQmKtCCrjtmZljW7dM6v/XWXgQZl9VGrm8 /7OBDlFlwCofeBbw4NbYoMbnknVKcdRX5VN8U30LfGt8P/HpHBapzemMWrRmQ5tGEzW7c313uSAf CS+wPnrnU7lai9lI8HYCNwMwiLc5ogjFaRLUJF9wyjrVgg2dn5st1X1qaPwKcs+QyIUBVIIU30Fd sVrHOVhy1nfHtl6zjo7jT97v5U9Lx30Jg09YY3v33dSUb1XjURb2wSEzdOQgnu0OwDo0un2kCJuJ YKwiOBB7nWa1VCYhEmux4xEHO1xDi53F+WVFxTWFtcPzGvNHFjXWLHMui5kudtCYo87BEs5JRe/m v1vzWf5nNWfyz9ToR+SPqFmWt6z2cefjMW1ebSyGd0FUbNCUGzQavSHKcrlCsIcgKgB2t0O9sJrz UpEg04TnxMLhaCyaC5N0tYozFRVjaioqqmuipTW1NpN6opxyY06OyRi1BVy87bB6w17m9W6DCu1y RgNOR0mc948tKpqTX1QUz4+W5Ofl5+VFamuctbU1MYRxOyIkhgikGHHU5jk1MRpN5ua6kgFtPFlS nSwtLSlhpqTdRvRJyoxOrp4YVsZo7N78vBm1++kOko8ey6qa9TUsUlNR01kj1HCcDA5zgKLSiHGV Yb2BSYaIoQKVHYZug9bgqztA78ebTl4KZXjA1qlGr8DsycOJTnNvRsOAtsv9y6q3TRWONoiqk20f dIijvXCzwflwtBeeNrWEs00t4W/jZc93LjfKfW4bcqAca9TQmEG68LlxCt9D+x+eC7ms/NzpQ5xv DnhE/Hk1TtWjYqvBTR3vsdo4kVC9cIMlkxgkE6c+n4dL1qS/4sw0Y3TtgqadB5FmMrSnfSQGr02+ ryaiDnMnHneT0AER5azoXX3WczegcdNzoyYofWaQIP4CXZRQEcbCkWdeqo8+MI/XUqd4bzL1M3pZ atMgsfzftIQLmZxhpD5PtQ/QDLpa5c0HgFNO4JSXdCg1812rXTe4BPDiNs6LwX3bOOe1e1132WxR LwHDJTRik6RJ0kFJkHy+wTSBc9X/QAt+kA78dCgV+CenAgNC2XePwXndctzrTMhh9XSDMuxP2j/p 2WHtYT17UN+j7dELXbr1OrZAt1C/MCBsDzysZVeHe+keJuSGl4UZoSJjITwJxzDJ6grDkDpGNaRG 7edyvQy65pAcmjMmi7EZrieRfCmfncP6LLVjMqyvKlmvpfvpcRKBFO0IyqIOXNAOJdZgjPiPwbjF kU1SGeDWih1ggD7O/VSsUklqlvepfupGBPU0nvyfLalDoXho6//K+ZyBXI1ep9fqmTZXA6t1QB/M cL9ilfsFsvJ5D2xlfem/7A44OTAT+CuhUcJVCQqvyt0QdQY43VnNUhXBf5gBzmy7rb1zUv1smG39 ob9y+B1z/YppV3UN5n/qmDB/XXtLUWjz+f1fDIAuE9qvbr6x/x9n26p8xHkEIz+FrN4AGDHBNHie Um93i26nxy28Ql8x/Yn9WfNfuj+ZtJfoltrYIrZIXKpfalxmWW5b5LjYo3fJglU2wJCjM8uEE3j4 U9Uyx6OWisVV202oBL9uJ9hjH9ugeO2w3GCaVsGclTDeHNEe157SarR99INeb/GTZ2UboD4cv108 RJmbDDidVAV0bmvhjp0DiB49TZxw60jOHKdnf/oDEM0Pei0hW4iTF/7HXanw7HRxh6LJ7ZQCjU6e IWLsK7CSUKPJiUxvRKbjGfo/U4LghzonnGAmnrmdNs8oJ88cToTeYMZhxY6K0QhWpucZE6zhBprI Om9V6ybP2im3GgxoBYN1q4bUSZgBPqf2w89Tx4y/7tjxV57orkOpU9R28BC1pU795ud/OXb/fceP cZtN6loVf/Mh4pcqjZVG6/ACpNrSKXQG67AspNgT7SWWNfTq4kvLTL/VHjK+q3vX8F7Bu5UfaT9E uC5eJrxad4uwTXgCbz8iVg+iqq88iCjFYNTtQpwM2vaXc+x2a07UlY84mZ1KU7Q8FI2GQ9F8BAiW W5Ou3CRgNadcNhmLZHqHqCPhZL42Llv1VO+vLiE5kZA1OAnW8JVBMeirGmz24TjKI/lVo8/JhsYT 3BrA/R3c+PZDeu4QfOQ672ClrNBcwZ15paozzxKhfNcr0/+1uyCW2fEsW+HRfhk84xoFN98M4NpZ aXNAqhy0NbR4/BNrr/nj6lT/s3+95TWOZClV5cgac+5/855tR49u+9lRYf622XPWHLl0byr9dErL MYobWMWkyi6W/vTIG1t/+sYR0F7EQ4uzhMuh/LgU5zU5tMQwybjMfqX9Zvvd2vsdOlU2Ukzhl7Ny UMC1n+2E2KAohqx4w0PkdiqTCieq8XHRhCnHqb6QptFZ8DqcM0cy5uUnSUJrbJRAOiHVcOEmYLTq TumYzl9KnJE8a2xybH1sa2xH7FRMG/OV9N/2HfmcKH3UAQ40ISOCYGfUcEi+NdxeQ6FHDPI/nbMt Q0b+o7KA7bNlUXavw5njtueqmIkw6OwOqSpf1uajO4flnWX5jD30YOv463wOY44jVuMbtv0gXaMK wit4aNqr8Fv5wsL8o3fOWOR3QGaP+dseT9WoW2OHneiZjOqHPTmSPiakQOta6D+Ujc7G3CZmvwCB aUtbnog8MewX9a85Xhn9F8db7rdG/Xn0p44TNR+P/tZxuubr0XaTQ+vWjDKMDjtcbteowOjN0btq DlhNMx2z6pfWL0teVX9t8ub6m5MPO3ucxtuSe8Nsij4B73mlMrKhxu+15uhc5uGkpqoiJpbVWXPM ghG2Nl9y5EjZJjfDllS7R4iU0bI+ereSG6+TZZLUzRguTwrNDa0MCSH/mMrpsWSRS1a48OwG9VTa VxbRIl9rs07Qxo2y6aKsbYnrgWooNTR3moBjMWNz7e+HLxdop3rbbbCCY5NVk1zGAJ6xzsEMruru 9cNG2yO5+Y58zyhXmCQDw8N0WASZfTSa7kZvmCB2YeSIYAN4nz/ZUB+uCxNnk40zwQSPHstkXHLD n8oTB/Z/T9JZY8x9Jv034kl/RlogEo5yDgPR7Y26GzhUZP6gJ3ZBUQTR3kfqQZENsPMnncjqOX32 Iq4m6UTWwglyixMkuMUJdSKXnwcrwyc9zdmQk2eZm+A55wXZkHvVO515S4Rb3PlLImctD4i555Qh a47EGDf01NYUxPPi6jsSVcI1GcmQWx/rp264dWJyTMVNu1rmzf39Sy+t07ssnBjYfZ7YtpUP7Zgy NfXSxguO3rFTSATBrbeG/G5fQ0H98ERtQ2Gu1eGNXXPeJb9aFHXm+ENPAoBdZeGKxqtaJpaXR2qW NCxfx+W328Gbk/CtlpBXlLwzAWoJ+APsIeNe4/PGN40njJrLcm7KuSvnkZwXTW+ZtB491XEaIsKw 4dKLok4fpZLT4LJZJZvdqfGZi/rog4otlMzL0yUpJVqz7DM5N+L9q0cVZ0kJrA5x+UWSK+VGEB9w MFcDfvFhbyl4Mg8POAHyAGuDajIDDYc+q0YFqlbdoYQiYwHyB4wmk98QJsaAOUwyFiDVrI7g54xh B3EC55rRBlzYddUZi5DbBfHwZZUU16/tmvHiMKdF8loi/+q6Y6fqqt7ON0OYz9G7/w/nz6+OWPj7 KPKETWtZOe9Uo6T5Os7GOrYL80kBaLHZKO51s0I39cOEprJAc7nebDboo9aMsdcUmJg19hbIfLyU 5NG8MZG8PDkSLaBuqzMiJ0mB0eNNhkMhq96QlKxaJ9xWsEoSD9woDyqGIskW0R/RUbz49mlv4bkm GywkN45zipuNt8zQ3kE88T8IqacPZ93sRqpw20xkiGHG7hC1mnyHaAsTu9aZWfkMGjqyZPhZvMv2 GaSnD4g9/QFwjls1VUcV3qX6TtfiezPsu2Y27kW46YmXr1amqWaWF5ZMfP1xdRu+UMXOq+9rblvL Qupm3Dp12TOZasYuwfegPp0W78QeFAolysOF7gLPTcJj7odhVNvn3uPREyaxde4t7l3u59zH3Cm3 fgc+inCECXpR7/KKXlchKxILXQWeerHedZ54nmumONPZ5mrztRVeTC8Rl7gWexb7FhdeLV7husd9 t+cR9rj4a9cOz152QOxzdXue9j1d+Ir7Jc+f3Uc9f3ef8CRM7oAbH5FwJzwbfBsKn3AfcL+oedH5 vvtj+rHna3bG/bXHlvGQ5UhnXWSZCIKdSsmqPEoQRaDkCad4bQeCCIRVeevzGA8pQMTbNjWeIJqN J9ipFM1Vg0KgJYYNkwzCFwa6Sw0tQAc1GLapoQXRbGjBTsUWDJarcQVRxBXcpcYVpMcpVQNxBfC0 ZeMKIoPiCiKD4goi2biCg9CsPHQNZIrjWH4XTBkxEd+OocJ00ViQlP3JiCNp0SbNciRisZi1K2Fx /K0PTr5blDi5w6dUIJ6gMIF4gnzEEyjBEDKfHxlUfF9S6UTg/gH6K8ioHroZAQUzmFI5vIbxeYzP Y4pkq4GJ7FeKRRPpdFHXb53iHc4kwisP9VTU8qK3fniN2kxkmriM2o0zqCWOV0ucjJeK3e2p0Siu 2nUIPGA8/oAh9uADUoTPv8gZcwvIVMdZkn+Sxxh08BAE/PWrAQgdAwEIidOIRzjRQbyZSH/OG1Up CCFQ8MNI//cQhO+ZWfBOAQ9jHmxdgfL3/c5sHMKAVrO3UO/TizzKIMsG6aWyThAKBkIMBsLPBocY DPQJG5fs61uys4iTy7/x7JK7ehf2bVnGrQMfcWGpkLJcmO8FC0dRFU0vZs7+z9i9A22uD1J8k4eI y4Cnzex25a6wLWxn9nrbTBsLcE0uHO2kK+wr5ZWxzubf0t9Kv7f/Xn4t9lrV8zXPN1v1sIncExVI FbU32+zNMSkak2R8a4HKNVUxyS5FaJWT0qqaZrvdHpFrEB5fw+CqsSalpNGRtCflZCTpr0xWJfOS sWTx6GRzsjZZk0wqzc2N9fWNsVhBWVlBY7umpo+W7Yk034swX8B0gFKNWZbdZrOGuBHCHaT3WjUr ARz+VkTSH++N3VuA99kwT763oN0aLM8qK5qgr8Vo9BuLtUntR/upDhCEV4UGCVAnfKe9JxEu71W9 db4JJ7w8OhXSkw8JAlQ5Hz3hP+mVTvBO3pEt/cQrncTfORl/c02Vauzp3/XCmIdg5aO9MOahfKIX xjw1eNke4+UHvdCOUf6lJ9AwKgPR7XgliYe/cGU2JtXheKkEB0s88l4y4jAphGOkEAQlKXr2KITj //iwFX8ZlrHX5rVYa6oRl9yDEuJRO4zOPPiR68j7SHX6A8UABdgWgu6LWR8o41CxGd2eUTa8JTaq uQmv8VKeNQ9DlDXlWfMwvPhLedbM3/6F2dvaKBuDkVE1VmRVTl9glMTltSouoKHEU6llM3TpXsnJ g6cPKxZUYg3IZJ5lZcezmIxKRpLjQhytyniJBjS5c0x/ddUwv2VktQG8oEPj/LUx+HiuizutsP/9 k6PF5tS+1IFbVCHji5Df6ojT61KP5Tkw/iH3NSykARpcyJHoQz6aR19IbdG5IehxSxsdnnopY1Ox uHVQac7TqyPAr9QX1JbBK7Obf3uMkrugy98DvKqizyiNXuK1e6MJi+yppbW2SRbFc8bxTdRkcIx3 jIsuoUtsVziuiG50bIzusz3r2B99Mfp2NAcnsVfZbVUO/prWTiVksZSr72lFsTeBaGg9XrPcFg1B ew9EYwk4BHfuKatQtQqPYqoqK6usiiaqHIaMi1uj2ZZxcBso8Tv56WyeCg/1lOPFHacj6ndUFefx 3hUFBeWxggJ8IKU4FnVUVUViUWcsFrUBgQlsHHYHoVUYsOPlO31IYzcQYzQZCDiTfj9wmiWNBm1e srgyiZfMc0hocoitCh0PneI6Tc1kHkQmaSKaVZrjmlMarcZXXbxfpeTqe/EnOrqgn3adVVAHAsVg Ls9GEmzQl6n2bo4V/4vZ+9wIsXPI9dlh9X3pf3SUS0Mp9+nDOr3UoOev7nV1yFlwgoyafdH0ewB2 jjVaZstTV/lCfovL/REHsy58KGqqKkJ9GPZLzrL+z25QoS+X51QH+my3uAwqgZ7EdmeACOB15oUB W0OGTp9EHM7ngCcP+btizOHGKKrPMbJn018RCyIAjETE/pl05YJOJwpRo1sFmhZHudXhkKxRdw5l dhax5DgtFnzohuVQt4WZaY41Qjx43zOCjwrQDjFpNTYaVxoFo9/n7lhppmafd21W1+S+jQnZmB5o BZBgecrGefCgKpC7zOtrDHQO9Apu9EOc3qklqBbKd3pAszieczKFV9Uz5lv15eohDSw8Vw7xoTUX 3vHN6HE6vOwrZ4wHtbXCW/2bWT3sMF7aT9il/V9lFIPx/SPX8EV9eTx7/lJeeQl4iE9QIZDyD7G+ udaGL/V48Yr/vTTp9o+/K3mUHTyC+EiiOp8P4Dj+nSQc7Ejr0n8Uz5wd4aP8r0B8nSxGIkj7kT5E OoH0ONJb4uv0dZQ2pEuQ2pGWIPUitSFtQZqGlI/Ej9+KVIrEj70WaT3S20gzkJ5FOoh0AGk50k+R BubivsntSLOR6pEWId2FBFjB95rqyVS6hv6bvSYsE3aKb2iNunv1Lxt+YnzIFDF9ZXnC8lrO76z3 SlNtxLbDPtFxoeOw60euw+63PA95r/dd4H8ocF6uMfiX8KZIjzxRffoCGiUM36LTIJdIOfesCw9o ZuKreQzXo8SeXSMtvqKHD9g0TZzalGheufbSpYsunbjo8snTJkzn9mf1DzGNaPwPfwXoE3D2zNcX PXhzPY8kSBm+QFWNb1ANwzONIPwrVK1kDBmL71+djy9OXYBvA04iU/A1wWm4pwvxzbw2fC9qNr5f 1bEfn4o6JBzqmVGt9KEYoRa9OXlV69HsNVnUssdQ3dhULhwiq5B2IR1BEslc5OuyPQIJo9aIxHu3 IIlkh3CAdCMdQnoDiffsR89+9OxHz370NAp9hApPC0/15IVxB3vw9lrVF01+oZekkZjwU2EzkXHu i7Ll3Gy5BWUx+rdmy1uFzT3JsLXJgDYlXyBPIzE82309YydV7VMrwxrUyvaBnu296Ak3+YT7cFf3 4a7uw13dh7v6AjnF2bejfzv6t6N/u9q/nSAEAOeUi7Knylbu67G6sz2oNBmFduFC7EkY3+DLlDOF C3uqwgebOoUZOPUuNd8hTEd9i5rPVfNJar5OHV2n1leq9ZVqvVGtN2br/NhytZ7Jw2rdynNhqjAN QchhYYowTi0nC62ISw8Lk9Dm5UThfLWcIIxVywvQ70X/eKEVUBoWxglj1Pb5aLegfR7avBwrjOlp CVc0rUJ7Lsbw7UyB97fgTlqwmS1YJN6zBWkH0jG1Zy7ydUhHkAR1JhVa8GvGr0lowhEKzqFgRCGC oODXiN8oYRRGRuJpRiJXhAY8bxh5OVIj0iSkuUiHkN5A0gkNyCNCLalAUpAmI3UiaXCeEhxXgvvC 9+fgBIAJA+eS2S0I5w4LkWwZZpsR/RYWQmxzTyisNBnYHnwpcA/pRFqFtJ7t6dHYrU1OzONzy5Em Ic1FWof0ANIuJD1pRI4RxcTwCjjetZ4kiIDuot6Ghiq1rK7LlLnBTGn2V1mbLhWKsExF5AEkAbdc hFsuwqMOtMKoMYBOATmIdATpGBJf8AIsRgEWowAPWIDjC9RZWnXeF2ilkQSyEvk6pMFz+NIU4JEL cK3vzsJ7C9FTiHMW4phCnK8Qy3gMOVWP4OOTkbYgHUTiY1GMbVHzRuSTkBjOEcUT8JoVeViI9qhv 0G3uoSOsTcOw7pOQMMhuxWreinW7lUMIVg+wjZHG7IwtKHchaYR9+BXhV4BfIX5R/GT8IviF8YMs hdfbt7It+N2G36343YLfZuyGc1fiYILNrV1Zu652S+0DtbtqD9bqDrB5+HWyTnxSxu0GdbXb9P4m iYlkDqKW/q3mT6r5pWquqLlH8c+xnJhjeXmOZdscy11zLG1zLBPnWMbMsZTPsfQhltyTsPw5Ydma sFyYsNQlLLUJS3XCUpSwNNnwWuJMBKw/p+aj1bxKzaNqHqQzeyzE8Ay+ICLrAfG0YI98XfhDuU+k PeEb5D49iuszrdmZIsk7nwpXyIvDJZmeeKbIk58VcQYygz5BdDShlOhe0c3VKbrhujJdqa5QV6CL 6cI6JyInJX2O3qw36vVw5Ip6pid6HsWgJDjXcmrxRStYR0Wei2pdApei2DaeI8pHz8g40u0QxrPx 00YjguHQAjJ+fqT7q2mxPmqcMqtbExtNu+3jyfjpo73dwxLj+3Tpqd31ifHdhsmz23ZTels7Wt1s Yx8l09v6aJp33Rjgn7vbh7jGkhtvxbdx1LK9nR/Ttlukt97aTtyXNXob7aNsw8e0/A9Zp9rZ2TJI bfIOqif4nQS77x4/ra37sWB7dxWvpIPt47HO/Ot4+/CN2LrWln1sGC/a2/YZ17P61qm837i+BTcy MI9E0N+Cdxl5oc4jET6PRM6ZF2LD+Lx8XmTmhdR5oSHzdo+UW1t2y8gyc0aqc0YOnbN46JzF6pzF 2TmCev/qKQbOoztOZHWOrDuu3vvgOaHMtf7jnPz/cc6g5Vw0elDje1W6j39cYnfzVa34tGBnrHUR Umf35suWeLvXz49E9uG7G2/xoUi3EO+cv2AJL+ct6qNvxRa1dDfHWiK7x6mHDh3vvooPj4u17CZX tU5v232VsqilZ5wyrjU2r6W9d+y84ieHXO7mgcvtLp73/Yt1z+MnK+bXGqsed861nuTDY/m1nuTX epJfa6wyVr2WCvUASz0Z3Q7DgVr2MpMRANwZkNtHu6VVo1RoTsreawP7RYKPGJjw0T8zPhNpQeKA XtpU2sSHgGV8KAfd1uyQ99qkHMCHD7JDErptsdHE27q0Bf+rV2crmeb/mq9evXrNRasvQrF6jfq/ es1alHzP8DnS1Wv4+8ZNZpW/hUGNOW3ejHSLSqOF1avb12SMD6vXEn71NTw7e9Hvamtxcrp6MCQQ fskhfxjloQJqwulWr4WlAydHJXMcXQ0NJ4HT4NA12T7QnP8P3Udx5gplbmRzdHJlYW0KZW5kb2Jq CjMwIDAgb2JqCjE2NTQ0CmVuZG9iagozMSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3Ig L0FzY2VudCA4MzMgL0NhcEhlaWdodCA1NzggL0Rlc2NlbnQgLTMwMCAvRmxhZ3MgMzMKL0ZvbnRC Qm94IFstMTIyIC02ODAgNjIyIDEwMjFdIC9Gb250TmFtZSAvUlhBTlJBK0NvdXJpZXJOZXdQU01U IC9JdGFsaWNBbmdsZQowIC9TdGVtViAwIC9NYXhXaWR0aCA2MzQgL1hIZWlnaHQgNDMxIC9Gb250 RmlsZTIgMjkgMCBSID4+CmVuZG9iagozMiAwIG9iagpbIDYwMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA2MDAgMCAwIDYwMCA2MDAgNjAwIDAgNjAwIDAgMCAwIDAgMCA2MDAgMCAwCjAgMCAwIDAg NjAwIDAgMCAwIDAgMCAwIDYwMCAwIDAgNjAwIDAgMCAwIDYwMCA2MDAgMCA2MDAgMCA2MDAgNjAw IDAgNjAwIDAKMCAwIDAgMCAwIDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAg NjAwIDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwCjAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwIDYwMCA2 MDAgNjAwIF0KZW5kb2JqCjEzIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlw ZSAvQmFzZUZvbnQgL1JYQU5SQStDb3VyaWVyTmV3UFNNVCAvRm9udERlc2NyaXB0b3IKMzEgMCBS IC9XaWR0aHMgMzIgMCBSIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyMiAvRW5jb2RpbmcgL01h Y1JvbWFuRW5jb2RpbmcKPj4KZW5kb2JqCjMzIDAgb2JqCjw8IC9MZW5ndGggMzQgMCBSIC9MZW5n dGgxIDMyMTIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdW9d3xcxdk2PHPO9t6L VtqilVZl1btkW1pb3bJsS7ZsybbcO+4Fg23AYNMMhBoSEwKEJIZgArJssEwJTuKENBNCCKQS8qQR EiekUS3pu2ZmRxYlz/u+v9/3x/PIuva6Zk7RmXvu6XPWhBJCzOQAUUnZqs0rtmk12ibEPAPct+rS XdHH7zz1HiF0CSFa09pt6za//Xa3hRDdekKMGes2Xb62O8dzihD7IULaH1i/ZsXqf31xyw8IWZiD 62vWI8J6g+4Cwrie5KzfvOsy69TQDoQP4J6Zm7auWnHjf917ByH99+L4bZtXXLYt/vvcuwkZKEI4 umXF5jXn/dsPIjyLhbftWLNt/M0/vI7wJtzOjDiKf+zHQnQE9yEx0oIYN4mQKCkgCZJPckkWySaZ JECSpJAESTHJIRqSQYpIKakidaSExEk5CeFKE3GRStjBQ8pImCjEiXvacGcr0RIjqSY1xEfsxE/y SC0sNpVUEAfxknpiIA1kGpmCv9xMphM9mUFaSYq0scfS30fI2J1MTfzMJRvJTtj7ALmO3ELuJM+R X5CV5CDUEfIAOUq+QobI18l3yasTV/z/IMYu124mFvUUUuQmZPz98fNjR4ERrW1SzJ0IuTXRizHj jvG/fiTur2N3jjvGRnQuYuLXWpWXcLd/0tHx95UmXGkdr2Fh5XpoO/9Lf9ffN/b42EMfSsRc0kMW kcVkCRkky8kKpH81WU82wDKXkE1kM9nCQ1twbB30WoSW4axVOIvpi2dtJdvIVrKD7CK7yaX4tw16 ZzrEjm3n4d1kD/5dRi4ne8k+sp9ckf7cw2P248heHnsZjlxJrkLOXE2u4UqyiDlIDpFrkWvXkxvI jcix/xy6ceKsw+QmcjPy+VPkVvKf9C0fOnIbuY3cDl++k9xFPk3uJp+FX3yO3PuR2M/w+HvIfeR+ +Ay74tOIuZ+ru8lnUH6/TZ4gj5HHyZPclqtgNWERaZe13NLbYIP9SPPBSU8srLlnwlpXwhos3YfT 6b4M9rtm0hWXpu3IrHcQZzLrHE7nA7vLFekYaYnbkDKhL6aT2Yil4dYPpVNe8X+KZSlmdroX9pKW YTa7G3H3fCx28hmT9d3k8yiBX8AnsypTD0ILdT/Xk+Pvmzj3AX7si+RL5MvIi4cIU5JFzFHEPUQe Rtl+hBwjj+LfRT1ZiaOPka/ynBsix8kwOUFOIiefJKfICI//7449jrrjo9ecSN9reOIup8lT5Gl4 yNfIGdQ038A/GfMs4p5Lx57lZ4nwN8g3yVl+Fjv6DfjW86ihvke+T35Afki+hdAL/PM7CL1IXiI/ Jq9SK9SPyJ/wOQqQVPvqZUsHlyxeNNDfN39eb8/cObO7Z3XN7Oxob2ttaZ4xPdXUOG3qlIb6utqa 6tKS4qL8RG5OPDsS8DgddqvZZDTodVqNqlBS1BpvWx4dSiwf0iTiHR3FLBxfgYgVkyKWD0UR1fbh c4ai7LoVOPShM1M4c+1HzkyJM1MTZ1JHdCqZWlwUbY1Hh861xKMjdFFPP/QtLfGB6NB5rru51iR4 wIpALIYroq2B9S3RIbo82jrUdun6w63LW4qL6HGzqTnevMZUXESOm8yQZqih/Pi24zS/kXKh5Lc2 HFeIwcr+7JCa27pi9dDcnv7WllAsNsDjSDO/15CueUjP7xXdMIRnJjdFjxedOXzziIOsXJ60rI6v XrGkf0hdgYsOq62HD18/5EwOFcRbhgr2/i4AA64ZKoq3tA4l43iwrt6JP0CHtLmOePTwvwkePn7+ L3jqSTEr0jG6XMe/CTvIkjhhpiG6QmqCZ8MTIn2xGHuWm0ZSZCUCQwd6+kU4SlaGhkmqNDkwpCxn R87II94+duSAPDJx+fI4LNsab12e/r10fWDowMpocRFylv/mDmlycTw6pCaWr1y1nvGKNYfjLUgh bEnm9w+lWiBSK9LGbD1eVorzVyxHIjYwM/T0D5XGtw154jOEtRGBm+S2bpjXzy8Rsa1DnuYhsnxV +qqh0lZcCxdpPcwyhj0gu1e8p/80qRx//XhVNHSiEr2OAfYcQ75mZEqi9XD/6rVDkeWh1fDPtdH+ UGwoNQDzDcT71wywXIo7hgpex5/DDzKQX4W0feRseTKSPaTPNUT7lZA6wHILEdE2fMRnTMUBx5BO BFmOzpga7achIk/DX0mfwdSH7oOAmtvcgYvBuLS5IxSDc/Of/+aRQiIBeIwhw8QzafAQ2ovPJP7O f3w0cTZ7oIJo65qWSQ/4oZsiwB8wfbdPfk6F2SJtDDyCgWVnB0tDcZECHcVhw5CCdPIolouB6BCZ G+2Pr4kPxOFDqbn9LHOYrXn+ds2Ld/Us6ue5nfaS+R8KieN14tgQiXXN75cBpRk+2Jbk+cqylYfb eXgi2PGRw53ycPSwId417zD74/H0DUkUJQiZo0t0rripzlWFwtqGijLetiIedUTbDq8YGT+w8vDx VOrwttbl6xtQDA7HO1cfjs/rn4q85OX+itBe9qddpIt2zZ9RXIS6Z8bxOL2h53iK3jBvUf9pB/rg N8zvH1ao0rx8xsDxHBzrPx1F5c5jFRbLItkpURZgd+pFwMDPD51OEXKAH9XwCB5eNUIJjxMnIY6S VSOKiHPI8xTEaURciscN4AclLLAeWYB6uDW6mmXP/oH1h5cPsMJFfMhK/NIhGm8kQ0q88ThVdJYh U3zNjCFzfAaLb2LxTSJex+L18RlD1EdhnBHUSYeXx1FPweX6SYgOwDsczPuV3OjI+Pj8/ti50PmB GIrEEmBR/5AxiXZAmzsT57UzLEd0+9CBVSvYc5A+FHVWMjtXDaAsyBvilM4hI+5gTN8BZ7Txa5g7 4qJVyBtkIL/+AAJDBwaGBpLsj/ZvYE8UjTqGSEe8Adku7qlNsD9UOnDYFa9gjo1Th0y51zMy4tnI vH4RE0IQfwwVLkuR3oInXxXHoVXLo8gBDVk1D64u6lITyzfErEGVqEms4TCF0gcJS5aaa7aahowl uCF+mTaX4Ib41Q/AKCzxPHR9+gT8bceQGU+UmGTK9AWwDg51smfB7/V4eHbq19ltekZIb/wyVI3s ofmf0uPwkDW3cwUqf3G9GTHxOnkx7mXIZVHsHmdFrJ6l3AK7q7nzR8Yfil/OagD5U1wUZ40Dc0wS Og3HJgOHPxoxtDhZXGT4aKyVRx8+bLB+8gXCXgbrBLO7RFvR1uBPaTFK3Km+hBGVivFjPekms8ni Z4iV9mLI2UCfeMLb0mIo1n+NNhOFROl8DDkpbU7ZNYr1VEZGU/xUte4W1dk5QotPNulvURTSNPra 6Aulo6+dd9WXnqelv/rNa79x/P0FZ31p5W9e/k15GXXGnBwem6LXe3Tx7BKlOi9RU1lZ0ahUVyXi 2TaFx1XV1DaqlRVhRcWZIqZRYWGqvnRhkTpnVKdcGW9aUKkNZ9g9Vp1WyQy4iqfmOuYtzp1akqVX 9TpVa9Dn187I7trUmv1zvTPL68tyGQyuLJ83y6kf/YXW9v4/tLYPmjWbPrhL1U1Z0pSjftZkUDQ6 3Ug4ECycEutcYHc7NGa3w+kz6F1OS37LktHrvJnsHpler7jXaDdsqJD4+PuaK7UejPYT5POnSc74 GyctDjorPpIWiZHxt06aEWOWwgSRymBRuQ72aeWfFv6Zyqe57HCRmXbnxBO5/7KYLYHsrLjJSn0a C7E4LMrj8efiP4yrcUvc4srqdfVp+0hTU5Orvr60dHDQ6a93QjorHecrnJWweXIwyX9IMpnr8+m4 0fPUmGpT49mJRE0tFZb26+NqTLPbQB25kUiu26jZOvqHjarJHc/MyrVTAx3WWIN54Whhhk2zj/6a fmOaL2TTqHqLkU4Z+67RatRobSGfZthsM6iqwW6+ZXQfgVc9SoiGwr/CmAWpI99JZUQCDtodcdjZ hxUfAQs+okhrZEQpSeVneFM47k3huNdrLmInF7GTi9jJRezkInZy0VNKBUb5Z56AJolKWPoEzgS/ dQInc8b54LdP4BJ+HGdWjiiOlPUB8xmzYs7I+1d5uT5nhBqHHT1VI9R8XD+fNJ1v4p5bT0sHf8ON VvFyUgg4dDJZLzSM6rFp4rHsRLWzqqYyBr/0Mo8Oq7SqRInHncyd3Relhkbq5qza3jn2mL+gwE8T u+5aVeFLTi+sXtKaPzaaUbdo5vDZ5t6a4Ozc9kt6Xnh/Sn9zgu6ctq63sdAbydNckxcpmr+3u2R+ e53LVN27RaGls6ozxwbjU+aM/qqhf2pkrC6zthet14rxtzQWbRjleOWJTDIlmbYKmFsF/JcTsAr4 r8wq/DiskvyaUon5pgAtxVxUghYNu+dpnqaFmHgqoyXHjQtQqF8+z0BLRfIdr5wtL8v12ETxreIF U8cMwAoqK8JeTxiFVRRYjUXRGjypZfs6r/z+rd3z7v7RVXUbF7WFDFpVYzAbbBVzts9ZcMvq2upV ty3u3tlTZdebdOopR8Bl8xTkheZ/6e+f/8KFx5d4o4UhmzvD5cl0G/NK81qv+/r+fc9eNT1RmtA5 w7wMMj+7FX7mwgzcnlRWU4y6me+4me+4PUi124UkuwNIr/tp5jskQ/hMRto6nHEemPsM+I0TODvj acWJWbgAtQzbekIjNHFcK/xEWuNl6RODcArlQ06hn+QCty748ltHx/7KHSD34Tc+3/NE1dZHrnv8 +P5HdtQr9zz8wZd7RVYv/OIbRzY8cWjmBWfjga/jMZGvSJu6H2krIpcez8hL5yqY5ypnPDeYPzc/ jufOG1GcKaPRHXVH8fgZI9SQsh5I0DMJ+mKCJhK64AhSZO3JAx3XTXj+4PYdyOZSXpU4RMIqeF5/ OGE8s2NO6fhxIdX9GpPVMHonS6Oy1mA1aLX4GNPRYQOqB40RerZCDVaTpt0VchlEeg2ukMcVchrG NhodmW5XhkM/Vm5whni6x99X5yPdeWTJcb07nW4wTzdnlq/pdPPjLHeR7iesWSScpUfSTrjdQd0I zT+R3RNklWS6XSo960wXZaROZNvkxMg2RxZudT4Sph+D9fR4eK5TBk80I5DtMSCpbTz2rDsTqejQ O0Jed8hpHP293qrXavGheSwvgoYnnZdoK+airSglIyebymnckk4WmCeLM5IF5tnJjyNZFpadmf4c M/NqM/NqM6sRzSZ4tZl5tZnVbX6S8qJCTLnZh8NJZ5EUjhP/yPiZEzjA+Ekc8xf2ouIrStnPWOiL Fmr5cCtSOrj9fBNFbfcyqwHTTnDRGQZR8kWTjMZ8QopaQPEiTkrNXIMnFsiIegyjJ6CCzFoGT3Yg GPMYlG5uP6gMg4WZyWJQGke/IbXm51KNvq/opE77BO2H/bxk7qkm/xz/436VpE0I5ibkDNuAuQn5 cViIPIWSbBo/cwqWMDl6eaOJZE4U34vpkimg/fK5jd6Ynz33xNNefEKRr/rxv9Lf4bnyCYbcRFQt /1cPlIUHctLuLFu81/g0rcA0eQC1rjZd66IsTjwg99PsEl11+vF4n2nC2vR3mS1bezNrS7LNeq2i om41BOMlkeyyqEMkwm2kbd0HFpUb7U6LxRl0+dAPsrvszpKe6ep9sL9GAztP1DddSEsG6ThNvCIt 3rRxOcO4YG5cMK8mvfDPk8Ro7/WO0GS6QqGl56RxuW1FeymaBTgK6911oVYwjp71F0jHoC+yrkSX J+Q2on54TGb9B18wOjPT+a9Lok6YSh5NOZY3bmtUrGVl/tJSU0kgwKtsFA9elaOEcMazgvmz8uNw hAxWlsI55RaLiZUmEytNJlaaTKw0mVhpMjFfQf8iFWSOk1PTYw74raWB8hJdJL8n0ie7XE0udLYq UVhkLwE9LllSnJXO+mmllZWsDzapzMQp63eVKHk0Pqn0sB5wWPHTStYZY9KrSxo8kaA/5jYoY5Wq 2Zvl8YY9ZmWsnaLkBANRt74otD5alhMw0j1aep05I5IIbraH3JaLLrrug7v0Jr2qQZOKbu4RaUvN 0cIcS0Z+6MJC9Wi4MGg2urO8It95P9aJNaVrT+TZ7Z50ueIME3GGlcBvsf4DD8M8Hm7OsKmkpIKZ syKAcysCOLHCgbMqmDkr2CkOEq7rNZXY8zRBVhuzRgedVn89M1+6lrlovVJYjTuNsFUikRf3+byf YLGw6q9MsH5Y2q80V1q9GdbajLx43Du2Pjo9U1EUgzsSCERchqKM3qy8SJaTNmTVVJQHKBojdyTo i7oM7R707M1ZFXnK6/VXTOm4e+aFf05U34/kZ5v8BZHR71StWj5YOufYHOVr6PWiPePFBf3/VePn NW9oYyi6eWR/KsPDrOBhTuVhHQ8P63h4mBVgqMqUMYpVvgPoGYfT5gXzagvMu2dg3j3jx3FV+Gl0 z0wkSAuG7fPirHSxygEd1YkOSLqrmm7J2JAqbQze/5jUH9O8MfPO1+664yc3tcy867W7bn35ltYn 8hZ/dtu2zy4rSCz6zI7t9yzNV+7+/IXjyxYeffuBI+8/vmzBl//5lS3P3jR7/s1Pr9tx5qbu+bc+ g/Q+inb5eZTBTKx0XnY8R5dOCJgnhDMSDubFjh9HQnTMCfzOLGaeLGaeLIfFSmdlsf581ohSMUyc uSPUdEKnsyCZ5hPeHsukJlu4iCxc6bR+uAihRtFM6nKpz6f2fPWyO43uWJBV3YUZ1FvYvWHzrIIn piwcLLr/c7PXteWod664d8vUsZKJsoHM1vublly+cM7GKtvoe/ntq1j9zvJ4uvZ65HEe1ls/lcoy xVz5LB35LB35LJvzWTbns2zOR1pSJhLNLMs8kKlmVqTNA+bmAfN8BvN85sdxGcpI5UlXzGQtHqEF J/3zcjW1LLOtLLNfPsd6LhiViHLy8uBZIRBXXqZNN8J5YmgnM1+MSLR8RDLJB5AKk0XnGdh1qLH8 7lXSF2768a0d7oLGws4tHfkew9ijH3WLHf6IUxdrWjQ1XLTg6DsP3PMe841/fL7nrkPbiqc2Z9vd ceX1Lc/cNHveLU+t3/HczXCUZ4Xd4CsaM3ylBqvUt6fCjhJnrQGJrWV2q+X5X8vsWMsMVwsLnCpg 47+CJiezFhRnnMsZZgZzpwLzdscJpxrOLHGgf/vkthRNpfzT4DtPxHr86VEx6/ENnp8w3aTxHEwn m/w8tUTFsO1ib4YN6nz+sJoe1vndPh+tSuQlEunBncas8+SEM2Ies2aPt7hx/pSd0s0wvnOXT8/o 2jk7Lz5jSX20qjjfs8tmGBttmRtsqrz94ZZVMyKootHcGlE9llctbIqP/mzC/dBV1KrWugVbm6ev m9PgsSWnzi4f+21OlnrtrA1+vW5sVmzKXF5Xt4+fV1fBHzvJH0+T6ZhosGMaYTozGozEGcbjDLcE c2NNH1GKUsmKlNtDZ1Wk0OvIqcipsIQC7NoQawBDDlwVYtV2iGVI6CmlnLWCJ0K8N3XmRDDNHsFP 2lkX01LyNGVbE0w0kTI7o7W0NmW20FnIoTMpE1O1zlqnbyp6409MD2kL5vng3+k6DP573smmLZLJ Qcd5B6q0SX1OPgiRHdCJyk0j/VtMGU10hz46ANWpq5r3fGFw+taFU/xmdG0Mtsq522fWDTbnVPRu 2LK+t3LKhtvnJxd2T3XrNIqqM+vNpS2DDTVzqzIq5m3csnFeJb1k8acwTI9mB3IjmDvSZ+fHw7Vz K2tnTymvbJy/fU7PVQuK7cGI2+wMuF0Yl2bGs7LKZuTWzJ5aUTlt3naM2+yoJ1+F72eTNacCKZg3 4ESX8MxJKMIrRRibV5bwb844AP5wpck6Ik5MdOCYU+diQ5msdL1Ygc7r3/kkxbeSjrPJtIUm9clj singXa1X+QDsLtmjHbtLDtDUQ3x4xscvH9w34YorDc5Mt1tMdLGyTMkjaOcuR78wSY6kspYX0ygr uVFWkqPMeaKs9xRlfhNlYxHn5LEIfI340hUhmFeEnHEdmCeZH8fVvqcUB+unsxELJsrOpIwYspgS vY5eDL+l5/ABSro2nBiloKOV7iQrFzsEzvRkxMUYzeWtB0Z2XzJ0ZYsYxLkNRfN2d3bt7kGXC8OU GHrKr116+sCMxsuf3KPGpUEu/GPRdZj5779moeqXccIu2ajj1sMuOWRLKiuHVW/5OTSDcSKD5mO+ x0qLgrQoQIOwAC+oXLDGLyBjmEi5WFQwEAwkciO9Aa1LjFFc9U1OFxWlJIlsJoODdHBwENN6ubwr qcnDeL6mZlIHsgLTfHrllMYWzMvyxQJOi14dGzBQV352Zsxl1NCdlG5QDajAIjlW1RBmU3ZUo8WQ QTPMJ/UwRP/gOU0Ti2eTeizvp42/r3sdaZxK1p1ITKVotN5NNbPCnQs3NDCRX0oxmclicml2gImC bBqIMlFcTovLaHEOLY7T2t7C3niZWZ08cYk+YBPyDj9ssjL9TySO9ZP5TCXrMX80mRM9Zp5g7UGN I7MgHElm2jRjf1feV20ZBdFYUaZdHXtER52JaCTHrVdonFKPavTkhjNjHqNKCxSaperc8axw3EG1 CZuT9eycNvVHF0ql1hzzY9JTNdjMH5zVNJjtbKhkN3/wbc0UE7TWluEXfhDm/SIPdnsN/L+NAS1w dj8f859JwQW6Lbm9IZ2rV8e6P8h9NhYXro4yfrGRumgOtE7+ypqaWjebyeV53ynGU17D2B1mrT0v Fs71mbUnghUZir88eFI1u7MzcgocWjN9Z2zCwemvlJ+zhGownTF2c/WuKfXba+mlJpueJdGHPtAS tDlN6vewVy1FhlJR+4zIjNIZqtnor7Kg5FexOqCKFf8qB2tQMKf6TgqTN3l2Qi2E1RKkgZV8nAp+ g7VTnHEBY14uGkYUQ8rj9H+LVDmqlClnqiipolVVJdMLR2goZX8xm2Zna7LeLJk57ZeWbg0pTc/X Dp7HjDemLZYOyk7x2eTSwfpS0VusQEO/FCMw1j3CSKF6UjepsprN0E0sOjRq+NBLL+YwfZUVNbVq kyMzlBGxTbm9p31nT3Hjroc37PeVz66ftqKz3GLAMEAfmrFgbdWKG+YnvnRLy+oZkYG507dOC1gs 6MVaFjW15batnT5r28zctqq51aGseJbBEbQHszLiWe6ivivnn/UXNxW0zZvRAgdSyBHY9yfa7fAf jMCeaGqiplhNum4E85YdzFtyFuYWqxmh76ZC3iTrfSajsGmS5UCS1cxJZvPkiGJKGYnXVFMd02jL Rqj2ycTMUJtjVj3kcW03G0mwaTE/ekjpUdhFq03UpnlydvdiJeoUqwZyiKF3+mCvRkX9SeWq2waT nW1teZjZ82JYpdO7o4Egxlj5XR0d+StvWpj/mLdqQSramGrNa9nf3NhfG6R/3P30oTZnoqFgC2pW OKDFoK3jfSR8jP6+oC7umH1waHfrNaunuQpnVIwdmbdw6iosL6BeWgSbRdXvYrL6xuOZrHVlnUbw 68y/wG+chDkInxTFAT5ZCquAed/74mTp+JvsAkyamlPWUhu1Bf8YSZmsHRHMkykn3TPVP5ezltto 7SgvGqG640YYbvTlJJsWT8Ln0iOws2iJxHTpR6bGeTCejT7KxYlxNapo9cGpXf2lK+5eUz19+5GB ZE9LdcCoU1xWe97UvoY9V8VSg1PrFzQlLWwY/6Az6LQGc7NcqX0ndl/73N4pjozsgM0dcOVFYvmx U48tPNifzEnGDW7MNCpkOexyL/ZeJrAacFMq0jSFmkP1rITWs1a6nvXz6pl/1DN3qX+avgdrlgqr lTIfw3Ewb6c54yIej7NLmUuZ3LE2c31eSGND0dQOB2aiuGtO2Lq1s9gsK3co1FvpBloQK4cXJ0Im F0N0tSfG7yr62JOGK7XqvXpnpoctvLUfWbzq5oX5FStvXzbnYErviTCvMh5tvqKlCT4En5oem5Zq ywtKF9rTvaD74PGVu54+1N7arJjleH60Fd6zcn+q5Zo18KZmdHCZvQZhryOo25LYJfNYqrC0pqlm a43qZiXKHYWd3O5YEesXFzF7icUoXsvBG957oiX5paTCllmeYCWuSpN2PzD3Mh7GZWBRzWmYBWOx oucPaG7TKGc09EUN1WgyS3+ZmBl4c7ltm02xGd/M5C42KFakxLw8t2PFr5LC3fiKFO/y6OKxSY6F sjrZ/RRvXg03qV49khccHQ63betJre4stejNOlVR9eaaBdtTWx/a0TB1+wOrNn56efFR9fI905Y0 ZmPiJC/WddmCEm+GV28Luqxuu8UcDLgb947s3XX66taWnZ/rd19zV8msNbXMhpTkYi/uddrL0EdY PexzsELIC18oXXcx5nUWBO/wgXllhm7de8NlhVj1fDHlYrPWuabzNe0ZifNlHdFZjg42TXS+gs13 JM9W8g7v2WQlVqBkV4+7i5fX3FhRnjSKQ3XPBwuo5fnkkEa5Dr0cnd4bLgjlVkVt3zWYjVqX/bsG VFCYUDNc5XCwgcJV8Y7NM+Mzcizo/djdfpvWaDYGKnsaVuqdGe6c6IU/s44SW7xSvdEcd4ZTP7j0 +gUFVrvFjVULtuZZPXaneqP6HdKI1fRl5MWU11XczspauwEO1B51uOms9som9KBYWwjmpQz8+pPs UJN+DmTKanfRWXNCGnuZWqnXM49CkYTFzqSsEMWV+lBIX1msYVZOVcG5SD/7E/1RBy7rL8xNmcG5 9jK9Wjfz55Z5b3i9y+vUP03tKIzO+FndzMU/i85JL3Y28bbz/CuiCUhWnksmzyb9GJKxQZkT7YLj XBK/SfnB7A4rYzKOj5YTmHXwenz+9FhZLtXXoqHFGj77ZKb3+TGcxgB6omFly6OJvDwbBtii2bjR bb86nlkxeGB27aqQyz+95s/N23pLqi45un3zkZVFjlh5tLy0IjeSU7Xk6lkF7RHqcDrHxtYMlrWX +tcsLu8o9c9b1vOnaEHAeOjSrjWNIXVXPJKzsHT2ZfOKsnyuknC8RDEpsWkDUxq39ZXnpgaqYo11 lcHgrKJpyxO5gzO6984vNhpiY39fsi5a15k/sDZS2zG6tKFJMQSLC/K905uzyhqFjx9BH+8BtNEV 5PKTTVW08OKyU9q5J61H8RbbzRpof1gs1LAKWKzW8MrDzI6ZxBoNZmIxiaE7VTwzpy04i1ejrF1G s5xeARDN8ofqUCfvvej0F/uEchbUKcYDXvUBg0u0voGSzrLG/S0I8slj2Si339a5aN+sWFD6tGLv XtqS0983epOMmdwSd3VOW3vjClZfXjv+Pu3RlmIdJkZuPtUUnxPfGld9rEAjieCLIzoM3hDm7guW Iz9e8H1PK9sxi+gVfZuPLymkTYolhXefNEXYnoDICG08GXR0cvu8cj6ZbmLSPRcMji42MBMtipvt M2HuCD+kjR81gLtoSkOSYcIE6iG5GkLLGgoL6oGLeb8feV9FPp2yNNXQgnJannLRbnQNXuQVGwTv d4DfZGWbh1E2y59W8jALYEmn5z+v8cEdMnzFxYQlVbiFL9usze/MbHNKl+DTgOhooHfL68KK1/kU ABs+TcxmTRokTDhEepeH16PTU+rzqfsNGAOE4gG7buzQR21C5xtcQSzUZXuNVvvYU3SL1cynrFS9 1Uj/MWb9uGtceAkjBatRRXNitAQcY0+N5TqxqEDRp32fNsJmXpLi63Vb+XodLxmouriXsF4aW2kH i/aBIL9PmhxtPJPTOfyJOfvx3JzIxIteO5F32hfRvs8lb6ZCLgf+HN8LkOAj1jw+XN3WS9smlV7+ TAjzaUjOyBQw7yjyUh0O++Ds4XCFWDdihVssHvHCbUKrdmoum2Wb24h+Jk/qpP4mvy3CvEBwxuV5 T9N32es9VDfcNRNdT13KOn1mY1txXWfxrIlKAR4wefq/Pr32hE1W6VEiqyOw2QfbfS5OaLJhzocq io9FpNdPvOmZBNG992pfFBWI2+Apaimp39nKGkusSul9Rc0l9bsm6hOdK9Pvy3LoZ93aWTfQUuYo 7ulqz1l4aWdkIkeUeP1HapaPx2AqygwnMpoNe/rmZJROzy9vKXSjypmFTOS+pD6APKwgd6XsIg9Z Rqar4Y/mU7r2FYZHvqXzkw2XwmbW/xUL6KzVnLyKTt89la6QWXWcMhXPLAzmdErjYzSOfog0dHo1 Im3v/87aHzbuf66WJ8z4me7/Q7X8IVPBRMuZnyt8PPQabMTWoh5OZTYV0HwXLXCyOaiEhSYMNKGn hXzWg68vwQxg7oNgXnmBP7z+xDqr4VITNU1a2GL94kkLW08pJjZPfMpOurcho7C3hA7bZ2IVR0kP MdkYKe2dcrDEaqz0j+zJyaldOaiUwyX1tYadX92x9ctbaup3ProTXPtYqHHjnM4NLbFQ08Y5HRtb ovT3W05f1zXjypM7wDPB+zuvWVlfteya7pnXrKivWnoNbHNk7C71J7ANG18fYOPrWA3biMdaLDAv oCzMq3II7jAoxWi+vWJozQfZfLZcjLI/cWzd6ZjzH8fWnzS0/njj7f3PQ+s7lua3TE/lyAob7uLx hlz6glndPcUrD7OhdSUfWrfltextbhyozaB/uvSZg+2O7Kr4WKMcUWv+hAKGTXpm4+WFjQXeWYce 39169eqp7oLm8rF7sC979X7hS8thr3vT9rouFYLBIuYkq+WSbAwpTMCruiQbPxbiTQPuOJVphwLz uhIsd+dxk2IXHsaP3txO87RkROMoYePHjJl1bPzo6NaiX/rJ40c+fJzwFMzQyb4mn/iUruP9+PjR yHpAEY++YGZHZx4zUsWq25flt7W2F7KtnJ5Mp/5jY8ixk9JW9FxBfdwux5HO3CkFm6Xxxv4tBpJi WoIPJHkdpTwEm1WSVSe3VdOEPe1YYJ54sHAwJpjn2ZmDudJbdtg0OStaJAN+l5syJmcm7N5op5cN qnm1T0vZHAMfB7JaR5qD9as/oRcoHEmnPKTojAaDPyvHGyyrbohP8h5eZ+dOb6jPssZysiwalaor fWGn0Wg0eEpm1Y4Oyab+YnVzsKYlz64aTCajjY93KOkZP6+8gDR3khdSltKupq45XVd1Pd6lnbQc xQsXD6O6BZ85gW4hD6MG4oyKfPoI/WUqItakmJuFmJull6RwOMSq6tBT9G2+McOEALGkEI/u1JlU AvdrsjxuUSwlv6o1/dk517ncuc2piqWnX7B1p5m+N8R0FwwpFp3SS07YHiu3b+BQaXrSgvUl0+b9 v15yUl6oXHrN7LKFrWU+k4YtKSWbFtQVtlSE8lJz+3pSeQW9+3pzOhoKvHoVPSWTzphd01lamCrw 5qd6++al8qitdRNy3B/05ETc2AkXioZc8ZrcRFV+JDvZuGBq9YrOIovL67DYfQ5n0KH3BX3ueFlm XnV+NLtw6nzWRsbG/6Zs1nwVbwYvOVlAnPHidGHkDJuCeV6AeaHkDCNi0fndlMVvLT4f78iynvd3 lKM8Htfz+cHzWH2m2MHNO5oV586KKS4NL3/Ojw6yFe/koTgf3LECqmw2OKIFJf621amsK+0utjHw CjkG+SObR3XZ/1jb7s/J9Bi0Rq1mcVa2w2bU5WIZVbGJUfYrctPFK2IcPmYaXGY0GbW2AEv3XWy+ S30GfYM7MNtVRc15zIPymAflsZWYPF5R5bH+ArY8vvckYR0zEkkXQjC3CvhdXv0zwfqk7AQZ8ZaI oO9hQaq4M8+sDXaii6a9OOnFSqic85pwqQ8N2OSk18TYRCxO1dRORGC6y5Xl9Wc5dd138y6A3iMm J/ylHWWN+1ox7YXxm8s40a3a0zd76robVyrZsuc0+q85y5pz+/uU3TKG2QdrVOo+2KeI/PY0Nqyj TWMLMxG+cpMboWEhwpQP0ZBwvs8LLDf5yA6UK12POWGYVC1OqEXfwknzHDRfS7PzETEtm+Zk0xiT 2IWbE6NRHhulOVGaZ6eXxmiMTfQYnd6OWBSlFqE3UkZUAzE2z8ZCbOgEfitlwT1i+Z0xc0anWVSB fC0EfkiSg7z/kGTrYINJth6W3uXOVo+SrODqJzZaXdwQ43f7xSIJtp7to4qqjJ3TWDPyw+H8INaM XtBo2YYgf1Ycu9/HNOoHCmY5Q/6wU6/erzGaLPoLX2FLYhqDzaQutLiMKmYasdPOYhzNsFiUPxgx YaQY2JcDwN7V4+9rD8HereS106QdFdQ0JA5z2tjbUEdrGeeW0ESMJqI0EaGJME1k0bxMmq+hBSpt mEKnNNApxXRqEV5mxDKoIz2AZoxpaUREcQcH2hA+rmbMF47sLNo+vZOfx8zZ5Jjj2Oq4yqFxpFy+ DkdlZ25nw21FtIgdK2L1psPt61hXtKdIaUWsf5aRmfknzJaDZ5uazsGWwuKYC0ovPYrFR9FxE6bG gDK9pU3N009aq5NN8iSjT5LaQxrt2Duq1Z8fjhQGLeqzivK4as3A+l0eQmPvaTUYafgzs10G9WeK 8rxidMHxsYdLeVWhryjYbZERwAZG9X69x34xW5RbjMbRnRczye7RG83II4xbRzOMRuSRFVUvhvej ARlSDOi6UlKA8tGF/ColV6ec0XK2pkm7S1h1MaWEYnH2rSchqwIUW2h5xcDKCY/yUSNz1UIcJuya qYTWxWmNmZqjbIzBMsRsLi8r6IybnVmdchjPqgq2qAu7phd0YXH2yz5yfXytCiue6sWXNCat9k0s 81G12eDOi4TjXrPmp69qzN5svKvhpEYaGHvHQN150ay4x6Q596LG5IyEsnJdinHsvSKb26LFMF1P 14x9DqRqLW4bPUUfsrmtGlVn0o8dp3NAqsbssY8t5XUH+oH7YZsc0nuahJDYaqSzNkQLQjTApsMT AZqw1diUPCPNYA1yQwYN1oGnBGmkM2hyd5q6NHNIF5vHZcuZKLhIpljCHkzGVLEeV+vGHj+aqJpY yHbziUOfR69UXqYrr8iIOhXdfqNDHXvO4MgJh7M9Ri2l6rs6Z3Y0M8epG3vC4dRaPDZar3GZ1CXe gE2L11CsoyXKK26zFq2Ei5fLAQySXsX3USTJlNPEgbT42Jp7gu9EKoUfVBlbjIox14mhy4lghx1t BYYweHQ2AY2V7sFzqHfSA2u2nZX5eC1lik208P3wfMsQZVJ5VWewGUZf8YZYlUFvGbvK4Wb7XRWN GUvyLG5sNz2KzRe6NuwY12fGsm0+X9ChbIzlYke8XmfzOaO2gD/DMXo3dpWLeqVw7DW6k7yO7w0x DZv9mcTx8jmxjUmvF4Ww1i3LHd2ps/mdN2qt7qDb6TdRzbXmQE5GMMdvvjVSVVIcfEFvwigAhYG6 D4SiDp3OEWV/QyFPj79Db1E/zceQoeME2xb3nTKF4xgD2zEZf67pHOsMyI3zco8J0jsxkklPOtFb jMH8SDQfZS2QH43kB40fDavRaFHIbA4VRbOLGReP5sdEBN4hRKWagZfUKPkMnmcL0mwm/uNs48yZ J1GodEYVdRUeJfl1ZoBJU3xbShunljBsbi8taQXYPQrV3XQn1iZCxAi7teNKsYDw/2I2bSJSWVoc eEGP/RT8xSf3VRlRl07nStvtBnWPWsL/Ri2xntRl+yrwdyrPMUtNrJ8yf0m/2qb/hFgf8/ejZn88 EMj2mXVWv+N6rcUVdDl8Jqod83/CARR9TfuV6efICFciY88ZTHr2ZpZh7Px/OCDyOanuUX408bzm PH/lxPOy9pM7VCJRddGjtBPRJcrFWOVH7Dlv0FhdAZfDa1YPmfzxoD/uM4/dM+kAEqDhR1jCtHkR PGjgnMGMB0UDSp2wpFOnc0Yz/tMB5GErPamUKNPw/S62k0RvPo8NAOiX8ozECpiY4uXlrsTlHFvq wg99EKVLS9/LC0cSibDOmYGE0/G36XmNolyJ+ziHcZ/TNBOvmX7yrTSK232hye1yudWvG+1GrYKl NLyTFzeyN1TYvd4bu1NDxgP4rh77E0Rv+hMqOtZZ/uhD+TTE4bwwzelyOdVvOpxjr8Sj4Xh2dpTd g1w79hD9p/YmfB9QdsqrsjZHZUMdlVdKqjdivpY0laLM8SaY6vB6lcs/8SJficrrIDFlQP+2bHDZ Yi21ZQVdGW6LWtNblxmp762keLfG5890KNqV3x0beOXVsUXftzjNWrxaoV37o5/+avv2X/7spXV4 9xH1P961Zs+0F8/0RzxTjFSeJi4MVfFU6PvxmSLGT7Bq04Up2zOsFcR4VTxjskI8JHMUVh+x9wtr XNVVSl5CTIH5fS76x8y6nhrVgve5MrKsVLtk6dKlGsWR6ffiBRpl3W4luP1XP/3RWqzUKVpUlN+j D736Cn3ou0YH3gzT6TTnxubg+W5S19J67W7MKxuHtY6L5ZkPStR0BaSn2Xp7wOUK2vR+E97gCMS8 RqpeNzG2/yFTKvptLM0KXtxk+/U8ZADfDlSfyprbu2Ba568XVesWVekX/zpc6Awvwr+c5t6cPv/F Fy6dlexFS+z754TGjQ8a42wjDi/0cvdSrVu8cclKzsSYSShs/udNOnb9q7G00rMbaBHEE6HTcjB/ l92tM1j11xZSHUzlDzt0tHDszUJFa8/0B1iogJ9hMVxXcLnd7bbfUED1zrA/kGnXFFJfHjU4wgF/ lk1L83fa3aPH87EZWr3UGbDrx06Gszk/wnoDvGewYGySzmJHDXRWOBoP0+k4B/szzLqxr03WkeVj JykmaRVyCcZhz2qjWCPpIEdOk5noYvrtSvfymTS5u4mubaLNTbSqieY00aYRpTnlsWRmWvZW043V tKuaNlTTZDWtxoEnMY0YRTazDi6KAlsiOIXbkDK8rTQy/n7KhIClYbysTJvAa/zD7oGWEeo9rl2W XtRkhTk5iL2kg4O/4V1VrJU7hEJtjM4H/BOewgb2bMvPh/aO6j8y+5ZeWVefrdp0dHvP/iXTch2u kjl7jm7JnZUqwuYohWLNw5yo6a4cvK6vQM2Y3r2gfMNtA4nH/DWLZuTObG3KiDUtbUotbcyiX+y7 //LO/JmbDn9p6bxH7rtp3VSj3WW22t02vPZmsDltsw58ZYk9HLDXr7lxecOyGTlWf8R19WMbist6 1rB15V7Y9im+B72WtNNrTpMaNjjFenkNCuRJViCrmWAxXLCYKhnDBYvh03MY/HKGbTtZGWZZ1EnL 5H24YJu4Jse8zuqAshElmAp68nndhN3vOCet2TZ+bH0PpDLC9ngYqcDgkX+EPWFTHT+/jg38vFkY CPEL05HswrqnlGZM67x8gmXyxUw/cyK90zi9q+cMmzFjlQ7fWDADj5sysTTNKMNNWZCP1bng0exO uPsM5mpOE+ubmqqnaYtHgwOtoxPOgiXW9NQ033ycnl5L8rmgJCMxays+mffwtRU2IEq7EX/folZU xGIbAmq/sKqK1Vk2ie2vqWGvA8v17hr1qanbj16y+r4tDfldW1qnLknFylcdWbvy1sEituWnfWtX 3k+z6uZVb9oaql84dc2mwuzWdS1Ny6ZFrj104CCdNf/gopLC3su6p61d0JUdae1ZUtOyp7+ytGdL U+XS+Z3R+My+Zcqywpay4Mq+vOap9ZGqK0cfLOmaPi0WaZzRWbRi4yUopx3wpef5OytJrIgFP7JI kCsXCTA9dCaVy7yjmE6a/mfrXh42t+Jhmedhr2V7nlbYNwpExbRSFHnBCi6YzwGD+QQL+A3We8Nc ADYJF6eMJvY6TIqobOI9ZcQVpaY5JoXwGQKE8G4WdwjsJGfCRPC9RdguYsKrMOxdEfkqzMX9sRha oKCzzEmmV2fYRB7qAfEzOcdYVmGlAfNYE28sa9TnSzcPXb33obXJsk1DB/aBh2yh5NTusr6N03zh 6Ws66vqmoT+rHP7028dXLPzKOw/c9Q7nR1fcc2lfbXDuzc9suv37BxpympfuuBbWoGQHCu69sHMj 1qysBTU0GaYFWWy8n2KW5VVjivrYdj0fLyI+ZlAfTPNkZS7+kXo2H4Kj9U8pVxEz5k1hPDPcOmWG dczOuvpotB4GKXmy0qcrmefAykO+ePuugk0YY56TvcsLB4eHn2OTm9wo3In5JmK+ZiX3ibOpkY9s iNRN+LOebyK/V4te0Gi1zWvXqya75YOFG+pdmdVzq/h2SNY24GXvwJSBS6YsvWWwxNd+3dZzSiX2 ympnsh3yekfY5wn7/VZqWnLHZSuTye6G7Oz8bIMr7MWEps2bEw9UL9nb2rjv1sd3vGJ0oYdFyTr4 6R2wXz/Vnsbi1plUJnPGRbTcAKOUs25SObdbObNb+YhSnTLNnpeYPTuAmSWY+I1UAqck2HRHCrGJ lGoLsSvFXDK/MsSuxMYaPqwPwfJP8HE8XBCbteBztnR1BOYuDT6TciMbbFNSuO0UNvEyq3QKxYzY GebyjEWtNMU5xenDBk1zytQ5r+if0ai2k738YJ54+aH0fL1j4v0HVCdslgV1kJhoxdYbvgcHm3DS NdCklkvHtzOE+Vv2PMsmFkPSr0VM3tV6MRO9qJXuaNz1yCXTt/c32A061WY1Vs/b2jJjdUt2ct7l 3fuQV3qd2WbcPmNDZ15GVU91w4pZFSbWMUBf0d3QtzW16IbFxdHGRVOat84tpjsGbl1b682K2Gye LG9OZjQ3mt3YV1Hbn8rWOzK87qBdn50aqM3vrInE8+Nae8hn9zttbuRzyfzd7dM29NSbFX31XFYf laHv9WP0vQrxvZgfpBrY5FgxzSuiOXk0J0FzM2kiROMZNCdIcwM0F3vqfTThpQkPTTiwyEJztDRH Q5Mh1oSdSbmYj2DDuS8A4WPzMJiu4R0JxqeQd77MErwzNH4hlYUzHKz4OZgvOdiksYNVbA7WDXew d//ziEa0S9i+9yIrfmw7X8qEwxpNWWleCOtXyGBNMuZwmGK9JrFnG6WukvUKxRRPMj13nkQ3kW2l YptE0YzwEihrpokKCpurJgbSzomiKbdv4KslfNjCHlN/7HHdId8EHX3T4rCiN2/S05e07nBROFYe dtzh9I59QRlbTB+i22KJsbfkSg516NAVdIeDfqvqQgcYX5RiNV74dlz502gDqiyUuTUoc3fjvZVG 8vWUNa+W5tXwhWOV11m8q5Citel6CYzvNkEJqGUvquTD+PkwZj4rGfm2ORVbK66qUCs++ZW/p/Be I3tTmhUy5BrbO4llMKhTrFfhdgdQdIpSlqKGf0Wzse9bW9QT+FDhGcQLQ2zTA3W8ki4zZwdfFsVH mJfZN13ho7yI8cfF4sFnDOQb/tgWgy8xEHNP6t1tB45vmrppfo0dXyyDZVK9qbB9Q0fztp6SvJ79 C6b1JzIDkSxlmsFu0npcY1nxzrKtR7fW0wfWP7i1wRkM2CzODJcTX2mAfd7RlnUzG5c1RSwZuYo9 FjWiGszJH/u0VqlecRiJH5f9ZUUHa7Nwuo+HMPs2XAoohPy+Zq91mX3qv0mQj1TI83PueINlFePx t8d24s2MmxA0snP5D67T3zf6c0JMsy+Uj91sfJLfKX2QU7vGhtv/EN+a8QUS1ywij2payArNX8ij 6hvAVxG+QB5VNMAtRK8Okkd1r5JHtYXALLJKkw1eCe7n57arfyB2bTZ5RHOYZOvDZBrCYfUnZImm ihxRV5JF4OXqB2QQu71y1bOkmsXTV8i16hc5H9GtJkdYnKaOn8v0cuV7uDZGepTHSAzhu9TPk2zt CKlW95AC9X6SrRaQATpOCpUc8rSiJZ9hWh0gNwBJZSdpVS+Mvw28p2wm1wJ76VmMGS+QHKT7EqAX 6AB2AOuAMmANwI/BQg+SB2kZ/YOyWnlJna2OaPo1X9KatP06ne5BfYb+LkOZ4ZfGx0w+04Nmj/mo xWf5tnW59S+2Q/aE/RHHZ52ZzrtdZa5d7gXuNzyXem3eh33Zvjf8q/3/CjwaPIRh72UZPw2ZQr2h XaGjobHMBZl7Mx/I/EaWJWtJ1nXh/PArkQvRodjc7Ja4KX4m/p34izz32vEtnFp8F4geuezAPDWG BPEAvotYw49SfPMJ8xZ8RTJBzs7s7R+YNyvZvGLThpU7NgwbVfS2Dp00BuhMiINSXCPF1VIckOIq Ka6U4gop9kuxT4q9UlwuxWVS7JHiUil2S7FLip1SbJdimxRbpdgixWYpNklxiRQbpdggxXop1kmx Voo1UqyWYpUUK6VYIcVyKZZJsVSKQSmWSLFYikVSDEjRL8VCKRZI0SfFfCnmSdErRY8Uc6WYI8Vs KbqlmCVFlxQzpeiUokOKdinapGiVokWKZilmSDFdipQUTVI0SjFNiqlSTJGiQYp6KeqkqJWiRopq KaqkqJSiQopyKcqkKJWiRIpiKYqkSEpRKEWBFPlS5EmRkCJXihwp4lJkSxGTIipFRIqwFFlSZEoR kiJDiqAUASn8Uvik8ErhkcIthUsKpxQOKexS2KSwSmGRwiyFSQqjFAYp9FLopNBKoZFClUKRgkpB 0oKOSzEmxagUF6T4QIr3pXhPineleEeKt6X4txT/kuKfUvxDir9L8ZYUf5Pir1Kcl+IvUvxZijel +JMUb0jxRyn+IMXvpfidFL+V4r+k+I0Ur0vxaylek+JXUvxSil9I8XMpfibFT6V4VYpXpPiJFC9L 8WMpXpLiR1K8KMUPpXhBinNS/ECK70vxPSm+K8V3pHheim9L8S0pzkrxTSm+IcXXpTgjxXNSfE2K Z6V4RoqnpXhKitNSjEhxSoonpXhCipNSnJBiWIrjUgxJ8bgUj0nxVSkeleKYFI9I8RUpHpbiISmO SvFlKb4kxReleFCKL0jxgBT3S3GfFJ+X4l4pPifFPVIckeKzUnxGirul+LQUd0lxpxR3SHG7FLdJ casUn5LiFiluluImKQ5LcaMUN0hxvRTXSXGtFIekOCjFNVJcLcUBKa6S4koprpBivxT7pNgrxeVS XCbFHikulWK3FLuk2CnFDim2S7FNiq1SbJFisxSbpLhEio1SbJBivRTrpFgrxRopVkuxSoqVUqyQ YrkUy6RYKsWgFEukWCzFIikGpOiXYqEUC6Tok2K+FPOk6JVirhRzpJgtxSwpuqSYKUWnFB1StEvR JkWrFC1SNJ9gvWX0mofDjfhqyoPDYS/oGhG6ejjcgNABEbpK0JXDYQsirxCh/YL2Cdor6PLhrOk4 5bLhrGbQHkGXCtotju0SoZ2CdojI7cNZM3DBNkFbBW0Rp2wWtEnQJcOZrThzo6ANgtYLWido7XBm C05ZI0KrBa0StFLQCkHLBS0TtFRcNyhCSwQtFrRI0ICgfkELBS0Q1CdovqB5gnoF9QiaK2iOoNmC ugXNEtQlaOZwqBNp6BTUMRyaiVC7oLbhUBdCrcOhWaAWQc2CZohj08V1KUFN4rpGQdMETRVnThHU IC6vF1QnqFZQjaBqcbMqQZXiLhWCygWViZuVCioR1xULKhKUFFQoqEBQvqA8ceuEoFxxzxxBcUHZ 4tYxQVFxXURQWFCWoExBIUEZwxmzYaygoMBwxhyE/IJ8ItIryCMi3YJcgpzimEOQXUTaBFkFWcQx syCTIKM4ZhCkF6QbDs7FX9cOB3tAGkGqiFREiAoinOi4oDF+Ch0VoQuCPhD0vjj2ngi9K+gdQW8L +vdwYD5eL/vXcGAe6J8i9A9Bfxf0ljj2NxH6q6Dzgv4ijv1Z0Jsi8k+C3hD0R0F/EKf8XoR+J0K/ FaH/EvQbQa+LY78W9JqI/JWgXwr6haCfi1N+JkI/FfTqsH8hkvLKsH8B6CeCXhaRPxb0kqAfCXpR nPJDQS+IyHOCfiDo+4K+J075rqDviMjnBX1b0LcEnRX0TXHmN0To64LOCHpOHPuaoGdF5DOCnhb0 lKDTgkbEmadE6ElBTwg6KejEsK8JiR4e9i0GHRc0JOhxQY8J+qqgRwUdE/TIsA+1Pv2KuMvDgh4S x44K+rKgLwn6oqAHBX1B0AOC7hc3u0/c5fOC7hXHPifoHkFHBH1WXPAZEbpb0KcF3SWO3Snucoeg 28Wx2wTdKuhTgm4RdLM48yYROizoRkE3CLpe0HXD3hVI+7XD3pWgQ4IODnvXInSNoKuHvX0IHRj2 orGhVw17a0BXCrpCXL5fXLdP0N5h72qccrm4/DJBewRdKmi3oF2Cdopb7xCXbxe0bdi7CnfZKm62 RZy5WdAmQZcI2ihog7huvaB14snWisvXCFotzlwlaKWgFYKWC1omaKlI9KB4siWCFotELxK3HhB/ qF/QQvG4C8Qf6hN3mS9onqBeQT3DnhQSNnfYw8w6Z9jDCuzsYc9BUPewpxg0S5zSJWjmsAcdCdop Qh2C2kVk27DnShxrHfZcD2oZ9lwFah72HADNGHa1gaYLSglqEtQ47EK/gE4ToanDzgGEpghqGHay clQvqG7Y2Y5Q7bCzH1Qz7FwEqhbHqgRVDjuLEFkhziwfdrKElQ07WYVUKqhEXF4s/kKRoKS4WaGg AnGzfEF5ghKCcoedzEo5guLintninjFxs6i4S0RQWFyXJShTUEhQhqDgsGMQ9wwMO5aC/MOOZSCf IK8gjyC3IJe4wCkucIhIuyCbIKsgizjTLM40iUh89zj7CwZBekE6caZWnKkRkaogRRAVRFLj9pUR hjH7qsiofXXkAvQHwPvAe4h7F3HvAG8D/wb+hfh/Av/Asb8j/BbwN+CvwHnE/wX4M469ifCfgDeA PwJ/sK2L/N62PvI74LfAfwG/Qdzr4F8DrwG/QviX4F8APwd+BvzUeknkVWt55BXwT6ybIi9bE5Ef Ay9B/8iajLwI/BB4AcfPIe4H1s2R70N/D/q70N+xbow8b90Q+bZ1feRb1nWRs7j2m7jfN4CvA6nx M/h8Dvga8Kxle+QZy47I05adkacsuyKngRHgFOKfBJ7AsZM4dgJxw8BxYAh43Hx55DHz3shXzfsj j5qviBwzXxl5BPgK8DDwEHAU+LK5OPIl8BeBB3HNF8APmC+J3A99H/TngXuhP4d73YN7HcG9Pou4 zwB3A58G7gLuBO7AdbfjfreZZkduNc2JfMq0LnKL6cuRm00PRa5VcyOH1LrIQVoXuabvQN/Vxw70 XdV3Rd+Vx67oM19BzVeErui6Yt8Vx674xRWpbp1pf9/evn3H9vZd3ren77Jje/ouPba7T7Pbs3vX bvVfu+mx3bRlNy3bTRWy27E7ulu17Orb0bfz2I4+smPujgM7hnZopgzteH2HQnZQ7MI4c2JHKNzG VlH377A62rb3be3bdmxr35a1m/s24rE21K3rW39sXd/autV9a46t7ltVt7JvRd3yvmV1g31Ljw32 Lalb1Lf42KK+gbr+voU4f0Hd/L6+Y/P75tX19PUe6+mbUze7bzbiu+u6+mYd6+qbWdfR13mso6+9 rq2vFUkmmY7MaKaKtdkzqdmZeBL8FygzykKp0Ouht0IaEhoKnQmpLntGJEMpsAdp85wg3Rq8Knhr ULUHfhhQUoGCoja7/4f+X/v/5te4U/6Ckjbic/iiPhVvtJw54euez9J2wtfUIri8mqe12xdPtNm9 1O6NeJXWiJcS5+vOt5yq9znHDx2K3U7t9nG7krLjdLstYlPYx7hNTdnKa9vs1ohVYR/jVtWXsiKG PXyeZe78Nrs5Ylb6msxzzErK3NTcljIXl7URlUYpJdQBUg049yT1RtrUZxDF/kcOSm87Pn9eMtk1 YiC9XUOGuYuH6A1DufPYZ6pn0ZDuBvzHJosW9x+n9FMD+D9kmucPedh/yMPD195yC8ma0TWUNa9/ WH3ggawZA11DB5hOpbgeZ5rglIHk0p27dyaTu5biY+nOXUn+ixDdzUL4wQH87tyFMPsHQnhi6xM7 4+M/4jSct2wnfvhtEBD88bP/l8TQ/yXP+T/4MY8T9t9MTR9XDpHVykHgGuBq4ABwFXAlcAWwH9gH 7AUuBy4D9gCXAruBXcBOYDuwDdgKbAE2A5uAS4CNwAZgPbAOWAusAVYDqwD8p5/KCmA5sAxYCgwC S4DFwCJgAOgHFgILgD5gPjAP6AV6gLnAHGA20A3MArqAmUAn0AG0A21AK9ACNAMzgOlACmgCGoFp AL42SZkCNAD1QB1QC9QA1UAVUAlUAOVAGVAKlADFQBGQBAqBAiAfyAMSQC6QA8SBbCAGRIEIEAay gEwgBGQAQSAA+AEf4AU8gBtwAU7AAdgBG2AFLIAZMAFGwADoAR2gBTTTx/GpAgpAAUJWY9l+NR0D RoELwAfA+8B7wLvAO8DbwL+BfwH/BP4B/B14C/gb8FfgPPAX4M/Am8CfgDeAPwJ/AH4P/A74LfBf wG+A14FfA68BvwJ+CfwC+DnwM+CnwKvAK8BPgJeBHwMvAT8CXgR+CLwAnAN+AHwf+B7wXeA7wPPA t4FvAWeBbwLfAL4OnAGeA74GPAs8AzwNPAWcBkaAU8CTwBPASeAEMAwcB4aAx4HHgK8CjwLHgEeA rwAPAw8BR4EvA18Cvgg8CHwBeAC4H7gP+DxwL/A54B7gCPBZ4DPA3cCngbuAO4E7gNuB24BbgU8B twA3AzcBh4EbgRuA64HrgGvJ6ukH6CGog8A1wNXAAeAq4ErgCmA/sA/YC1wOXAbsAS4FdgO7gJ3A DmA7sA3YCmwBNgObgEuAjcAGYD2wDlgLrAFWA6uAlcAKYDmwDFgKDAJLgMXAImAA6AcWAguAPmA+ MA/oBeYCc4DZwCygC5gJdAIdQDvQBrQCLUAzWf0/uIr+3/BoA/8bHvJ/8DMGli0l/x/1Xjw4CmVu ZHN0cmVhbQplbmRvYmoKMzQgMCBvYmoKMTgzNjcKZW5kb2JqCjM1IDAgb2JqCjw8IC9UeXBlIC9G b250RGVzY3JpcHRvciAvQXNjZW50IDk1MiAvQ2FwSGVpZ2h0IDYzOCAvRGVzY2VudCAtMjY5IC9G bGFncyA0Ci9Gb250QkJveCBbLTQ3NiAtMTk0IDEyMTQgOTUyXSAvRm9udE5hbWUgL0pSWFlTTCtD YWxpYnJpIC9JdGFsaWNBbmdsZSAwIC9TdGVtVgowIC9NYXhXaWR0aCAxMjg4IC9YSGVpZ2h0IDQ3 MSAvRm9udEZpbGUyIDMzIDAgUiA+PgplbmRvYmoKMzYgMCBvYmoKWyAyMjYgNDg3IDUyNSAyMjkg MzkxIDUyNSAzNDkgNTI3IDMwNSAyMjkgNDk4IDQ3OSA1MjUgMzM1IDUyNSA3MTUgNTI1IDUzMwo0 MjMgNDUyIDQ1MyAyNTAgNDk4IDQzMyA3OTkgMjUwIDUyNSA0NTUgMzE5IDQ1OSAyNTIgNTQ0IDY0 MiAzOTUgNDcxIDU3OSA1NDMKNDg4IDY2MiA4NTUgNjQ2IDYxNSAyNTIgNDE4IDQxOCA4OTAgNTE3 IDQ4NyA1MjUgMzA2IDQyMCAyMjEgMjY4IDY3MyA1NjcgNDk4CjYyMyAzMDMgNDk4IDMwMyA1MDcg NTA3IDUwNyA0NTkgNTA3IDUwNyA1MDcgNTA3IF0KZW5kb2JqCjM3IDAgb2JqCjw8IC9MZW5ndGgg MzggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2Uy27bMBBF9/oKLtNFYEqk 7AQQBAQpAnjRB+r2A2SJMgTUkiDLC/99z52kaZHFNXA1nOGcIc3N8/7zfhxWt/m+TO0hra4fxm5J l+m6tMkd02kYs7xw3dCub86+tedmzjYkH26XNZ33Yz+5qsqc2/wg5bIuN3f31E3H9Enfvi1dWobx 5O5+PR/sy+E6z7/TOY2r81lduy71lPvSzF+bc3IbS73fd8SH9XZP1r8VP29zcnRERv7aUjt16TI3 bVqa8ZSyyvu6enmpszR2H0Klf8049m9Li7yuTL54rLOqKLDI+zLKBmyU3T7Illjk/S7IbrEI62V3 WIQtZB+wiNxe9hGLsFvZBouwrewRi7ClbItF2Fy2wyIqWzRhEdaa7LGIxdo3AC8R3ckCKBFNssBJ 3kchBAAlomZhDca7U5MBVolSGk6AVSp8bhbWIGafWy6swXh3mlWAVaJyJwur5D1cWFglokIIsErY oyysEk02srBKHIptBGswXoaQVRFWicXCj7BKLNas+GYCQaWANrGRhhNhlcjVnCOsErlWCtZo58tH orBKLNaBRlijAUYB0qmJqIgicBJWs4rAsUyzEn6ERmIjawMaasrqIvFjwiq3hEYCQU3SmolSthgi xqKNVJlra2LOqswMTN4zfP0f/l78vPzwRygBldjUdgGU3mR1E0pgJazY6cvEpjrrEnaJTc3CXRo7 /x+isEtEDYcxlHa4XC2ijEGiQ82N8iasjmDLKCQ2Uhv8G0xEVZn7bsJalDFwjVVKk+FmmbB09R+7 ngU9X+/PTXtdFl4ae+PsEdLjMozp/Rmcp1kFTH8AHhxJdAplbmRzdHJlYW0KZW5kb2JqCjM4IDAg b2JqCjYyMwplbmRvYmoKOSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUg L0Jhc2VGb250IC9KUlhZU0wrQ2FsaWJyaSAvRm9udERlc2NyaXB0b3IKMzUgMCBSIC9XaWR0aHMg MzYgMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDEwMCAvVG9Vbmljb2RlIDM3IDAgUiA+Pgpl bmRvYmoKMzkgMCBvYmoKPDwgL0xlbmd0aCA0MCAwIFIgL0xlbmd0aDEgODM5MiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdWQt4VNW1XnvvM4+EPIYAIQ/iOWGYCWYSCREIj0jO5OUj FQJEO4NaJ5C0oChTCaCogChXGXzER721thKxIBWUkzOICY8y6rXXai2xthbtw3ytttXCJ2219qLk 3H/vCa/W797v3jNZe6299/r3Wnvtxzl7hxgRZdF6EmQuvqE9Tl6aiZKfgAoWr+oyPp/91LuQ3yfy LPx6/Bs39HuWvETkNYlc139j2S1fzym/ZRRR9i7oLFvS2d7x+eGbriHKKUB+2hIU5K31vo58K/IT ltzQdbN3hjSY04XEu2z54naahh/l3Ia8+4b2m+Oe5doq5O9C3rix/YbOJzZv2oL895EPxJev6HIu oF8iL/0Lxm/qjP/lsg/ykf+EaOTPUMbwk08WuUFoQ5a49tE4RU/TOC1I44gc9CdNQ0ud92Wd5Pwj NFCSJtUKkU276JdsIjMoyU7QWPoHK2ST6VLS6DNEbDedpG/RaGqjR1keTaB8uoIuZRp0QnQve9xZ 5XxIF9FDtNV5gW1wnkH9A/Qj+gc8+K3GqIbmQP8K6qQPxQcUdb6D2N9NI2gWzWf51E5v4/cp/HiY HqEfstucf8DqaNqA9mopTGHnRecLKqd7tW7XkYzn6UHaz9zOYmcpnUfjKcFDztvOexSkKD1Fu+BT iKW0S6iUrqeN9G1WKH4E6Vv0fRpiWfwa0eA6BEuX0pV0I62mBD1Dr7E81uo64jru3Or8EdEcRRPh 01L6kE1ll/NtWpYz23mXrqJ+ehX9lb+UdpX2tOuqoTrne85LNIZeYJnsAHvRVe26/+QdzpPOcxiR IE1GRObAziK6k16kH9Nf6K98nbOOLqEFsPwKK2EGCyLib/NCvpavFW/RBejtNfB2JW0hCyOyj/bT QcTmVzRIH7DRrJhdxhaxB9lfeRbv4IfF42KP+LnGtB8g3n4KIEZdtI32Yk6/QYeZC+1XsVZ2HVvO /p19jw1yix/ln2le7U7tc+2kKzg0OPS5M8f5lAqoiL5Ca2gdYvsUJWkP/ZR+QX+lv9HfmY9NZ0vY k8xig+woz+Dj+Vwe54/ybfxZMUc8KF7Upmr12vXaG9q7rn9zbfa0e4a+2D708NCzQ286LzhvYu7k oP0gNSOid2BWbKND9BZaf4d+Q7+T8wftz2IL2ddgZQW7hz3CnmWvsDfZR+glqd94Pos3wupyfhPi tIE/zB+B9cP4DfB3+W/4n/mnwiXGi2nim+JJYYk+MSD+oPm0oHaBNlmbqy3UHIxMteti1wLXDtdO 10uu4+5ad4c77v6TZ4PnLu9PTpaf/O0QDS0ZsoaSmLtezKQ1iMQTtBXzfg/G4DVE9KfweJA+wSgU sVJWBr9nsGbWwi5nX2VXs062gd3NHmLfZo+zrew59AB94B5EK8TDfAFv5538Ln43v4/vwW8f/zF/ mx/hx+D5WOEXITFZXCoWiqvEjehDl1gr7kJkHxTPiMPiLfFH8SdxDKM2VjtPW6mt0R7Tntb2aG+6 vuK6Ab+trkOulOtN1xeuL9zcXeQe557kvs69w/07j9szzdPq2eT5uedv3jgbx8rhuYG5f/rhhViD 5/Fn+GhtHTuG4hKmUS56HsI4LMCq+BvViSGMS46sh29jeKGGPRAbmKlZRLyL7aep7BVa5+YCu5E2 SDb7NR/UXuYX0S9YjBVqT4sbXa/xUtqJ3aibH+D7WT3t4bX8Sv5dQewDtoM+wHy/mR5h17MVtJMd YzPZ7ayGraOf83yxgN1Ftc5WrrEMdik7TvCA7tA66Gunu/ClAptBv6YPh57QsrXbsD/10aMY0V30 HvsBnWAu5yh2N4HdqB27zL2Y7xtJ7nrXYJ2tw3osxA6yzH2Y9jA33gQ17tnaGjpO/0UfuvZhRtVj N/3j0FLtCe33To1TiRWGVUY7sO6W0MVYMR9glhxEXuauxkrPxF5SjVXdSgupg27HrvegYznfde50 bnGW0+vAnmAV7ATrwYroA6KWXsXvAXqHbcY6vPhLu/e/Fg51UIo+YgUswKqxHo65Vrm6Xc+49rh+ 6HrDPRnRvosex4z+HWZzJnqwmN6kj+gz5sXYFFIFTYG/0+F7hJbxqDhIDayI4lizE7GP1w/3ZAVa 2YDofRfr+SDWxnHsE1fTD+kI42wserQY9r1opwVxvpZW0HaM4J0siZIO7Nrl9Gf0O4dN512wZ6Kl R7FrpeDTr+kPiLaj/KrAvtDIrkRbn9FXqQMWplEr68UI7KUZ2FkbxU8Q7wnMR/VsPPs+cDGs0Bwq oRmu3zNOFUNznOl8qTiId4yD8h68vYrpIvZNeJGLfpykMWwuTR2aDx/eYkKz2M+UF4/xTudusXpo Gb1OP8CYmNoqTyORGW4z62ZfVDtr5ozpNVOnXFg9uWrSBZUVofLzJ5YFAxP840sN/bySccVFhQVj 88eMHpU30pebk501IjPD63G7NMEZVTT5m2OGFYxZWtB/ySWVMu9vR0H7WQUxy0BR87k6liFx7ag6 R9OE5tf/SdNMa5qnNZnPqKXaygqjyW9YbzT6jT62cF4E8n2N/qhhHVPy5UruVnI25NJSAIymgiWN hsViRpPVvGpJoinWWFnBekdkNvgbOjMrK6g3cwTEEZCssf54Lxs7mymBj22a2cvJm40uWkX+xiar 0A8omhGBpvYOq3VepKmxuLQ0WllhsYbF/kUW+eut3JBSoQZlxnI3WB5lxlhqoTe02eitSCXu7fPR olgoq8Pf0X51xBLtaKPJGhmC3UZr7Jr3C85k0XheQ+Tus2uLRaKpYKkhlROJuw0rNS9yFra4VLYQ jaINYHmgOZZohul7MVItCwxY4xujEYtthElD9kT2Kt2/Tn+TLIldZ1gZ/nr/ksR1MQxNUcKi+beU 2kVFZr8zSEVNRqIt4i+16or90fbGcb2jKTH/lmShaRSeW1NZ0esbmQ5sb07usJCVfbbQiaCn65Sk 1KXUMv90ZJn0yH+pZWJGLTbgScSPPk2XSed0SiyejgHAE2VAWR0YkaVWRkMs4Zspy9FFZrkCPr+R +JQwA/zHjp5b0j5c4g74PiVZKefJ6almsfZTshUKWeXlcop4GjCm8HG2yk+trFjVx6f54z4DDOGj VsS2PTpzEsJfWioHeHOfSYuQsdbPi6TzBi0qtsmcFIpaPCZrMIDpmjFXyJr1p2pOw2N+zOQ96mN5 jOUNnv7L9eWPaloy02L5/0N1Z7q+ZYG/Zd7CiNGUiA3P2pa2c3LpehlQxA11w5I1qiEiijnKpMSL harFpLx64WkVZCJZlhbAn1s6jdUhMClVATOaLV/sknQazSwtHV4y/4rp83jPAvU5xyVKsTOw4V5Y M0PDfqa9tmadkz/Hu6yEaGnDjsNb2hYmEpnn1DVjL0skmv1GcyKWaO9z1i/yGz5/op8/zZ9OxJuw C6UHtM/Zt7nYar43iq4sYTMxbTnV9/rZPfN6TXbPgoWRfh9OL/e0RWzOeEOsPhqtxKeFPNy48MOb 2kP1ezgbcnv6eJ05ilzakKBMjzbEqNDrdg1xcYAFKQMfqAVUEPL9vfZk7RzfJ7WXn6ylOsi+L5BM riodWToygIThpf+FIVJfmC76nAwtRWpquPgDv6rj71+bW/upt9AL20T/OfehP53ip71hlKH0ZQUK PbOH5lCDj06cOLEGvZBqZz/cjSI+QxWp05/S4PhO4HjHu5H6aBLekOQ+wV9CZzk0GeUNtyNPIlR/ 2ZxowyWh8E1L25dV1i9f1nF5m2xOauJxyuQZ8UseWS+IetvWh7PFLtoNgjGkBqgHJMgUu5Ke7Gqz DzxvtOJ2fqi630mJXfbMC1V55SPV6w+InXiFX4jinfYVsnhn0myU6juTF85K80mTFbe96WrP6Go9 XATYJBCn3GFpLvgDoC2gQyA3HNpJ74EckBA7xFa7WUfD29BQbni02IZAmEgPgxyQgPfb0Jdt9PFw iQavnkpmZEnzTylUsXgKqFykPtB60G7QYZCLliPdAnJAAhI+70FcbBVP2j7dF84UT9A6EBffoVzG SEfr3076VGweS+aOqjbDPvEtagVxssTllAJxNPsgYA8Sh3qLXTlZhbAlmZlT7YP+Zji9GY5shske pEzlTUhSf3NyVL50/k47d6TC3WpXTUkLSV9BdSuicDMx0SluxAFPx8HgRnw+6WIxeAn4ItFB2cpP M5nrq14Pe3VQr8N38vmoDot8fH3qolEU4ctHdmelnZO2s9KeWF6NHjeIAqWSK7Lx4acLr/DY1bqx X5gq+PckM0ZI/+6xfWOqD4qNwoODuS7WQ2usnntQZGKMM1VP2pIZ2dXd4SzRhm62ISw6fGSIskxN caONhsIjRZMYh8OqLq4XJTg466JZnKf40+JJHBF18b1kcJye2i8eVqiHZKMwPzs9tWYns3OqU+EM MRu1lrgfA3C/Mt6dDE7HZ3ZQTKQqEEeM10FaB8knEpASGLUERiqBkUrAqQRmH4lNqNkEnUliDcXF auoGbYEsp9UYGwGVi2GMPWFidb8oFAUIjG8/QslQWpTMyJGeFdh5o5RaQTIrp7ruoFhBc0EcXe5K ji2oXr5flKuuVCQLiiUgbmO6HsSxTw0NWsqXQ3JQjEMgZGBKxHn2GN0K68jLiawT46/xARkk/hb/ hRxuefJV/PVh/sYw/2maOyk+kF4U/GeSD4bH8Q/Q2LX8N7QFEuf7+ctUhYbe5X1y9Pk7vJ/qwI8g 3wHeD34h+D679FW9j/clweD743Z2vuwsf9kOTRoW9MCwMLZ4WMjLrw4H+Ev8Rdz+6PyX4BPAX+Qp 3Nbo/BB4AXgK3/6vgj/Pp+IeSMepOM3/gx+QU5y/wPfiFKLzpJ0jXbBsj2S7bbdkz9mUzrVO0g/w 5/hOXGDo/Fk7WITKHcngBD13P9pjuCfoskv0vHAmf5JF2CdQ6sEZBZzy+Fa7RjbSbR8w9H7ezbvN ghozYFaa20VVoKqyarswAkalUWNsN8I+fj82kC0c65dvRlpDBsfsAZmgbr7J1mqs8En0SfaL03qk PUqKIY0riZD6lCRrjyupjm+kuSCONtaC1oHWg+7Aa6qbrwHdCroNdLsq6YK0ErQau0kciDgQcSDi ChEHIg5EHIi4QkjLcSDiChEDIgZEDIiYQsSAiAERAyKmENLfGBAxhWgFohWIViBaFaIViFYgWoFo VYhWIFqBaFUIEwgTCBMIUyFMIEwgTCBMhTCBMIEwFaIKiCogqoCoUogqIKqAqAKiSiGqgKgCokoh DCAMIAwgDIUwgDCAMIAwFMIAwgDCUAgfED4gfED4FMIHhA8IHxA+hfAB4QPCpxCDQAwCMQjEoEIM AjEIxCAQgwoxCMQgEIN8da8YCL8CyAAgA4AMKMgAIAOADAAyoCADgAwAMjDcdRkIOWFSwKaATQGb UtgUsClgU8CmFDYFzRSwKYW1gLCAsICwFMICwgLCAsJSCAsICwhLIXqA6AGiB4gehegBogeIHiB6 FKIHiB4gehSiG4huILqB6FaIbiC6gegGolshuoHoBqJbIf7PQ8PvYBEv3rV8PTtf8XV0VPG1dETx 26lX8dtou+K30gbF11CN4qspqDiGWvEu0r3M1mtyw/nYAuaCrgUtB20B7QYdAnmUdBjSeyCHTzXH a7meuZ4tnt2eQx7Xbs+gh+e657q3uHe7D7ldu92Dbm6Ei3m22kextdADwDFah/RjEF4iSOuUVMen wO4U7LNT8ZvCp5gjjxkfl7PD5exQOdtdzh4oZ+EMfjHT1E5nUA0+d3UWMbOCs/UjoJpg2WzsTPfv PTpWt4PT9D52IM3ON0PIHgX1graDNoBqQNWgSlAApINqguWARczxw00eAC8DlYIMUA3l478JlDfS a/bzbLY9+Uo2ZUg7ZROB22+XVYH12WVzwV6wyxbp4Qy2l8rkVxF7HotqJ/huW38f1c+m2S5b34/c DlufAnaNXXYB2FV22Rt6OJtdQTr+D6CztmG+AAMu8/Nt/UqozbP188FCdllQapfDUAC157MI/h+j S1mhJ6Qt+W19FrTH2/oMqe2lMjnwuK+rVO65IMu8SMKhj/tZRGPmCP2Y/rB+FP7+GYHF9HjH6NPA Dgf62JVmpn6g8gkoh3U7nCn18X7oHeaW5M/r2wOb9MfRFgvs1R/TL9Dvr+zzovg++L1JmbD1DTjH 7jRH6ev1Kr2r8n19hX6Z3q7P168JoNzWr9YPSDcpyiJ85169FQ1eil4EbP3iAHyBi836Lbqpl+kz jAMyvjRdmsZMrjwgI0DVaesViG95ANZt/YqaPjbSLPcc93R7rvLUe2Z5/J7xnvM8JZ7R3jyvz5vj zfJmer1et1fzci95R/c5g2ZInjFGu9Vxxa3JjKZkH84MDPNYpjh/eTldRtYo0cJbFtSzFiu1mFoW GdbfF/j7WOa8hZbLX8+svBZqaau3poda+jzOfKsm1GJ5Wq+K9DJ2fxSlFr+nj1FbpI85smhjsbyP 6WW08b7ifmKscON90SgV5K+qK6jLmz1yRnPjlyQxVRhrDJ15Cs4WS6xHWxZErGdKola1FJySaIt1 h7yt6ee5PLupsZ/nSBaN9Gtxnts0X5Zr8cYo1N5XapjNOVCjMsmg5q0nQ6phP6mXahijtF4QcOiV Sga9zGwKKr1gZrbS05jU6z1iNDX24u5M6gSIjiidIwE6SwczBtjG3iASaPkNFpFaDLdyyrHzVUO6 DpVKJFBh+O5TDelMGbMmnVEJDKtMPa0yVdkSaX9UMzJBM6MnntIZPRE6ZwL5/5M660MsOXnl2peb cAEW8zd1gmLW5lVLCqz1iwyjd+1KWYF7qGBs0eIlkrd3Wiv9nY3WWn+j0TtZ4f6p+mVZPdnf2Esv N7VFel82OxvtyebkJn97YzRZVxsJn2Nr02lbkdovsVUrG4tIW3UK90+2wrK6TtoKS1thaavOrFO2 mpbKed8a6fVSfRSXNIon+YhMzOFYcWm0Pt8Xny0ndP+s0oK1xfs0wn8zRuBiKgtXmdkgWVUZrgzL KqwzWZUjbzmHqwrWziot3sd2DFf5UDzSX0+nBoIkvsWaOq/FKsUliZwquIr88jFbIR9VXUBNSxvx h3yXoq4VXadalJyk5r8+XV/2rFy5ckUXkpWhFUQtVvmCFmsabsF6PR6YijVGUXbBqTIhVFlvRkZT n5NCZQhOsC5pTkohFkIEzUxyk4f3uHs8XJ4iupJFJdXLD+K7YR0Ix2G+2sZVgqxanRwfwGkJKpOm pjmOqzJvF5VWw0KyBlDJA2lujqyE0B3oruyu6Qn0VPbUuFG7dzsK9e3yVWpP2i6oK7TiVDAgdkUR bLgl7T1pjytRhnukEApFQyuYitcp/TNclSN7JrDoo3pWqOZlvFWEkUoRQZe1GI+09ZUyJ5+0oLCI swKhFFrpnCqSyZkHOaL/BgTJTaIKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iago1NTI4CmVuZG9i ago0MSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA5MDUgL0NhcEhlaWdo dCA3MjIgL0Rlc2NlbnQgLTIxMiAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstNjI4IC0zNzYgMjAwMCAx MDExXSAvRm9udE5hbWUgL0JKTllDSCtBcmlhbC1Cb2xkTVQgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1W IDAgL0xlYWRpbmcgMzMgL01heFdpZHRoIDIwMDAgL1hIZWlnaHQgNTI1IC9Gb250RmlsZTIgMzkg MCBSID4+CmVuZG9iago0MiAwIG9iagpbIDI3OCBdCmVuZG9iagoxMiAwIG9iago8PCAvVHlwZSAv Rm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9CSk5ZQ0grQXJpYWwtQm9sZE1UIC9G b250RGVzY3JpcHRvcgo0MSAwIFIgL1dpZHRocyA0MiAwIFIgL0ZpcnN0Q2hhciAzMiAvTGFzdENo YXIgMzIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iago0MyAwIG9iago8PCAv TGVuZ3RoIDQ0IDAgUiAvTGVuZ3RoMSAxNzEzMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAGlewl8VNW5+Dn3zr7e2Wcyk8lM7ixJZpJJMtnJckkmISEEkhAwk7BMYICAiOwqyCIEwYBP xWKjUtEu5JVae2m1xbZa7ENs++T97FNbX1stWtu61PeobX1UyOT/nTMzMSBu75/MOffcs5/vfPs5 F2GEkBrtRiwqXX7D0Hp8Fn8IOT+GkFy+dbNnzvud5xHCHoSYtpXrV93wwivJcoTYYYQ0M1etvWVl xxt//wlC+kcRCl0YXjGU/PvYuhMIzTiKEKoahgx9k/wFeH8J3n3DN2y+WfRqGuD9Irw/vPbG5UN/ Hv3dfyBUPwbvvTcM3bxeMptpgfe/wLtn3dANK1YveOtNhBo08O5fv3HF+he7D0BZQwVC0h9AHoZ/ 8qdBMtQPTy8KIj/ywGpMyIC0yIKcUINBNiRFDmRFOqiRi3KQHuUjCbTikBK5UB5SITnikRl6sSM3 8gFEjEiBAigoHYU2SLoAaoZojCTlkM78sefT6ckLk19BaPICySZxqjedztZLP2U7EMc2TF5goNXk w1DDcGX5td8UkE2ChBTvQK+hn5EE+hLsGewCGkMHUQNKoA0095Oif3xSwSfn40ZchYuxD30N3YFL sRfb0SFSG/LLcQF6bKrlTrQFvYAeQkfRPWgTGoYNeR+dR3ugfBlaN1WLzK8Z/hEaoMuhBViHS9Df Abd6p+p9lHgJPQ+jGaH8BbQE3YzmovvQTvQ79AZUSaB3YIypPxwmSRqPwjwehpc7IXwfApnFw+h2 mieiJIyO0Am0Ec2mZVOR7GmkYDbD/twG+3Ie/QoKtqAFqDFbAdfhIuxG/wpwfxO9hO5jJOh3QCmn YYwLWAc534cVn8evoQFWBrO8D11AW2Hev0u9knqV4IIQTy5dsnjR4EC8f0Ffb9ecztkd7bPaYi3N M4Wmxob6GXW1NdVVlRXR8rLSSElxOFRUWBAM+H18vteT5851OXMcdpvVYjYZDZxep9WoVUqFXCaV sAxGYWwX7S39rWtER0tC1PAxnvOImrkXuiIiMjq9vMETjcSLM7VEaUhEpk7R3N1/Egk1cVEWurrK XJH1c+97oXGX09MqSvzw42cPJcWC3n4vz/3KOVUeh27FnJZ+r9cpMn74dUAR/GYPeZIi1w35UEBz OkTU3U/Cqck3aiAT1XjjEPf2i+7sa5z0ll7KtEk+CQR1+qppzsWj3EmNoyUmIvNJpHlDRBZS7UIN ElG9WBCCiXCQor2hiIjN74vYJGJLFyzpyiFIs/M114BBa3IN35pcDRBNJj6C6YU0RL2eUc9ob78h 6vR66aQ7xZ/19J9Uq1r4lhUqWAWiGeikSg05apIB27L+JNY0YppgNK11Jxmk0AL4jGS6rSSsEYWD CUjwMYAblJg+Kjk1efrQ9CIEzdKVEFSjKUzHFGUtojw9Cc9qURgS0UHPyfDp0UOnOLQsEdIk+eTQ on6RHYJJnUSsv3W4T3R1dg9AFkwCQmLYQ7Y7RiOyeZ7WYc8ovJO6CYj5GDS9Mj85vCJB0AQn+BiU KVv693tPO0UjPFtFQ0jUQnPttjed7GirfbWHvI6O7veID/f0Ty/1kjqABPbisGe0lYfRoLPWNc1k xyJT20axsSNJN0c4OOQRdy9bAzCD39ChLP57RzlR84EXdgf2B1oS6iAAJiGZWEOWsgZaSuDhGT24 gi71EF0a4KundU2MBNIQsB8tgNYD/a3DfCvAMzMgAATas/6r23q9oiNEGo6OtpIpDiVh9gQy8HOE 6DTSL0ATzhCG+bSIQh99oD66BzCiMBSLZ7IyFaBEAvsgColYPE4Wld4AUe7fLy3hPaOke7lfNIc4 7xkoO10c7uztb40R7ISaTEt/w3t253uQ7uyeysZ2qDMaeY8AiZTM5zt70lgwTOBDokRfmoABapmd h6qZ+rTXc3bnufQIi/rb+LbE6Ggb72kbTYwOnZrcvYz3cPzoSY1mdH1rwkPJH0P+Dw86xbZDcZFL DOM6ukNkeFgc62/r7RRNPYNkq9o8w0OQA78m3lvj9Bqm6gAXuXZxhuYA+4EGCM2Ncn+B1WuAOzk9 bYTVnAIO4RS5GkKyMKEF/UATy2GI1iSNgFbmQ+dOQjVs3N+6en4GWE4vDEmRh/DAnkwudOL1Eno6 eEpAy+BF3N3Tn373oGXO7yIhEoJ9TJCS09kSywJSsjtbMtU8wcO+2TthfIofn4TfwNuncHvUwBs9 tYSxw+zg15EUT/fBGi/WiAqAGN16U0s/62RIFUgxTpakVCEQD/WiLUQbEpgAxxzleM8LvMiFRGlL /2lnfdzDGYBZYqjTDhUJpnIv8D/HhI8iMyfiehFbST4CvgrQA75vq4HCKUTytI4mMgg4fVlQldRO Dk+RUnryQLtkbbB6jgfSdabBYDDyZIXPE4TPCgZ/G6Er2BIKqNlxUUfknaj7C41gvs6Wfg9wIqDc HprwtHqGyWaLnkSMsoS4k5Rns09Nnk/ECAvsBxyEKs4MigOip0F7JSoWhz8vou8GRL/tUHy4DuYk FMEKPJUwLAF6S19/htzoPlEigLE6yFKuLJ+CYrYOMDYgZ69YmvNzOyBqjp1SdZp2pyrDJvTBaqY2 YPpgtCyLHmQmYhvI/zQPoDMTZ9F3unZS3H5VcUe2GNjHDuc2qAeCrPkkjw/0nBTwgfkD/U+Cduw5 0Nf/XQYzLYnm+EkflPU/6QEdiOYyJJdkkioe8oI6MfT2XUZB6zufFBDaTUslNIO+Lz+FEc1LV4I8 jJafYtJ5XLYeA3mSdJ5A80CewBRb7cPA3vp52PSkKHT33xofHk3ECbCRNY2AgNl8IxIZvvEkZmQa UcWvaBbVfDPJbyL5Tel8GcmX882A/kAcnlNA6qMJHsgfGHA/cuI4QWGC5Yzfc2pyEjjoOeC8XlHm XwQBGKwyFPeIUv9sqDeLhARkzxJ3Lx8i8yBoCm3l/o7lcVEx1SFU6RCV0IMy0wPUaKNtQDyTRssB WYd4moRsII7dcTEeIoP2ryYz8nhAH2rn60RZID1JaYAMFImPGvlyKk5kflHl3w8tYIzZlBHSHCe8 wmBEHsFProGZL+eh1vKEB3ZAgpbPB2SUBMhPRfYNclaAVJcEQKhCUAEh00JElsX61VqVqCyBDuFH 0uoS6BB+8jgAhSyevu3PVICxOVENMwpMA2WmAUAHijrIXOC3HyZPqj5Duuk5hXr5m0VMIUqHkkOx qPV3DIGykG6vhhwe9L50Y+hL4SdZpI8z6Vw5WbmGKrR9pybH+VsIkWT/isO8iPr6CWIiJ+iQAoqP Xp0hDgLjVFydq6XZo6MK7bUbpOGl0E49SS+e1tWxYhgKwPs0RLdL+1ABCqNSVIGGBJPZrMuXyXQo HAqV6uz20gohAnQhOEtRlIsy0Vx1AUJFIZO53BxSs9Hi4qrSaOScsTZitNWei8B/LYlQZPG5nFdz SP45Q23k1f8w1Bqi8FJWiisrGpnqRrayIsDn6xg5X1lVFS13MxYzvOhYi8Vm4SuxwWsggamWWYt8 toBTP7PRU+pzKBP1d7S0LW906X31YU/AIjfejS9PyNihyzX4z1arv6gy6IhEa/nOXrOv3L3HXZIb bSsMNDa0FXvDwQKXbN0jj6TelDxwaaXkfz98FJYNf8wk+A6k+dJFYKd70TeBLFsW9AtRDwLmnoel XimnBy3OauWlSq9Sn4fZvMMCwtjJYqzUs3KLnVXZlErV8ZgS2SMhA4oabFF7EywVzLOcrvdCBiOq LQWNsxzAEAUgRLn9p0+TUOYU8v7vPcaxVy6TWcw2i7cS4AnmtJsh6Sow+gJBv5dlg6kFXp1xOLXA X1OSgx/Bajzb6i4NTbxSUa7jUgk8/DAeX1rQWbRM3twsCc+ZJbnu0sOdTUFlc7OspChvTt2vmSiB D0arJi9IZkpXAHxOp6FDjSOhUmdpB/B1MwmGVbKMyyVlpYcFl8TAQYFBr8c6Vm82q1n1YbOJwXqB 4zyKHXaARNfrAJ2ccy+dQ03vhZCdOwOQqg01EWBNvZWVEjqYvCCEP/cogtmE7Ff2cuVbWWkcG/gA oB1j4IzR8qqq6qhBJuPzfUxlhdEXLbdKZh6wD/c99NUv3dWxqNp8x7rvL3sh9c8d92L3cyu+Lq1K vbbh+tQvU79KvZv6Q9myeOqXOfb7cOSt/8IzH7MCIMCHgKT14NNxoWK0M4NHXlcxW3zYJbicx2Mu Vp/L5h7WC3rueEwv2xEMRnJ3WrIAeR1FQijHzlEoNGWTAAfB8Yl9EIy7Vps4LnezFrMMMEQu4wFB 2EpDRQkTrMTWaHl1FfkHLAFAyJnh8fOPXV/R0THzqe1rHknV+UMWmdQSCuBHjB3rOmuCM72+lU/e 1uiULqhY/+C5245e7J+30mJsVtkKm0rZJRGhwKFqvuRjPfai1nU3f/vpSzcxBGcoLCQPASzcqAh9 KQOLoMvDegBDXGa5uYgtOmyGHTseM7NShVxxPCa37/T5wnlop5ZCpBxwhIAECMo+BQ1CS/YIQRQC F/en95chx2u3jvvNaXqZAo23HNwhBBuClQQ1svDBKtBsJ/6UhQvTOnF56/l/HWpcmNxaW7tuYVvg w+Zqr1XRfCVInvjxvjMrJBtqb109vL2CyeDGXIBHGfjWfpGBR7UzJxyNhtkoMJQwMJRwWId15Wz5 YZ2g0x6P6diyfMaHMXM8hp05xbU7rT6+KVq8U56GD/dy+UtASLVpGAFfuXqh0/hPLQFX0ecfLsvJ PqtTMB4/wi0AoI2wccA5i9Vqs0GweAPBYAnD8wYzvLGGaHkjkBohwBsm/jYF0llbv9FY0R5s3bJs 9lCwqWh+bWpXXcdcvryyuk5XULV2efdwg233zoVXQtib71qwoXPZocWFKs/1vQcGB1XN3Q99a45g Tz3dWe/TSY5OvBTqGm48cIDgI0Z9kxfYF4GHlaFX09B/XO33F9vAXBHqgcPYkKPbkXAAH3OYzYRI BbOklPCxUn0Z8LGy4mKWZQ8Xmxx2e6F3N8eVFu6Wy6NIIIydCjnK014HFv9pTM0I7B924qOhCXP7 fEMLxZ/B3NJ9x01WoPA09gZLQMYS2Wq1GXjYBBDqFrIN6T3i8wNBw6uOLRtmLKktWTk4d2e8bNuf x+JfHb7DNKO/pXagonjNiu13tmz8zV0rXx3CPTdtKYi3NA72lgT7Vtzcuf3RuMmeem3e4nDBvJq6 BT0VwvZ7EtufGLJZMTjSCbzBLyv5LeB7Prozg+0BIwL0ZnV6IUeul7Pyw4Ke9YK7/XgMGQ1OraBz 7pTJfLzBiIHEu17/Vc457legRqQZABWkKArs8RygNfg0nULOJ/c3RfkfaxZP42ta8QD9gi+REuR0 szYL3l5UZpf11AuRfPUdkvvvMFmd7vxoYbuMsxXyzXJb0cxS9o+u+hXFeGnqkZhQ7DYqLzsrq/Mt Bikslqx5zuQFaR6suRSty6zZKpF7Wbc0L899PJbHmsJs+LBgMmlPYeUTpaXlwZ1T0vB11JRDpF9T RoEgC7Rcs/GUiPuoahwDLw9Wei2gPRnMOpbPL2Ey/D6T52YoUrC/1Aaq8SlfkVVW0Lfj6NC/nNk+ gzB7RlsYNCvMlUtmr0wWSgY6Z/j0GX42cdet4xvb3DNuOnE7sz/N7ZvVDl9dzcTaeXsWl/feexh4 Wz3oBxx7AXTIKPogs/IudSFb+JAgqLvVzHo1VqslekueZZeFVbEWp5NjuTHByRUExmMFCEfZCIpw EcYskUTYyH0SK8LqAolnJBqtVJgFS3ifgnK8l3LOGYhQsEWp3gB4QDQtEIBXCH2osXhDVkI0/N9n IcA0Mh1/9khxf5BIjkCgssLnT0sO4II88EagPitsCkEwL0sJkO4E8w1974PXLdw1E/S2QFFzSUlL lfapRdtuWhK55Z52mdacW5A6ZH/wSKy+pLd0r7S7vWl9x73ftC5dvKLQE5/3/cJwrka4e1dqW3M7 b9GqmvErkrXDjTPLeksADxlUAvsxKB2DU6mCKeoLymXjMbkSq9QFrE/vY31HQAuxulm7e0ywWnOM e73eIpVzJGe67AWUrM1C14CIVvtsWu5+el9AfUTvukbTuKmihA1W+kFFbgSMzMpbeRCbCdeikgFg dIxRgSaPbdtx/cDKuu9+d/ULYw/tnb0bexfEFw0tHAwvrJE0tc+p8ZiVzbqJf8PV9fylD7/99pba WiNu277lme89+9OSBVGgx0Hg+V8BvHSjrRmsdHPq3WoTaxoT1BySSFys64jEygl60Oc99r1pwQoI FAXmk9VN0yokMJ7nKU1+vINpiAKq7PTqcWyjWJHlwhaqe+pARFImzXZ3LfvB2v96c8c7X+55pPms vr7G3xJ1h5d1163CaHFi/uTfvv4/223mvy5Z6B+8f8uWR64rh70la/onrMkBZ5LPZlZV5zGxnjFh vQnrTXmmeaalJomVNZlUrAok2Zig4pADq1kHy1pZ6xGBtTqQcSQnJ99jGpFNbfdfz5ZnWBBVx+ky 0toWYD+1Y8jyI19wpCwFpXX8a3Ya90+HkdVG/r0UPtUs0VBlcvb3K3+25+13b3nt3sE7lnkCJjOe uB3v2jNn26ynJO3dXYPK768dmLz01XdvKeqsbOqZv/WJb9W248777zt6L+AAnLexAelROMP9VgZa 5SZBqWk36XfrARxjgh675eMxqXuW4NTzUG085s/NzTMJxjxnnkyTNyKRBANZmRQ9a4hygBuAItME U3mWRogmfo5SiPczx5guoj7WQbwa1CQDYR/VRH6DQUwhIbNYopa0KmXx9kX83LaI365juXd/vbDl gKHQGyoxPPMMV1iR0jXr8hvmMMOtckNuie/xJ3XPV1fUrl46Z8fEWGejT9MMp9m+lCDJBTwCXorm 4cIMbOKCZ25QpYgoqtnqMYFVKCIcRuXlUH+WUK6PNLANY0KE4+ay+rl5cyNzWRs7V9AZ2+cKnL2N bRuzuzrM0pZcDS/k8kWYKWeLkHRfXV1PxUgRRTSA21/PgpuAO3MmhzsH/1kTEHSoEODZFCDTjJfg H3B8e6SWynF4I+YzwcOZ/3/zFOyuKcz8YkPHcVAODN1MzASqTUWn2BjI3IqqaiICwK4kD8ribN7p vG1KAlAZwedLcr8lcflfPLe8qdxRX31x/Pgtbzy44dSeWe0ziwLBmRVzu1u2HFsUnevHqycWz5rT 2jGrY/Ysn8+/Y//OvfY24dEOdsCkdg3FHnvcWFzh9hj23HH9Az3mykWzahP57rm1kd6WgvBdicX7 +oIqWeonO7dv3LL9tk2XT7iaQ+2tfXPySz1pvaUOdLX9IC9mTEmLgqBBxxYVFo3HuELLDLeThX/g HFxN9XisBtVhxYjF0jDDM0LU367X06ZaE1hpmX1DxG6Igipjo7uV+6m9QaNrN4xjqrxOiU9wc1Ct hiqyIFIl1PUhIXlpoYJfGLyrc93N1azGEnCmnBFeq80rKwjMr2ZlamO+K2V155t0ElZlDhRhyw52 UU9Lz9gtqXvDXSW5ZvCBqItmL8XS5I0N7khPSerWmgZvjtUI+XKTI9gqsJqFPdVeswJEzrPAhztA 0DZIbwTKcKIfZKinlmVYdrmgZ+YxzCR4PJifML+HhESJGI5hOJYxnNDrdeMxvd4hcUrGY05sZIwj CkWuK8tgznBnsowFYMJ1/ZE4kZYs3rARlEOC96VfdIQpNnON7uIY3EVsBqhUKqdhin+Z+u81ZX6t 0hHKx6YdGeDZpTf+4x8fvqgtal+Kf1lW7zPJY4qJ2iyQqP5L8OgFwKN69KMMRKoKC8ZjhSgEdwrC IHYfEsLVOeGHSktrwQExHqvWSxV21inPyXGOx3KQuaJWJWsMm0fgZgjBKjBwzwBqZexbon4Q5RgW Qh0A1C/QRKES+iKjTPPRXbO7OM460oBG08YrtZqIm20aroElK6msIEo3KHqsAzO1VQXulK2Yj3bl ePJcpRp/9Ap8s97q5QtCAyXcdfjvwcQq5qbUngWCE7BLGciZ1bk5yBufX9oe0n4c2y4/ocvraYpY WzWCIKtPEDsD4MyUApxtqCcDZ4vFPB6zIBuWyGUgzWRoRKt12LNYlUWpNLT0V9dNQ8QO9EscZMRC vHKt+Plpi1FaKPFg77VnS/EAaEN2HmRLHP06Mz9B4VNTnRPULhxjBYnACkcECRc/cd11C8dj1+lt OWUVHdI5UUdn55zxWKdhxK0Ij9S4a2rcg3HUOtKdxgjAhtpIhAPUyHiG0r7WNG4TAyqtpWasPqqw fMGBM/TyGf2CYpdmTfQB9nRGwf+IQ+kkJI86ZNMEJslwrQx0s/aZP4p/oRk8PGf2sphlxZGe7tVg JlLu5S7O12ryI4GccLHHJJdyvD/lK+E1Uo3F6Xf5e6rVvuKUt9SvlZqCpdi4k+1nF7QFOmYsmVPU P7LoKp6mGdgguDhvflHFjNQPY+3hXBVhdh0JrGkerCnK0ZX0RlI7lnSG1M3NlLwfnA1ndqqYguAa 7KXkCOxlLbo/s5chG1PL5jhyxmPYYQme8Pt9oDLpCwy6YjDujwjFXHREJpvhLgiaRtx02wxRarZR 9RKolvqpCG+bJiE8n9XnFZIls99ZAUOdUBSgnwhkObU3shslOZJylvi0Mq3N5XMFems0/kgq9yNY 6jWNS1bV9q5tyaVb0awOdSzF6lmDdUGHJjI/ktq1dPbHQHU3W93kjwzsWZg6nBYnxA4DXV0SBdjp wQIZzEDPjqj5gaxKEKljgpLT7LXbPdxeCQUVKEhTnoCsDctd3WJKdaH6NNCslBqeUxYVVTgA64if TSZjZtz78s2zR35w/fsfbHsj9fjSROWskHHp4lhvgFv1h+/cfmZ3w+QHj727kdG/9GLVyrviv355 4aNk7vWpXskqmDsPHrOnMnOvINyFlY8LMqflhMlkZI3jgklfaivOAR/3ESGH8wbZ4JjgtebuLSqK Wqw+Fo2o6bpsGRUh7ePI0CcgAklROZcmXqotFHzeUa6EQxqzPt5hXJrlaBRFqKYgT5Nvxt0Lvslp xid+nmrQoF2zanMwgC3b9ZqFR+ZRK3TVcmKBXreoeEHV96giTfVs9vpZ9UVOsyKmuIed30FN0Rzc SAzR506XLKgElgjwTAA8dwM8c+GcbcofznFqL6v3Ems0jAokBWwBMEWr1WF3jMfszrBxJDe3xP+R Wfo6KOtEZk3XsmDB1NAmzM796f0RResTW8f9OvAQUuWVuCxs1TbqsiWSgMCNohLIwbTz4lL1wJr6 k99b9+v7Shd1z5i9mwMC0kULDb0LGuPFCwdLFlbdXtHgv/ThN9+5WWO11Rov3TinIV/X3KzJb5jL dm7bGv/XTc8+E+6fkeYvLOEvAfRvGSyrMWA1UnAKRskqJAKjNqrz1axBIoGDJCIyAid8Pn485tNn wKQQ5PKCAFi0uVMyAlT6rMj7CLsQaFIZ92HGiCj5YgNdpUpRf91VfWbkArhbib1GvXEf5/f/ru14 YKCh5QlDdYm1stgk0xWVp0wfcR+2h104R5v6S12jsyxaUZF6ZumcEBzJXcmYMeoBP8AAwC2SlbFP In7yrR8ouXYVz5v4U5NvCWXpF9ZmEkzg6RgzcSgCfoBIWAiDM3ssbLXbbMG8fXp9SXCfTFaGhBKA 4LWc2RmwNRFiJWniag6R81yifX18XO+njyuEpxxrn9ZxxpNNDKVpjmxL2pE95ccmSBus/LV9+LrO Lr5nWfVQe9HwM7d2HLpxxFbdXNI819W+asnWxvq1Xx78xi+wbnAwNrOwrjJkr+sYqB4YadOY3xba nPVVgapoKLjgxtk9W+b4I/9DdRg/wJeR/AbO8sYyeBk2KcGDZoJzTQ2rN80SOL1L0HDtLpedhX/i VzEa4SqTWacwZ/wqZ6PgLjgDvgKKK3bubIQechIPdhp2gvcz+5xich9rnXWcpP0EUYvX4iUkSyi0 mmX67+4+cu+OBnANSf8H56b+YCn3u8Jlzps7Gx75GhNpVRW0rO35cEeqYcPaqCrHTngURgLIq1G4 gV6M7sqsOWgoNiJUPB5DelYRcZ3IUee6WbkXhMARwuZd5hG1OsKM+KeEVxRYVFYPi3T9EQR/2k2d tgM/tbfMSqkKd1XTuAmWlvFhp88x6bvNIuWrs45XyJcEBbxPk18W8PfWygy+Qny71FgQSV24RalZ fHj2ml01YMqYvC72/MTLibVNuSXzI3hPx6wCp6Z5IjanrcipalHezS6Mzbv/Fryuph7O/I1yChfT 5AeSVoCLG63KwMWNdQY2V58jUVukbnfueMytl9vtNrk8V23wSAgninJn4cAfOA2KRAkIbESlJEza fK2mwFum1wLLjB7tm0zp03zq2pdjHpMjXEYWCefcfcxsLg3jfbl8XjiQ+tlTqYvO/EI3e75Z6fOV dqU68a7SDr6oWt7coswpmt830cX8c96MPBk5qMDIOfmBbBmsx4/2ZnFb7cpjFaZcLNU5eLlSqRiP KfXIaGFZP4I74phljBjeFI68oI444+nqbGR56R+K2KbPH46sP7FDWOoVdeNSluVZsjBiSgFh20ym 6FULZ9/+8W9/8TerO+DBb4P+r9rxpx/+dK9ZDwC4xe3N9fOpv6mYfRPbmX+2NfFgUikK/Y6G/NQQ 852JHry6arYrDQh7UXd8ogvWD1BgvwTrN6FHsuvnDIJJbQARMyYY9EiakL4ghZMKqUIJnxawaEyh Mklhcgq4xIDo+jNnEefAaxoBtkjE6jS/afqgiuy29zM6FhQAj4w+dK0e4n5Kz1GDtxITbU7OG7wW fO+LxU1Ry7bLjzHoudK6SN42dvaawJK+1NPNbIVnzgAuTe/zKtjszfA9BIt0T7Aig7/DkBP19+AK Drldszn1N1yS+k8oJzjxEOj5tXA+moOWZmBiM9qsgsWisMllSoXymzGFFY3qdC5n1qo8m5WxoLQS qUGWy13dZkpoTlUCC5MehoBzM6NXgPs/KrOw+Vpv45Kuy4/cuLTclud0DA43MKrdMmyrm+G3qJnB Qakhv7GNebHQVzJrDa5NwEdBZN5rYd42mHcQ3ZOZdyEcPuvlEkGad4deXxiU6615VkbPWp1OUFiP gc0tCcpBT31AkGdADwro2awmSq6i4Ai5qNT1V3D0EsPlHFlYzhfuBfRyP71hwpI7OcShS5UocihE jj7o2Qe5nmFh3p8p+DWbbJfXFh3buHZDzbIF3avtj28b3T/v3h/On3HPo123e/5hikRSDzQn3rh9 19cPz123Y8O2v5QFzfP2D8w78NhXO+8PqdKw2AX82wqwKEZ/zcCiXaPO5/l8Nv+YwLNm/tjNpXr4 NgmggViBhQO6Y6x8vR3r7VjJ2uE2BmgJx8wOjVrO80g+GuBG3e6IrRg5BBvVDF6i8Oh6nVw7iJCb B+T6TkaGL57SDgCCoHWlkZq4bAn4Kr/4PASzIyv7PscQcVMlOMozULV8dMJdGSUSkeiv5JpZxiSS H574j+1PrYptX3bdXQs2/OnrG37T83jumoUvHRmb99jjAwvL5s/USzTvrY3tXbzgtkSJUr/w7qWb n1hV6L+0cRWW3Tm6UX7kzhs3hK5fSPR6OO6W7IK7Y0446f73DNTrvR65UoE4ULbULpNc7mKfdb3s +qOLhSwNy7mOgsrqVMoc0Oh4zMkJBrUy18OaD0qlPhc5g0qjny1aDlxmOpF1TRD0XEy4jSEKKWJX U/AWf6EBr6DJT+gz7gfyrASmAyNRLJbzlrQ/A9C5oprH+HVfyCqbeItZ+jr4WHO1qzWTKnuRJ4Xf xQtVqtQJuKwRbIwcWcsmLz+m9ZW8eqSyyW9SNjOqP959bGIija9fAXytln4ZBbA/AzmtVp2rLlaz dolLzergI5XvuTzt5Ck0G23tOvVRQe/CLpePnCVHLKyWtXAcKF8PcLL1GOvhQh6LfYIP7qEd8zkY 5Dik1yuQRbB6RhUKOGe2A9ICXWfPkTtFHXyz5PDUxLn0ad8VeAZMAUAMDeDwa+JsKBQiBgTB5U+e Y/kXnKPguzaKf8LQ8eo0NmfQWB40eDMMxpBxlNPrS4GvPOFYd90Nw7fvKtsQHmDm+fOt2nXmiQfq dwze+qNVt77ztdW/afzwhuv333nwsFFbw3xLZfeknkmNGQ2LvrN19EeLi8jeMGgd7E0CeIkdFaJv Z3anTOpQOFjHUUGhsHNanAsf8xHVF7P4qGCXc5TNcA6M8zQHg8GQJO+gGUCeOR6AmzEZNTjNagGY gL1Tso8A1v+5us8yhYzz4GP9EN0JZQz8zAEzOYwx+qoxsciICUt5MXvqt6kLxaq5Dy3Z9I2+9W9/ 88Hfb30Wr/lj6nLZwmabauXq+p5y61Kpp1GauvQ3SVX5ilPb9v37xlvf//Y7eNufuImB3LK8uo4f nCqZv2XWXeSccefkhGQh3P3Qoesz0LIhmVYrYzWy+7UyuLnOaKQIcWpBQ1kp4BWh8ijFwSeRFD4a exJuop6viaNIE9AkvTVKsW2qFwG6AdIF8E0Vg68arspWeuk1WpNXsnDi5XP4g1RLuCrfotmcwz4t NX34Tiv7T70ur7wSHyPykuwtOlbq/MlSff0/kBp8fPD33LzDb2WfkxdTguw8nJhi+JIV6tI/aCd/ IFULH/aqLl9MJVUnaE+ZQvookMbQ0/jf4AZk9eRFyX1olfRrKCF5GyWknfB0oj5pLmqWrkZzJO2o XvIjVMKeRoOSJjTIHEWNkkLkk5xFdcwI6pD8GJ43oTp5HqRfgvAvUO852ibBnkQd7KOoh/kL8kOe AO1NsuXIyb6MmvFv0SrJU+ghCGsh7IJQAeErENZB2Amz3IP2YCM+zoSZx9nNkrDkONz6fUe2TvaK fL38spJRHlUFVL9RF2k4zWNajfZxuIX3O/0hTsYd5j40bDP8t1FiTBj/ZHrY3GjRWL5ugVvDFAoF 6ADco07A98AMAgsbrQDt8mFcCFoXgTaG737JE1zioG+igbmzW/tmhVqGbli2cfVQcfONa5NQ9CTy YPfjSjue7TmFc7MJVzZhyyas2YQxmzBkE/psQptNqLIJZTahyCZk2YQ0m5AIk3T4SzT+kMbv0PhN Gv+Bxq/T+DUav0LjF2l8jsbP0/jnNP4Zjc/S+AyNf0rj0zR+isYnafwdGh+i8UEaj9L4DhrfTuN9 NB6h8V4a76HxbTTeTeNdNN5J4x007qFxN407aNxO4t+ft9pcL70M0fZbrc7ttzp++Z+Q3iokboLH DeshWnsjRNevszqvX7drY87mLWaLa9UaiFauhmjFsNm5YnjfhhzHJuu2Fof3Fgjy52zPMX9+C4c2 fw/bnsbBXyWeXv/07qcl9z/AhIQH8NJ78T2HmRC5a8i968ytVS63L39uOetZrtXXkszwrDx/LXdi xc7ah8b4PPuXA0W1Xx7DofYxfN8RJsQdaRJq/+sIVotOcURkZ2qxHAMrgUM1WeYpyTylQscoCh2E cAeE0X2y0G27cGjHTmlo50h+3oF9OLQfwsg+aWgvBGe1xV5lsVRajBUWfdSiKbcoyyyyUgsbsaAS yynsEXa3NHoDQV1BUK8vwgUXJ0MX/6n/4H91f/+HrvSD0ovMhYu4KKQLh/T5vM7H6915Ok+eXs8Z NEqVWiOTKzSsRKpBmNHI2GSeWt+pZ9RwxBxjVyo3s/uV30LHlb/VK9UIlCT9DDRDGWcHlVvZzfoH 0YPK+/VPKn+DdE/C7ah8wah34lytXZ6jtXA2rVFi1ubN1GEvISuIOQgRCE0QjkH4CfYKAVm4vqi+ oD5Q76vPr/fUu+ud9fZ6S72xXl+vrJfVs/Wovjvah0VjJ+rsaxZNGJ7zm8VoqPMU6+kVy0OdorJ7 sP8kxv8Sh1yROQBfC/WJkgPwIUQffIc6MNh/CjtI8T5wgGGMxM7EvjvjoVCumCQf3e3OjYvlJHF3 bhy+IyzvEZ18M+gQV/5t2kzfN23eMj1/k/j3VvFi6+oh8SJ85voBfCV6sTUhfsDHNpFam8SiVjHc OiQWQGaAj01vGcJXvIU2IRggPQZ5bNoU2rR5E0mJdrEJ1ntl7VDopJIsvLu3GT7cWtQpJuHzSWf3 YELM4ZvhW2B4q+oehM/qmk8i+NDrJHx21XdSBtHgYP/MXPiUPYlzIbgg2CBYIRghGCDoIWghqCAo ISggyCBIIUiEruSl5IfJd5JvJv+QfD35WvKV5IvJc8nnkz9P/ix5Nnkm+dPk6eRTyZPJ7yQPJQ8m R5N3JG9P7kuOJPcm9yRvS+5O7kruTO5I9iS7kx3J9uTVi/pc77Bz/4c/9P8AxCtfDAplbmRzdHJl YW0KZW5kb2JqCjQ0IDAgb2JqCjEwNjQ4CmVuZG9iago0NSAwIG9iago8PCAvVHlwZSAvRm9udERl c2NyaXB0b3IgL0FzY2VudCA5NTAgL0NhcEhlaWdodCA2NzEgL0Rlc2NlbnQgLTIyMiAvRmxhZ3Mg NAovRm9udEJCb3ggWy0zNzkgLTIxOSAxMzMzIDk1MF0gL0ZvbnROYW1lIC9aTkpFVEcrQ2FtYnJp YS1Cb2xkIC9JdGFsaWNBbmdsZQowIC9TdGVtViAwIC9NYXhXaWR0aCAxMzgwIC9YSGVpZ2h0IDQ4 OCAvRm9udEZpbGUyIDQzIDAgUiA+PgplbmRvYmoKNDYgMCBvYmoKWyA1OTIgMjMyIDU3MyAzMDgg MzE0IDUzMSA2MDQgMzY1IDIyMCA2NTIgNTk3IDYxNCA0NjEgNTY5IDMyNiA1OTIgNTMxIDQ1OQo1 MjAgNTkyIDcwNSA0NjkgNTk3IDY3NiA1OTcgNDc5IDUzNSA1MTMgNTkyIDg5MCA2NjIgNTkxIDc5 OCA1OTIgNTkxIDU5MiA2MzkKNTkyIDU5MiBdCmVuZG9iago0NyAwIG9iago8PCAvTGVuZ3RoIDQ4 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdk81q20AURvd6ilmmi6CxRrYc EIKQEPAibanbB9DPyAhqScjywm/f812nKXRxhD/N3DtzxqP05fB6GIfVpd+XqT3G1fXD2C3xMl2X NromnoYx2WSuG9r1I9m79lzPSUrx8XZZ4/kw9pMry8S59Acll3W5uYfnbmriF737tnRxGcaTe/j1 crQ3x+s8/47nOK7OJ1XlutjT7r2ev9bn6FIrfTx0jA/r7ZGqfzN+3ubo2BEVm/uW2qmLl7lu41KP p5iU3lfl21uVxLH7byjs7xVN/zE121Sl8D5sq6TMMiJ4n0XFQATv86CYE8H7Xau4JQLxSXFHBKK1 KohAtFZ7Inhf5Jr8RBSeJ7HmJ7DQRrEhApO9YksE77cWOyIwmmk0EoGFesWeCMQdMXAWAkF15mFQ a6O4BvMtJBhwFdQWirgKarUQJ2SwSSkEXAWTrRbXcPfdaxRXwZ51GgFXwboWcQ3mW9QaxVXQyjaJ a7j7Wmdcg/myNybjKpjcKeIqWEibzHEVLKRWHKdBlFGOq8BICvyrBq2sFlfU1LnRKL6CzjYZ19wE sdbd+nuJdM30OXxe3/a6LNxc+2bsUuuyDmP8/KzmaVYD4w/wEedQCmVuZHN0cmVhbQplbmRvYmoK NDggMCBvYmoKNDU5CmVuZG9iagoxMSAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1 ZVR5cGUgL0Jhc2VGb250IC9aTkpFVEcrQ2FtYnJpYS1Cb2xkIC9Gb250RGVzY3JpcHRvcgo0NSAw IFIgL1dpZHRocyA0NiAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgNzEgL1RvVW5pY29kZSA0 NyAwIFIgPj4KZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxlIChPQXV0aCBXUkFQIENsaWVudCBPbmx5 IFByb2ZpbGUgXChkcmFmdCAyMDA5LTEyLTE2XCkpIC9BdXRob3IgKEx1a2UgU2hlcGFyZCkKL1N1 YmplY3QgKCkgL0FBUEw6S2V5d29yZHMgWyAoKSBdIC9LZXl3b3JkcyAoKSAvQ3JlYXRvciAoTWlj cm9zb2Z0IFdvcmQpIC9Qcm9kdWNlcgooTWFjIE9TIFggMTAuNS44IFF1YXJ0eiBQREZDb250ZXh0 KSAvQ3JlYXRpb25EYXRlIChEOjIwMDkxMjE3MDc0ODU2WjAwJzAwJykKL01vZERhdGUgKEQ6MjAw OTEyMTcwNzQ4NTZaMDAnMDAnKSA+PgplbmRvYmoKeHJlZgowIDQ5CjAwMDAwMDAwMDAgNjU1MzUg ZiAKMDAwMDA3Mzg4OCAwMDAwMCBuIAowMDAwMDA2NDU4IDAwMDAwIG4gCjAwMDAwMTg1NTIgMDAw MDAgbiAKMDAwMDAwMDAyMiAwMDAwMCBuIAowMDAwMDA2NDM4IDAwMDAwIG4gCjAwMDAwMDY1NjIg MDAwMDAgbiAKMDAwMDAwNzYxNCAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwNTU3 NjEgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMDczNzIxIDAwMDAwIG4gCjAwMDAw NjE4MjYgMDAwMDAgbiAKMDAwMDAzNTg2OSAwMDAwMCBuIAowMDAwMDA2Njk5IDAwMDAwIG4gCjAw MDAwMDc1OTQgMDAwMDAgbiAKMDAwMDAxMjM5NyAwMDAwMCBuIAowMDAwMDA3NjUwIDAwMDAwIG4g CjAwMDAwMTIzNzYgMDAwMDAgbiAKMDAwMDAxMjUwNCAwMDAwMCBuIAowMDAwMDE2NzA4IDAwMDAw IG4gCjAwMDAwMTI2NDIgMDAwMDAgbiAKMDAwMDAxNjY4NyAwMDAwMCBuIAowMDAwMDE2ODE1IDAw MDAwIG4gCjAwMDAwMTgzMDcgMDAwMDAgbiAKMDAwMDAxNjk1MyAwMDAwMCBuIAowMDAwMDE4Mjg2 IDAwMDAwIG4gCjAwMDAwMTg0MTQgMDAwMDAgbiAKMDAwMDAxODY1NiAwMDAwMCBuIAowMDAwMDE4 NzA2IDAwMDAwIG4gCjAwMDAwMzUzNDEgMDAwMDAgbiAKMDAwMDAzNTM2MyAwMDAwMCBuIAowMDAw MDM1NTkxIDAwMDAwIG4gCjAwMDAwMzYwNDkgMDAwMDAgbiAKMDAwMDA1NDUwNyAwMDAwMCBuIAow MDAwMDU0NTI5IDAwMDAwIG4gCjAwMDAwNTQ3NTAgMDAwMDAgbiAKMDAwMDA1NTA0MiAwMDAwMCBu IAowMDAwMDU1NzQxIDAwMDAwIG4gCjAwMDAwNTU5MjMgMDAwMDAgbiAKMDAwMDA2MTU0MSAwMDAw MCBuIAowMDAwMDYxNTYyIDAwMDAwIG4gCjAwMDAwNjE4MDIgMDAwMDAgbiAKMDAwMDA2MjAwMyAw MDAwMCBuIAowMDAwMDcyNzQyIDAwMDAwIG4gCjAwMDAwNzI3NjQgMDAwMDAgbiAKMDAwMDA3Mjk5 MCAwMDAwMCBuIAowMDAwMDczMTY2IDAwMDAwIG4gCjAwMDAwNzM3MDEgMDAwMDAgbiAKdHJhaWxl cgo8PCAvU2l6ZSA0OSAvUm9vdCAyOCAwIFIgL0luZm8gMSAwIFIgL0lEIFsgPGVkMWVmNjQ3MDM1 NGUzODdmOWQwN2IyOWI1OGZjYmIwPgo8ZWQxZWY2NDcwMzU0ZTM4N2Y5ZDA3YjI5YjU4ZmNiYjA+ IF0gPj4Kc3RhcnR4cmVmCjc0MTg3CiUlRU9GCg== --001517740988bec4f0047af0d033-- From olivier.miel@gmail.com Fri Dec 18 02:46:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90253A683D for ; Fri, 18 Dec 2009 02:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rt6Crkg5Xif for ; Fri, 18 Dec 2009 02:46:56 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 865E23A657C for ; Fri, 18 Dec 2009 02:46:55 -0800 (PST) Received: by fxm7 with SMTP id 7so2761982fxm.29 for ; Fri, 18 Dec 2009 02:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=BLDcBRDuSakKrG40tfeOuUnVNpY3hCX2t1jDyIvZcsU=; b=Eg0Lep+XHiYw6D1ZjI41CCrW+n/ftmtpGOF67I/KJMcYZ7iA430hQQXaSPsp9PmfEX x16dFYlio1ciTPfEbRLJ1m5pln876+2t1qOsj3dziGc+9EfeeUVU6yi7eARYqIRXJ92w WZDLRRx4oErtbSFsOqyS4+A4fmqZVxexq7+7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=U6cCEOh2gci28onvD44yREM09eS44seKmgXr54X4dhFOh+I2d695CwKw3U5Dc5js8p dM2/J+K5YVSZt2d4pZHcmES6F4tfMV5XqYUPrp4Me2s5BQi9Tb9zW1zqCZfCUwwH2XGz ujmQD+DLSJqQDFX0zaLIN1xELKKCIIE9/6klo= MIME-Version: 1.0 Received: by 10.239.139.39 with SMTP id r39mr393590hbr.116.1261133196837; Fri, 18 Dec 2009 02:46:36 -0800 (PST) Date: Fri, 18 Dec 2009 11:46:36 +0100 Message-ID: From: Olivier MIEL To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] draft-hammer-oauth-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 11:03:16 -0000 Hi all, sorry to intrude, I'm currently implementing OAuth 1.0a on my own (http://code.google.com/p/pledge-oauth/), using the last (to this day) draft of the upcoming RFC as a basis and I may have some issues with it: 1> (http://tools.ietf.org/html/draft-hammer-oauth-08#section-3.4.1.2) The draft-02 included a requirement to normalize empty paths as "/" (http://tools.ietf.org/html/draft-hammer-oauth-02#section-3.3.1.3) when computing the signature base string ;=A0the current draft does not explicitly, but the fact is still mentioned in the version notes appendix (http://tools.ietf.org/html/draft-hammer-oauth-08#page-39). It seems to have been dropped in draft-04, when the example switched from using URL to proper HTTP requests (http://tools.ietf.org/html/draft-hammer-oauth-04#page-17). Some implementations - most of those I reviewed* -=A0still support this some way or another=A0(out of RFC 2616 section 3.2.2 conformity).=A0Is it still an implicit requirement ?=A0(I'm assuming it is) 2> (http://tools.ietf.org/html/draft-hammer-oauth-08#section-3.4.1.3.1) Shouldn't the OAuth parameters be collected from one source only ? There is an ambiguity : it is explicitly required that client send their parameters either in the 'Authorization' header, in the query or in the body of the request and in only one of those only, but there is no matching requirement on the server side. It could be interpreted as some leniency on the server side of the implementation ; or maybe it's a wild assumption on my part ? (I'm assuming it's the same on the server side) 3>=A0The specification (section 2.) prohibits "oauth_" parameters in end-point URLs but do not (explicitly)=A0in call-backs.=A0Is it implicit ? (I'm assuming it is) Those last two are more nitpicking on my part (I include them just to be consistent with the list of I had prepared :) ) +> (http://tools.ietf.org/html/draft-hammer-oauth-04#section-4.4.2) HMAC-SHA1 specifies how to encode bytes, not strings ; there is no mention of what encoding should be used to decode the key and signature base string into bytes ; of course, the percent-encoding turned everything into proper ASCII characters, so ASCII and UTF-8 are equivalent ; just nitpickin'. +> Stale timestamps :=A0it is not specify whether this case should be a 'bad request' or an 'unauthorized' kind of error (I'm assuming the former). Thank you in advance for your comments. I don't have much experience with standardization efforts ; I pray my ramblings can be of some use. I'll continue to review the specification along my implementation effort. I hope I can be of help in fixing some ambiguities. Olivier MIEL. *=A0namely: googlecode OAuth java (http://oauth.googlecode.com/svn/code/java/), signpost (http://code.google.com/p/oauth-signpost/), asemantics-oauth (http://code.google.com/p/asmx-oauth/), spring-security-oauth (http://spring-security-oauth.codehaus.org/) and the OAuth bits in the GData java client library. N.B. : (about 1>) what about OPTIONS "*" requests ? Maybe the server hosting protected resources shouldn't be considered a protected resource itself. From eran@hueniverse.com Fri Dec 18 09:25:38 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B523A6A7C for ; Fri, 18 Dec 2009 09:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RuPkYPxDtt8 for ; Fri, 18 Dec 2009 09:25:37 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 33B8B3A691B for ; Fri, 18 Dec 2009 09:25:37 -0800 (PST) Received: (qmail 31794 invoked from network); 18 Dec 2009 17:25:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Dec 2009 17:25:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 18 Dec 2009 10:25:16 -0700 From: Eran Hammer-Lahav To: Olivier MIEL , "oauth@ietf.org" Date: Fri, 18 Dec 2009 10:25:04 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-08.txt Thread-Index: Acp/0a0enS6SLUvBQeKmqPQIYLiflgAM8CdA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787DCF30B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] draft-hammer-oauth-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 17:25:38 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Olivier MIEL > Sent: Friday, December 18, 2009 2:47 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] draft-hammer-oauth-08.txt >=20 > Hi all, sorry to intrude, >=20 > I'm currently implementing OAuth 1.0a on my own > (http://code.google.com/p/pledge-oauth/), using the last (to this day) dr= aft > of the upcoming RFC as a basis and I may have some issues with > it: >=20 > 1> (http://tools.ietf.org/html/draft-hammer-oauth-08#section-3.4.1.2) > The draft-02 included a requirement to normalize empty paths as "/" > (http://tools.ietf.org/html/draft-hammer-oauth-02#section-3.3.1.3) > when computing the signature base string ;=A0the current draft does not > explicitly, but the fact is still mentioned in the version notes appendix > (http://tools.ietf.org/html/draft-hammer-oauth-08#page-39). >=20 > It seems to have been dropped in draft-04, when the example switched > from using URL to proper HTTP requests (http://tools.ietf.org/html/draft- > hammer-oauth-04#page-17). >=20 > Some implementations - most of those I reviewed* -=A0still support this s= ome > way or another=A0(out of RFC 2616 section 3.2.2 conformity).=A0Is it stil= l an implicit > requirement ?=A0(I'm assuming it is) It is still a requirement but it is implied from HTTP. Since HTTP requires = normalizing empty paths as /, the specs assumes you are sending proper HTTP= requests. > 2> (http://tools.ietf.org/html/draft-hammer-oauth-08#section-3.4.1.3.1) > Shouldn't the OAuth parameters be collected from one source only ? > There is an ambiguity : it is explicitly required that client send their > parameters either in the 'Authorization' header, in the query or in the b= ody > of the request and in only one of those only, but there is no matching > requirement on the server side. >=20 > It could be interpreted as some leniency on the server side of the > implementation ; or maybe it's a wild assumption on my part ? (I'm assumi= ng > it's the same on the server side) oauth_ parameters should only be sent in one place, but all parameters are = signed, not just the OAuth ones. > 3>=A0The specification (section 2.) prohibits "oauth_" parameters in > end-point URLs but do not (explicitly)=A0in call-backs.=A0Is it implicit = ? > (I'm assuming it is) No. What you do in your callback is up to you. There is no potential confli= ct. > Those last two are more nitpicking on my part (I include them just to be > consistent with the list of I had prepared :) ) >=20 > +> (http://tools.ietf.org/html/draft-hammer-oauth-04#section-4.4.2) > HMAC-SHA1 specifies how to encode bytes, not strings ; there is no mentio= n > of what encoding should be used to decode the key and signature base > string into bytes ; of course, the percent-encoding turned everything int= o > proper ASCII characters, so ASCII and UTF-8 are equivalent ; just nitpick= in'. Why decode when you can just create the same string again and compare the f= inal result? > +> Stale timestamps :=A0it is not specify whether this case should be a > 'bad request' or an 'unauthorized' kind of error (I'm assuming the former= ). Same as bad nonce value. EHL From chris.messina@gmail.com Fri Dec 18 18:01:15 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D064C3A67F5 for ; Fri, 18 Dec 2009 18:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qf5StYnqsnuR for ; Fri, 18 Dec 2009 18:01:14 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id A80083A6807 for ; Fri, 18 Dec 2009 18:01:14 -0800 (PST) Received: by yxe30 with SMTP id 30so4167120yxe.29 for ; Fri, 18 Dec 2009 18:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=X8E5ChjClZddneIzd8MT/uVTsj/1tmCXZWVtQl7+qB8=; b=sR/HzKyVSvS/llv2Btn6+I5oJFnXHVATbqbbCgqmPNN63RO57NLSFfuydalNJEgID5 70I+NXWYf9h3l8KNcoroub/c67eHPKKj+pGjIAtVpc7FRJYk/Sp0XP8egspiBGmsW+o6 By2XQxbFPLb2pRCqdUJMasS1Ijd33MF1/6uYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KnsDpIiwA5HKzeEv1LhVqxwElUFIEZiHAl09vju32zej67nYCY0rABblA8XPpurT6h 5FaROALnaIfsVEuL0CA84KW26fAgk8aDznEsKRPT48B4axw1MZY2TrgIK9c1sLzVy3af aaHYVbYtyVI3/JQowMFiBJGWZB65RCvWJTV2g= MIME-Version: 1.0 Received: by 10.150.21.22 with SMTP id 22mr7628346ybu.36.1261188057042; Fri, 18 Dec 2009 18:00:57 -0800 (PST) In-Reply-To: <1b587cab0912170827p4fd34d08w9045b88d07bf9a43@mail.gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E72343785293899@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343785293C44@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1124AA95AD4@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090042v2c116af3lc5ad5acf9d29d7d8@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB101AE@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912090751v50ef98b8nab1ddcc266fd729d@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124AB83C38@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912100148n18be4450if1de9ddc313e589e@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1124D53D750@WSMSG3153V.srv.dir.telstra.com> <1b587cab0912170827p4fd34d08w9045b88d07bf9a43@mail.gmail.com> Date: Fri, 18 Dec 2009 18:00:56 -0800 Message-ID: <1bc4603e0912181800n59819c77tb1c308953e613b1a@mail.gmail.com> From: Chris Messina To: Ben Laurie Content-Type: multipart/alternative; boundary=000e0cd63c822290e8047b0b3a0d Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Request for proposals on bootstrapping usernames X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 02:01:15 -0000 --000e0cd63c822290e8047b0b3a0d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 17, 2009 at 8:27 AM, Ben Laurie wrote: > > If you have as a design requirement that the server should store a password > in the clear, then indeed there's no advantage to Schnorr. I thought no-one > wanted to store passwords in the clear anymore, though. > > ...and yet apparently they still do: http://www.techcrunch.com/2009/12/14/rockyou-hack-security-myspace-facebook-passwords/ Sigh. -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] shareable [X] ask first [ ] private --000e0cd63c822290e8047b0b3a0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 17, 2009 at 8:27 AM, Ben Laurie <benl@google.com> wrote:

If you have as a design requirement that the server should store a p= assword in the clear, then indeed there's no advantage to Schnorr. I th= ought no-one wanted to store passwords in the clear anymore, though.


...and yet appa= rently they still do:


Sigh.

--
Chris Messina
Open Web Advocat= e

Personal: http://factoryjoe.com<= /a>
Follow me on Twitter: ht= tp://twitter.com/chrismessina

Citizen Agency: http://citizenagen= cy.com
Diso Project: http://diso= -project.org
OpenID Foundation: http:/= /openid.net

This email is: =A0 [ ] shareable =A0 =A0[X] ask first =A0 [ ] private --000e0cd63c822290e8047b0b3a0d-- From olivier.miel@gmail.com Sat Dec 19 04:28:29 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC903A6810 for ; Sat, 19 Dec 2009 04:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6R9FbESwXyos for ; Sat, 19 Dec 2009 04:28:29 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 855D63A6781 for ; Sat, 19 Dec 2009 04:28:28 -0800 (PST) Received: by fxm7 with SMTP id 7so3635688fxm.29 for ; Sat, 19 Dec 2009 04:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sEZtiSuwIC2elC1xUbB51ENqxRFyFWkHJKnHmF2jQeE=; b=ac7z46XG5xGzKISOZv9ec2SieZc6QEsL97DoNONsASpmjjo4C0Pmo9eBT8pdc11nxt aazREHSRWY05X6s6dymWuiAPVj+Ju29GUwY4JLFmqzuvSOipop8Uc72Jk9llXYvawZBD ++EPOuvUK1WnD5PD7JqcVXptKhq5dc30l7igM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bZVGABlir9zg0ebIiYVl73Q/BmU7KOVlyKSL1ypOI33cmXHpNEMxV4mNEYNAc/QZ2b G1Gl+e6mc4EIVSqPaJYtqPl6cbh7crdlnVp0REpm6j2wA52JaTsGAfwiwb9EeNwqDm0E FltkXSu6lIrhf2bmBsw+Ini+ri5WpOg65hYUo= MIME-Version: 1.0 Received: by 10.239.139.72 with SMTP id s8mr510996hbs.25.1261225688919; Sat, 19 Dec 2009 04:28:08 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343787DCF30B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343787DCF30B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 19 Dec 2009 13:28:08 +0100 Message-ID: From: Olivier MIEL To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-hammer-oauth-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 12:28:29 -0000 2009/12/18 Eran Hammer-Lahav <>: >> -----Original Message----- >> 1> (...) >> Some implementations - most of those I reviewed* - still support this some >> way or another (out of RFC 2616 section 3.2.2 conformity). Is it still an implicit >> requirement ? (I'm assuming it is) > > It is still a requirement but it is implied from HTTP. Since HTTP requires normalizing empty paths as /, the specs assumes you are sending proper HTTP requests. Sending and receiving, yes, I understand that. >> 2> (...) > > oauth_ parameters should only be sent in one place, but all parameters are signed, not just the OAuth ones. I didn't meant that parameters from one source or another should be excluded from the signature, I wanted to know if, given a client that screwed up and distributed the parameters in several source, should the server respond with a 400 code ? In retrospects, the question seems futile, though. >> 3> The specification (section 2.) prohibits "oauth_" parameters in >> end-point URLs but do not (explicitly) in call-backs. Is it implicit ? >> (I'm assuming it is) > > No. What you do in your callback is up to you. There is no potential conflict. Point taken. >> +> (http://tools.ietf.org/html/draft-hammer-oauth-04#section-4.4.2) >> HMAC-SHA1 specifies how to encode bytes, not strings ; there is no mention >> of what encoding should be used to decode the key and signature base >> string into bytes ; of course, the percent-encoding turned everything into >> proper ASCII characters, so ASCII and UTF-8 are equivalent ; just nitpickin'. > > Why decode when you can just create the same string again and compare the final result? I'm not suggesting to decode the signature into bytes. What I meant is that there is no suggested scheme to convert the signature base string and the key into bytes before applying HMAC-SHA1 to compute the signature. The signature base string is composed of characters either being "&" (ASCII code 38) separators or characters from percent encoded strings ; these last ones are either preserved UTF-8 characters from the unreserved set or percent-encoded UTF-8 characters. All characters belong to the ASCII set, so all character-encoding that extend ASCII will bear the same result (i.e. ASCII and UTF-8 are equivalent). But if I'm using a character-encoding that's incompatible with ASCII - such as UTF-16 - I won't get the same bytes and some implementations may be incompatible. >> +> Stale timestamps : it is not specify whether this case should be a >> 'bad request' or an 'unauthorized' kind of error (I'm assuming the former). > > Same as bad nonce value. Okay. Thank you for your swift response (and for your patience). Olivier MIEL. From eran@hueniverse.com Sat Dec 19 08:16:31 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6403A6AE2 for ; Sat, 19 Dec 2009 08:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id recaNhpiI44e for ; Sat, 19 Dec 2009 08:16:30 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3EB9F3A6ADB for ; Sat, 19 Dec 2009 08:16:28 -0800 (PST) Received: (qmail 2111 invoked from network); 19 Dec 2009 16:16:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Dec 2009 16:16:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 19 Dec 2009 09:16:12 -0700 From: Eran Hammer-Lahav To: Olivier MIEL Date: Sat, 19 Dec 2009 09:16:03 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-08.txt Thread-Index: AcqAprpyEidVNzTtRranFHTtrphueAAH8STQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787DCF524@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343787DCF30B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-hammer-oauth-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2009 16:16:32 -0000 > -----Original Message----- > From: Olivier MIEL [mailto:olivier.miel@gmail.com] > Sent: Saturday, December 19, 2009 4:28 AM > But if I'm using a character-encoding that's incompatible with ASCII - su= ch as > UTF-16 - I won't get the same bytes and some implementations may be > incompatible. The encoding section requires UTF-8. EHL From Jeff.Hodges@KingsMountain.com Mon Dec 21 16:24:00 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB86328C0D0 for ; Mon, 21 Dec 2009 16:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51dDtK3DXHhI for ; Mon, 21 Dec 2009 16:23:59 -0800 (PST) Received: from outbound-mail-123.bluehost.com (outbound-mail-123.bluehost.com [67.222.38.23]) by core3.amsl.com (Postfix) with SMTP id 8C6F43A67DF for ; Mon, 21 Dec 2009 16:23:59 -0800 (PST) Received: (qmail 18638 invoked by uid 0); 22 Dec 2009 00:23:43 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by outboundproxy4.bluehost.com with SMTP; 22 Dec 2009 00:23:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:X-Identified-User; b=PucwCE0TvS63zy2iEltoSLFPfhaMEEqbSkhUSyfdCAA1KxJiaXqqKqOIgXYcwJ6L3KC6Jhi8RBwDa1e2veuqT/wTlhyuQ2+to4vMpwd2vHJGIilnE6MPlZVwsvIkyAB2; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.91]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NMsXO-0003q2-5q for oauth@ietf.org; Mon, 21 Dec 2009 17:23:43 -0700 Message-ID: <4B301195.4050808@KingsMountain.com> Date: Mon, 21 Dec 2009 16:23:49 -0800 From: =JeffH User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: IETF oauth WG Content-Type: multipart/mixed; boundary="------------040106090402000909020509" X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [OAUTH-WG] fyi: Cross-Origin Resource Sharing (CORS) [W3C] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 00:24:00 -0000 This is a multi-part message in MIME format. --------------040106090402000909020509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, At the oauth unofficial un-bar bof in Hiroshima (ietf-76 Nov-2009), I mentioned some work in the W3C WebApps WG called "Cross-Origin Resource Sharing (CORS)" which will essentially facilitate interactions between web sites on a user's behalf, and thus has similar user-visible functionality as OAuth. At the W3C technical plenary (in Santa Clara) the week prior to IETF-76, during the webapps working group session(s), Maciej Stachowiak presented a slide deck background/overview of CORS (attached below). Of possible interest to this group, at the end of the slides (slide 37) he contrasts CORS to OAuth. StPeter asked me to send a pointer to the slides to this list, this message is to satisfy that action item. A way to think about the apparent duplication of effort between OAuth and CORS is that OAuth is a means to do sharing between one's websites today, with today's deployed browsers, while CORS is ostensibly a way to do it in the not-to-distant future, with the aid of the latest generation of browsers (and thus an at-first-small(er)-user-population, but one which will grow as new browser generations are released and deployed). Also, CORS isn't (AFAICT) vying to become an HTTP authentication method. That all said, being aware of the CORS is of possible interest to y'all. HTH, =JeffH ------ Cross-Origin Resource Sharing Editor's Draft 5 October 2009 http://dev.w3.org/2006/waf/access-control/ CORS Background slides (Maciej Stachowiak) http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0468.html public-webapps@w3.org Mail Archives http://lists.w3.org/Archives/Public/public-webapps/ W3C Web Applications (WebApps) Working Group http://www.w3.org/2008/webapps/ --------------040106090402000909020509 Content-Type: application/pdf; name="Stachowiak-CORS-Background-2009-11-03.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Stachowiak-CORS-Background-2009-11-03.pdf" JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFtUE1Lw0AUvO+vmGMCNtmP5mOvDSp4ULQLHsRD jU0RSUuzVPDf+3ZfDlk1gQw7+95MZs54xBkSWkJJvUZTt5j2eMYRZecVeg8F3/+dGCCLWsYH H2FWC5qV8f1/PhgpKWGsRUtWupYLK81WKtqJpTZtRdUV3dF6XVn0IzYO7Zp5QqsKbRoD+sCN KG9UQYHgBvGCrHt42mKz6z8PUw4yzk6X43uOV7g7XDsqIFZQmDnNtiPZX31sUd56JQ4+bUXD QDXkVIUkQxRKuWWRMhS5SKOhWsFRlJ4jalRQ9OMhg54zgDK4HKsW2YXAItszeAbKEshdLgJ8 8+mKgBbAcM/kieGLYVYZ+fSWkBOLzeuG71JNzaRMwCa9/gDT2X96CmVuZHN0cmVhbQplbmRv YmoKNSAwIG9iagoyODUKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAz IDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCAx MDI0IDc4OF0KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwg L0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+ CmVuZG9iagoxMiAwIG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9BQVBMOkFBIGZhbHNlID4+ CmVuZG9iagoxMyAwIG9iago8PCAvTGVuZ3RoIDE0IDAgUiAvTiAxIC9BbHRlcm5hdGUgL0Rl dmljZUdyYXkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhVJPSBRRHP7NNhKE iEGFeIh3CgmVKaysoNp2dVmVbVuV0qIYZ9+6o7Mz05vZNcWTBF2iPHUPomN07NChm5eiwKxL 1yCpIAg8dej7zezqKIRveTvf+/39ft97RG2dpu87KUFUc0OVK6Wnbk5Ni4MfKUUd1E5YphX4 6WJxjLHruZK/u9fWZ9LYst7HtXb79j21lWVgIeottrcQ+iGRZgAfmZ8oZYCzwB2Wr9g+ATxY Dqwa8COiAw+auTDT0Zx0pbItkVPmoigqr2I7Sa77+bnGvou1iYP+XI9m1o69s+qq0UzUtPdE obwPrkQZz19U9mw1FKcN45xIQxop8q7V3ytMxxGRKxBKBlI1ZLmfak6ddeB1GLtdupPj+PYQ pT7JYKiJtemymR2FfQB2KsvsEPAF6PGyYg/ngXth/1tRw5PAJ2E/ZId51q0f9heuU+B7hD01 4M4UrsXx2oofXi0BQ/dUI2iMc03E09c5c6SI7zHUGZj3RjmmCzF3lqoTN4A7YR9ZqmYKsV37 ruol7nsCd9PjO9GbOQtcoBxJcrEV2RTQPAlYFH2LsEkOPD7OHlXgd6iYwBy5idzNKPce1REb Z6NSgVZ6jVfGT+O58cX4ZWwYz4B+rHbXe3z/6eMVdde2Pjz5jXrcOa69nRtVYVZxZQvd/8cy hI/ZJzmmwdOhWVhr2HbkD5rMTLAMKMR/BT6X+pITVdzV7u24RRLMUD4sbCW6S1RuKdTqPYNK rBwr2AB2cJLELFocuFNrujl4d9giem35TVey64b++vZ6+9ryHm3KqCkoE82zRGaUsVuj5N14 2/1mkRGfODq+572KWsn+SUUQP4U5WiryFFX0VlDWxG9nDn4btn5cP6Xn9UH9PAk9rZ/Rr+ij Eb4MdEnPwnNRH6NJ8LBpIeISoIqDM9ROVGONA+Ip8fK0W2SR/Q9AGf1mCmVuZHN0cmVhbQpl bmRvYmoKMTQgMCBvYmoKNzA0CmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDEzIDAgUiBd CmVuZG9iagoxNSAwIG9iago8PCAvTGVuZ3RoIDE2IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0Rl dmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFlE1IFGEYx/+zjQSx BtGXCMXQwSRUJgtSAtP1K1O2ZdVMCWKdfXedHGenmd0tRSKE6Jh1jC5WRIeITuGhQ6c6RASZ dYmgo0UQBV4itv87k7tjVL4wM795nv/7fL3DAFWPUo5jRTRgys67yd6Ydnp0TNv8GlWoRhRc KcNzOhKJAZ+plc/1a/UtFGlZapSx1vs2fKt2mRBQNCp3ZAM+LHk84OOSL+SdPDVnJBsTqTTZ ITe4Q8lO8i3y1myIx0OcFp4BVLVTkzMcl3EiO8gtRSMrYz4g63batMnvpT3tGVPUsN/INzkL 2rjy/UDbHmDTi4ptzAMe3AN211Vs9TXAzhFg8VDF9j3pz0fZ9crLHGr2wynRGGv6UCp9rwM2 3wB+Xi+VftwulX7eYQ7W8dQyCm7R17Iw5SUQ1BvsZvzkGv2Lg558VQuwwDmObAH6rwA3PwL7 HwLbHwOJamCoFZHLbDe48uIi5wJ05pxp18xO5LVmXT+idfBohdZnG00NWsqyNN/laa7whFsU 6SZMWQXO2V/beI8Ke3iQT/YXuSS87t+szKVTXZwlmtjWp7To6iY3kO9nzJ4+cj2v9xm3Zzhg 5YCZ7xsKOHLKtuI8F6mJ1Njj8ZNkxldUJx+T85A85xUHZUzffi51IkGupT05meuXml3c2z4z McQzkqxYMxOd8d/8xi0kZd591Nx1LP+bZ22RZxiFBQETNu82NCTRixga4cBFDhl6TCpMWqVf 0GrCw+RflRYS5V0WFb1Y4Z4Vf895FLhbxj+FWBxzDeUImv5O/6Iv6wv6Xf3zfG2hvuKZc8+a xqtrXxlXZpbVyLhBjTK+rCmIb7DaDnotZGmd4hX05JX1jeHqMvZ8bdmjyRzianw11KUIZWrE OOPJrmX3RbLFN+HnW8v2r+lR+3z2SU0l17K6eGYp+nw2XA1r/7OrYNKyq/DkjZAuPGuh7lUP qn1qi9oKTT2mtqttahffjqoD5R3DnJWJC6zbZfUp9mBjmt7KSVdmi+Dfwi+G/6VeYQvXNDT5 D024uYxpCd8R3DZwh5T/w1+zAw3eCmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKNzkyCmVu ZG9iago4IDAgb2JqClsgL0lDQ0Jhc2VkIDE1IDAgUiBdCmVuZG9iagoxOCAwIG9iago8PCAv TGVuZ3RoIDE5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWF1zEzcU fd9fcR/tmUbR90q8JQE67UAnYM/0AfpgzJq4jW2SdcrwP+n/6bnSrrPrrwQoMyUPwtpdSffo 3HOudEOv6IYkaUlKakulD3Rb0e+0pNOLWtG0JkX1dPeNGUnhZfpHc35XF3hXpr/97/NESkry LlLQBv+Pnal0nkql6Yru2PgqjXqCZ/icVzhd0PmYgs39aJVXQlujKRgaL+j0uRIIiMaz4g0N Llarv+ZV/WRIMdKAXqw+zJdD+oPGv9KzMeI/iEB3Fb0IhZMqehkYGS01GYfZdGhDmpGmT2Tp ZcKFLkZYCv+NLhiCNhiEEkKBUNIIOnZHGDXLOj07u3zxZLT+fF3R6eW1ovOnF2m9nQcXq+W6 Wq6L85fNo8vqdlp9XN9Nrul2zjMqn+Y0FlMFshLbCox+WSh6umometZ83GNCsY8JnQi0NGRd ux0mb/4JWi8cWd/ZiWI8I+zE28HZ22G7AUpjM7b3oV1HJ75vDxxE4zVx3KYk430Tt/5RcRsn jHclaAjuNTQsmIY0uJx8qIY0/vOecm2oPcjbjNimHmeHLBBNl3reWXIaXbSgEvSzoOE1BRAy 916nXhcVeq+Qd/dvz4pHM5Qx40+1LzcTGROaiVJvkSdSsdxM1L79nxI5uLSfiNQHT06ZZj/N d+5nQgYoZVnp8NhYIZX1JZX3spL3E2QeVbdDYrYP/h6SgrKk30p9BauLw+lMB9NZlxkFrEpZ smVsULDF8WxuqdXT9U4291AoOih4I2J0SFcF9WhpDR1jWp89gtOtjOzldIfRspVTBzQPymlx TE4ZCpZT5XuCfIiF34Q/o8CyAhpqUNAlASwgp+4BGj60ASynXpdsCXC3zgYoJVRpYG3ebuEP Gp6DhTDuwQr2RoNPNbOw8bYie9tRoXGNU+1sTgOzTK4F0nPIsODkWgyzN6WwWjoIgxPeWA0R QiOiNz71qVKz8BijsCUlKAT3vaYRFsVe2tp92nSvg5DeQ7eUEaX1hseCmEHG8Ik3SgQD23cG T6Nl7WlnKpzWImgkQZK4PePMkvU2RUyywzYUq7ywkWGVVrgGdqw5RYoWnTCOLcQHqXwglnN6 Xd3cVfX6PgU2IBa9iTaYGYu6xCISE4BZaRGmsUaYCOU0wSIQjsM7TbrkpGPECiavSmUDqg1j rSgdVmWVxeJtGgJfmcioGKeEt55/OqGj5dE2E1hpQCMFsb7aO8xhoIzzwmgs12G7Mzt3YCq2 hKEHU/1xtaw79rfBCaUjo73taoWOZmM2GtFmV8u92WwMcqF1tfbtXHcxVgdrLRY5wLYZ3HnX DJ578+AWCdUO3r69R0OKB0qywxredzIdPLMPEuK/U0I4PCCzKyH7nAwo5bLsmJMV/Tq51ZKv qM9aFIDWVmHadzIN2mcUygdQaA3lmJMxPzJVO0K618maAu0xTtYq+CHRbL0pi2bK2S3RRPoG hVy1SFDJiQ6hs1pYi8MQM01HVKksmrowkUnItNvVS2ynZRXQ0BFQWCW9LPEz6YeVotSoeg10 LZalRspvJuFcKSUeJn7vGeewDGBGgUMiSnuZ+AqT6siAQdHvI8LYkUyYVFaD56iT2KluFzS6 e7eY1/V8tRx2GHZzD1l3sv2aY8staX5T4IAxxWloMl/WdAcnXE4WUJ0TuMjgp+b093FS19kp c9G2gl3yot6/HW58k171DqA7CpUqDBjeTo1yVHr4K4dzSOerPZry7aedrWOeim15HL4znbgu 0XDj3XSCjP4PjnkwT96iVI8B3pz4ENP4o+JG3VB6De7vHvNGd9NpxQx79ElvR0tQO6SE7xVg 94nRKSa8wBpwCSOUg6FwLRGEi8gLF6OwMqTEdw62zQ66V0lwc4Hyg29Q8ElAMcXDQB0Uurie QFLznYEK/Jr2UJLNJCrwbIrrDhQUe8Y5oiQSRZvhMkfGR9ZdEJHXVa4j6NN8fYWbA77N+TKq 1if5gucfuqom71H+7heUgIOyDEDCALRM5Y568UMd+ZjbLfj42gLnvKxTmy3tqNTxQbnM6KhU YzTP6vXk3fW8vqre92kCiJsLNVwU7dwKjOj0Z1zIfaiZHYov21JNi8snUiVOO47NaZYuh/p9 3bu8VG131g8NS1dQkHKc7ziLTtA6XBllbdXNNRpf3oyhpIEGd2j4sJsbMJ1/IRJuJsOCm8/5 FySXP8BOcfNb7sQxhV/BkZmbZpRF/vWu14mN5Feaz01+1h9T507Za2JHx+nVvwisupQKZW5k c3RyZWFtCmVuZG9iagoxOSAwIG9iagoxNjc5CmVuZG9iagoxNyAwIG9iago8PCAvVHlwZSAv UGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjAgMCBSIC9Db250ZW50cyAxOCAwIFIg L01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iagoyMCAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MxIDEyIDAgUiA+ PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIKPj4gL1hPYmplY3QgPDwgL0lt NiAzMSAwIFIgL0ltMSAyMSAwIFIgL0ltMiAyMyAwIFIgL0ltNCAyNyAwIFIgL0ltMyAyNSAw IFIKL0ltNSAyOSAwIFIgL0ltNyAzMyAwIFIgL0ltOCAzNSAwIFIgL0ltOSAzNyAwIFIgPj4g L1Byb3BlcnRpZXMgPDwgL1BsMSA0MCAwIFIKPj4gPj4KZW5kb2JqCjMxIDAgb2JqCjw8IC9M ZW5ndGggMzIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUg L0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sg NDEgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAwNPA ABvkAAEKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iago1NQplbmRvYmoKMjEgMCBvYmoKPDwg L0xlbmd0aCAyMiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAx MTYgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01h c2sgNDMgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCngB7dABDQAAAMKg909tDwcRKAwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDgeWAuOAABCmVuZHN0cmVhbQplbmRvYmoKMjIgMCBvYmoK NzQKZW5kb2JqCjIzIDAgb2JqCjw8IC9MZW5ndGggMjQgMCBSIC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggNTkgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4IDAgUiAv SW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgNDUgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0Zp bHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9tCU+IQGHAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgz8BwYXggABCmVuZHN0cmVhbQplbmRvYmoKMjQgMCBvYmoKNTAK ZW5kb2JqCjI3IDAgb2JqCjw8IC9MZW5ndGggMjggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjcgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQo4IDAgUiAvSW50 ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgNDcgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITAaAqMhMGAhAAAI iwABCmVuZHN0cmVhbQplbmRvYmoKMjggMCBvYmoKMzIKZW5kb2JqCjI1IDAgb2JqCjw8IC9M ZW5ndGggMjYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUg L0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sg NDkgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAwNPA ABvkAAEKZW5kc3RyZWFtCmVuZG9iagoyNiAwIG9iago1NQplbmRvYmoKMjkgMCBvYmoKPDwg L0xlbmd0aCAzMCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAx MDggL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01h c2sgNTEgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCngB7dCBAAAAAMOg+VNf4QCFUGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAwDswI3AAAQplbmRzdHJlYW0KZW5kb2JqCjMwIDAgb2JqCjYzCmVuZG9iagoz MyAwIG9iago8PCAvTGVuZ3RoIDM0IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRl IHRydWUgL1NNYXNrIDUzIDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQp4AWNgGAWjITAaAqMhMBoCoyEwGgKjITBgIQAACIsAAQplbmRz dHJlYW0KZW5kb2JqCjM0IDAgb2JqCjMyCmVuZG9iagozNSAwIG9iago8PCAvTGVuZ3RoIDM2 IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDExNiAvSGVpZ2h0 IDM0IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA1NSAwIFIg L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt 0AENAAAAwqD3T20PBxEoDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYOB5YC44AAEKZW5kc3RyZWFtCmVuZG9iagozNiAwIG9iago3NAplbmRvYmoK MzcgMCBvYmoKPDwgL0xlbmd0aCAzOCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCA5NyAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0 ZSB0cnVlIC9TTWFzayA1NyAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0 ZURlY29kZQo+PgpzdHJlYW0KeAHt0DEBAAAAwqD1T20ND4hAYcCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDDwODB/UAAEKZW5kc3RyZWFtCmVuZG9iagozOCAwIG9iago1OQpl bmRvYmoKNTMgMCBvYmoKPDwgL0xlbmd0aCA1NCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAyNyAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5 IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4 IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AWWSbVPaQBSF2d28kpiikYoN0GAt VhuJqSjQFqQQTQBx2CQ0xOkICDM4jv//cxcxIep+SXaTc/c8595EIlwAkgVAuI09AaI5nqXg +28AsVJ6RxZoGPt99QppKXekFzMC9U6Gkhm93akfyOxbGaBT+03/DldzAnojg1zGuJk/jq8O t5jXMkBJhbr/8DTHZ0oSvTIC2fSxdXs/m/p/iik6XhEgMV+98YeOP+r92OXjFSGzddh2B+aF 7eHGlw9xGUoq5Wv36lSr9Ye2/pFby4jzr00XNw7U48sh/qVurLGXzq8D/Luofm/9DWxtO8IG 1MZew5+OzLJe6fybej/zEfbSeW+ymDj2ZXc4e7izImyAhHzNmy8mIxe7wf1ihs9DbOL8mxmM g0HXsqwevh2vsVHyU7nv41a5pGla6bzt+CH20vmF4zSPlG1ZltNZreXg+gobcjsnHa9j7AoM TdOMqJx2vRdsJH6u9geN/VU8zzUG/UpeRAnSjr2abZ6EoZKbDdOqFSQKEN6cXjHUMFPIpApG pZQjYQHEy1lV2eReGggQt6moWZkncwApXpQENpoIMnWCJHIUSR9ARFEoNpnRwX8Oy0SuCmVu ZHN0cmVhbQplbmRvYmoKNTQgMCBvYmoKNDUxCmVuZG9iago1NSAwIG9iago8PCAvTGVuZ3Ro IDU2IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDExNiAvSGVp Z2h0IDM0IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJw b2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4AZ0XZ3fiSHKUBUiIjAQYkbPIwWBMRiCySB6vw755G+a9vf///arBYIN9e3tX X9Sqrq7UlfrbtwNgOACGltj78ttxeUAfya72z8j/Z4GTNEOTSCiGkwzL0gSO2CA0c0CfmR73 KeJSkfP2P1/gpEGwmlkSGOGk0eZ2CSxiihGs2Wbl6IP8N244ZbK5HGbmHwnFcIIgju67VgYj jY4bv5unQA5hcEayGdmCBGGkySUHRJ76IJQwOMLpuOdAe83n+h9cZuIM9FfqgTn2YDrhM4NM jLJEGuNhyccBJUZy3mQuLnHIAW9AcP5SpxG3XRh/2rz6EqxF8rouVD5R4LQlkCunPYg1bpCK 85df1JQdMSWMUrpWiTtZ4kT7jRQi7cUo52Y/2H7evFyAyp5EJuz4ghQ86FHqtTjawygh3Hn6 6+e25jOBHJyxx27blaDw7l3SEh/s5iXxC0aXEtHVmP3ZUsJteNf4RAKM4412WTYjMxlXbvrj X3899+NW5GmCuyn1ujnJeD5GWhPD/bIsfZR5SCkcO18A/EPsEATFe+JpsJNAiYhwb+mILs1f 7nezyFsYyQca619/++11XvIYwHs440x3x3cRCwqvA3yWiREUYzAa2GOuQbIRFGs0cRxnMvJO f8AjMBRkHws4k+GNBqftyc6kfbAL1unhdr/ZPm7aEQEZSgrh5kzNv7vyWiaGUwbBKfm8op1H qYwRtMnq9smBgOxzO9w3sigYACG63B6/32M3HW6JMPoqk1kjwIH7CJOvOt9MOr3lTjvKgd3q dH4X5Mmv7cQIxiyGM8VKpZCUHcCRYCzeWK7SaDbrxUQwlEyHnIIzpOSzSqFSK8alQxST5kh7 NSsjV2KUNd5dL5tKob/Rm6G3C85r60HSdnLulZ04Y/Fn7wZjTRv1agmRoxiLnG+p09Vmt+qX 07l6M+93ysWBNux2h9qolZFMJIbR9sxoO8k7mUOilKY7rRCM1Jf7seJkkBq2tLqdFkRYf3Gf GGX2F/vT2WSszRaT+5Sb472FwXwx1x9fH8dVpTLUGhFPtLX5rg/bnfFy3kKZjbNiaf4wToMh ENvh9u77KB8MVxe/bBoyqgukEOvv9Nsb45cyCYOY7S9mvVqx3ByvZs2o0xlrLeb9ZnfxuB/k k1Vt1Y77kv3Hp1ldUeraeoJiEzf6bvXvatJKHhJl9uvr8i5faG9+vIzTqC6AHp3dthVE143g 0rew21wsOooseaPVsa6VZJ8yXI0qSaW90jvpSHmidxO+5OBh101IYry1Wt1B4BAmubl5GMQE EpJGbj78+cfjbKgun3/+ub1FdYHggq3dvhsxvwXRhUyMdmSG+rjg5VmjLdJcLpvxQG64HOTD ibv54j4eLGoHmf3tourjTN7yTG+HeYLgAq3dQy9qJlGijF5//v6809f71z9+Pg9Q/sD+/fah Dzp9YSfOuAtgCdDh4OXiZN1PB9KdudYolPvLWS0sF95kbqYFF8O48kAMkpAd230P7ECJsnp5 2c3Go9F4vn99QXUB6fQ3MlmpNNUhlclvGOPMaZtB2heuTlZTdTRf9BWf701mb42ClHZkNb0H 2h98u+9FBRIlynavNfJKJqMUmtMHqAsW6uhb5Id3Ox9WVa+JIgGMYgGMS9lZkkSeW/cSbo8y 2D5sV7N+SXZI+aOdZ5njg0yIobq+H8QFGjrKZDupBN12AHe4NtuiukDxn2JI/b65j7gsgiCY LZIyXE+rQbtZEJOd1fIuaHMmupvv63EzJ9t4d+5a5hrZiXJlsVdTVtYcvtf1VsTKUhRFG2yx jr6CusBAruz1+sdcUZ+eJrV0PBaLhmQ52Zyv1GoyHFHuZ/ooL5kdyf5mqzXSst1ocH0tE0JP GW+hAHCO9EDXChIq7Whc8EDM9dMOky2l7mbvvQt62fDpx+N82Ov1OneFeDTfXay0brM1mK0m tyErJ+a0h92olvI7OJMrO1q0Yt5EZznKOmnKnlGXbXRLpBDt6NOiJIhK772DQBmMNsc9xW0G /2yGafu59plDre3L88NmresrrZmSg7n2dLmYQ+1Rb6NOk+C/Xb08rfr1XESyi6n2sBYSw3W1 nbTREDAt9TbIQwKabmrT6a1sc8fL1eS5wRJGMVktx1xWX2W6aIbONZ4webKdyWyijcfjUbcS cdm9iWpnqKr9ZiGETEt1t89P24U2aGaDvnC+nPTYvKlKDtozyd9kyynUi6FFZvqT+5jDJsqy mztNBDjFuWVZtNjCd1P15HFwOs4I3lgmewAlGXTxBs7hR4hkWLIYWEuoPl3rU1XVoAIWgt4b vyiYLJLstbEEwVq9fskMxQ2qbPBW7Soiz/G8gTpNhqgv8jzHOZPt0V30vWdD8+IsNscB7Daz kSZIQNidTpvZQJGsSxksp61SttAYr1etmFPgjdCyjTzHQm+FMZCHA9D+cdadafXKskCT5Idh FPo9SdKcN99pf5xNDnMARPYR0AE0GNA0TZEwfrASRJ5aivhD2e5620/YGKCAqYQ8jLmHxcEo MFQutm7jjlO7QnF7BJy2hiv35Y8z2Gnr8osBAAbUz42Wo1oyEi/2db0NleaS7vwHQ1i0XMt4 oJuecccFYXQnK+UYzJrXO1eEb7+gY/ROm/Qa1XpHW4zKN2h4/BJgjHfHcqkb8yl+TlSHATUb R639hPr7LwbRnmr0hoPBcDTqVcK2z647MUAxGgweR5UTDn3R2yEQFD/p8pHmcg2cxEiuCtNQ o5IJ2A1/4x94+FjtFsO1OeiNZLddvpEuZXz6wymjVZLD0WjoBh5a5Ntw8YkMEIcH3tWjD9HB W5Bl/qd3HwQxbeAEi8VsYv/LQTR5n4bsD0r9B/QHis9LdAa1uQ9pd030b9xnaNQKZW5kc3Ry ZWFtCmVuZG9iago1NiAwIG9iagoyMTQ1CmVuZG9iago0MSAwIG9iago8PCAvTGVuZ3RoIDQy IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQg MjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0 ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBrVbZkqJYEC323QVXwB1xX1FULDcUUcoNRcvauh9mOmJi/v8H5mJVdU/HxLxVvkDm zTwk3JPncncHDIIRYDAMec7XGIRgJMNxLE2gXwYLo6Q/mszKGSnM4cjXNAuhdCTbGIwnI62S 8OPwV7w9hFCRgm7tnaPzMG0INPIVoDAWkIeb02m/2+9XvQyHfgkoFW+t3YOpa4PRqJ36GlCE TQ8dd9nKSkm5kI16r/9BMG/LIPh3g0AQugUh7/LJw/cQSP2gJcLlJq47K4RZ1s8HGRy+EYxl GRKDQS5GkAROkDRNEQRJeZyDYBQnSRxBUJxiOZbCEfg9BPIomsI9WiJsduQ+LmsxBgeGIe8E y2QSUR+JIBgbiob5UDyRiIVC0SjPYjCM0cFo2EeRbEhMZ9MCz2AISgUikRAfERMCT6PwHUxL 2u7JGZfiHOgDhlE6nK1ruq5V0zyF0dF8tawUG91uLS+XqkqcQVE6KlcUMchLxfZA77cVgcOJ QKpUKSgVVWvJYRK5g/FQyXCfnFkzHQIPQahosb9Y2/bK0GSeDmR7c+N+aKyssdocTPVimCSC +f6km09kWxPLttfLUU3k2HhtPB/r4+XaaCdYFIJQRmyY7pO7HhTjLE7wytDe2aZpby0tHYyU F+7Jni+s5Vhtjex1P+3jJNWy7yvFzmK7sUxr8zCtxPhUf+vuTMNcGWqSQ6E7GOOk+uxwvR5m ddHnS3YfTtuJps22jlkThfrD6/PDsKOq9UJBs51FNR4pTPcbvdaeO8floKNbzlbPxXOj89vJ 0NROS4nd5gfGuXhpYF+e3UVdipeMy+O6V60N7POul000t2/XeTUlivGIUJ45m34+11k7S7Wm g42YNittw3EX1UR+fHndabIkChHuNumAN3Qo0164L+60mle91vRWa2i7ez2fam5enH7SR1EU ySW1jWN21dl+d1+pTi9vp1mn2Z0f3GUjrYzdR7McZkAa5mmSx2GU8IlV4/y805u68/11O+n3 R8uHZSebbNqPdiNCeLwmQuX58WAtd0erJVfmz9/Ppt7TZ2t7XE4po+NxlGE9+njqCbhOEBiK MUJz/eTOe+Pjt6e1rrZUra8qotRYn60Kj3nDhbCpwf7per06I0UqzZ+/ObNuq93ta7W0kB8d 9oME/SlxMMYEeT9NkEFldr4s+/f7l7PRzGezOTkjhOKN9cksB28qAxOR2urlzx9vm7YUkSeX 502/lMvk5FwyEpHvD9ueRH2CIlQ4o2SFUDBeNs6uoXati2vU06IgJZMxPt5YnRald1AI5bKj 619/v84LvC/Z2z9u+ookiMmUGA7L9/utJv4CZaS6rqvVYn24uez0Unm4cx+GNUUpVUrpmPgv 0DuYjLV2f/xwewmGilTNkzNXS/lCGYxX7D+gCdXc2Mu5tT+f5lVJqswOp81iPJpM+iVJrC8P RjHwLrIQ5s9Pz9dlJURgXEqzT4fVdDSejlpZQdY3dkf42SlMRSuTzfF0cs8Hs53w+8W6sTs6 ezAuw5IQK40tPef7UG6YijcNs5sEu0zw8mB9PB52W9top6NpdWE0YuTnN/UGqjqYr2x7eV9P +gkCuPpitbLmei0RDCYb3arIfJwxoNVUrZ7jCaCPVEjuTK31ypx0lWggVlBbuSDuSbBnEIJz 0XSx3mxUcjEfEEeMjWbKjWa9nBP8FBWUUoKf+OwAIQNxT9wgUEYGJaXWbNYKKcB5LppMhL34 hwGFJdlAOBLmOeqmyyjJBT3XRwGhJBiOIX6e22ACaIYEgnlrhvGHgIoGWAJFgF6zoPoT01uH EcwT6I9fCfAUDCc8F0g6mDag7D+TgQ/+ZG4uqEI9XffWvfvf8t4LwJHzqxQcQ//2fkJ6N7+t /F/eP/t759kKZW5kc3RyZWFtCmVuZG9iago0MiAwIG9iagoxNDA4CmVuZG9iago1NyAwIG9i ago8PCAvTGVuZ3RoIDU4IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDk3IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAg MSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBrVZpl6LIEi12lEUEWdxZRHHDrdzQst0VcQO1yuo+7/3/ nzHJ1HRZM6c/VnwhLpkZ9yQRN4KnJ2AQDCPAYAgK0bcbBKN4hGYYisQAx7eHf4IQnOJTqq7n FC6Cfj8DBOOxtNUZTV6GTUOMot9+BRhjs82pd/bPh1XPiOPwd38jJKLYi/PlfDgcvR9Vmfxu AgiNGS/ny27S6znjviVFvp0AF6rr22lUyqTVQiHDEQgMDCQClC54hhmBPmr4I/1/An+n7bPU /3MCIsSG97bvZNgow8XZCIYRJIEhEISEDigq4JBRhqGjfwQUTYPqBtxg22epwygRnojgYdVD eMLe3c9DjSMxHMcwnIqLAo3DME4LYjyKwijJShnN0NIChSH/ATEpq6oZiSXDbZyS17WMyBAo Ticyqp5PhsefIIwrzW9v23aejwKdIaSglQtyFEGicsFSBRKPJrR6b/zitE2JIv4FKLDSHQ67 1TwfwSMJvTEYOc/ldCwaS5W7zqjf0BMRBHpCqEzXu9+2/ZLCEghKZVvjnh5D0ZjeGzczDCWV Bqs9qLDFsxpnvgJWKvUXW9fdzLqGQPN6f3M47JYDS46n6lPvuN/8aOVYDHqCiXhhuH99PU4b +TiJs8Z4N6/wGMZX5u7IEERz5Pmn3WYNwkhy8QuQTMc9uMulu193VTHd3N6uh/VsWEnL5ov/ 5rvLSVvlAAGERIRCf3u9X7c9Q6C44uy8qSdwPFHfnKYlJd/dXQ7T50bDLmVl9QEyIQj2k253 uj8v7Zw+OL0Hi36zqspKZXW/e+OOXUwxgCBk4NXm7HR/2w90IVGaB1s7JLBdf1bOlaf+eVJJ S5IsCrI1+wS8ZM1ur9tetTZwr4eBWegd3/1po5ARYwlr8frm9suqwpEgByEDwSYtxwO0naxi fSWo6q1tsGkqFEGQJC03HoCSbPfX+27YbDru5eiY+fryct0OrDRHxfKD4+tp2tBEGgOyDQWF YFFB7+3fb1MrW5n7nzeY18yu58+K4FMCgUWU9gOQcuv4/1/7Sb8/Xu1Wz6qsdja+v3XKCkOJ 1uQQHGctNQ5uEA4DAsdQMm6Mg3e3qVfnvtsQcVxsuP68Vux5/tRkUXBRmFQ6nwAi5Pbpf/ft sN1sd/vtohwTtPbiGOxfyhLNKOXRzj+vO6CKYAghWT5OkziV6uzv+45Rmfm7lkySctsL5rXC 8y5YVhMkiiBoRGk9ACk1vZ/XWaOgabqhJjmKEdXGj+Pt6Og8zaVK/c3lsrJB7wTdOlUwc1Jc yPcOr25Lsyb+cZDn4urwfJ1XVHsFUqgJDE3TjFxfP4BUXd4us3o+lUxnswrP8VLaaK1ubxs7 JSSUXNkBSXfyFALjfKE76ttWubMMrotKWh8c/YWtaY3V/W1hpc3x+bLtl3U1n5GVIui7v4Fs DA+XnVMzTatiacmkapYq7cXtp9fRckbJqjuHn7eJTocExbG73yyWbnDd9/JC0l77h1m/Nz39 ep2ZUspeBhdvPh72Gnoq13iAZLo6PQXe4mU8mfQrqlYfjMdTINh10yi1R+PJygcdLkchEMbm n9enIAiuF29UBErTepujt5qv9peDo3FctrU4+qe9uxyUFDH/ADKfrs8O/vm499ZOJafZk413 8IPdwMwVe0Dep+A0r0lkmGTBaE9W27CnmFIUiwhGZzL/MRo4L8OqQpGxbM2Zr9fLl5YGsvcJ VJ5i09XhYrNZz4e1nCgXOpPlGjQUUxYy1eF8vVmO62kGCAFGI/F0oWI36sWsAP4q0AifNStl U9NAcbA4ijOSatXtWimXiOLEF4DhtKSWwbmyDoqITuRK9Ua9lBWoSCxpVGy7oissHk4pGMGj LC+KCY4C4wwIiqA4QeBYhmWiYGSATs/EE2IizoCu/0fAsxEcxUg6npAScZpAUTwaE0RRANPr cwqiYNjg6MdvF6DAgKEI+vEixGAVA+FBa/wCQpFif6s0nK3/+CAG2APES/yOBzQKDAL24f0D v4CP5ceLr1u/ngv930Ee7l9pkBe5CmVuZHN0cmVhbQplbmRvYmoKNTggMCBvYmoKMTUxNApl bmRvYmoKNDMgMCBvYmoKPDwgL0xlbmd0aCA0NCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCAxMTYgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQovRGV2aWNlR3Jh eSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQg OCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdF2d34khylAVIiIwEGJGzyMFg TEYgskger8O+eRvmvb3///2qwWCDfXt7V1/Uqq6u1JX627cDYDgAhpbY+/LbcXlAH8mu9s/I /2eBkzRDk0gohpMMy9IEjtggNHNAn5ke9yniUpHz9j9f4KRBsJpZEhjhpNHmdgksYooRrNlm 5eiD/DduOGWyuRxm5h8JxXCCII7uu1YGI42OG7+bp0AOYXBGshnZggRhpMklB0Se+iCUMDjC 6bjnQHvN5/ofXGbiDPRX6oE59mA64TODTIyyRBrjYcnHASVGct5kLi5xyAFvQHD+UqcRt10Y f9q8+hKsRfK6LlQ+UeC0JZArpz2INW6QivOXX9SUHTEljFK6Vok7WeJE+40UIu3FKOdmP9h+ 3rxcgMqeRCbs+IIUPOhR6rU42sMoIdx5+uvntuYzgRycscdu25Wg8O5d0hIf7OYl8QtGlxLR 1Zj92VLCbXjX+EQCjOONdlk2IzMZV276419/PffjVuRpgrsp9bo5yXg+RloTw/2yLH2UeUgp HDtfAPxD7BAExXviabCTQImIcG/piC7NX+53s8hbGMkHGutff/vtdV7yGMB7OONMd8d3EQsK rwN8lokRFGMwGthjrkGyERRrNHEcZzLyTn/AIzAUZB8LOJPhjQan7cnOpH2wC9bp4Xa/2T5u 2hEBGUoK4eZMzb+78lomhlMGwSn5vKKdR6mMEbTJ6vbJgYDsczvcN7IoGAAhutwev99jNx1u iTD6KpNZI8CB+wiTrzrfTDq95U47yoHd6nR+F+TJr+3ECMYshjPFSqWQlB3AkWAs3liu0mg2 68VEMJRMh5yCM6Tks0qhUivGpUMUk+ZIezUrI1dilDXeXS+bSqG/0ZuhtwvOa+tB0nZy7pWd OGPxZ+8GY00b9WoJkaMYi5xvqdPVZrfql9O5ejPvd8rFgTbsdofaqJWRTCSG0fbMaDvJO5lD opSmO60QjNSX+7HiZJAatrS6nRZEWH9xnxhl9hf709lkrM0Wk/uUm+O9hcF8MdcfXx/HVaUy 1BoRT7S1+a4P253xct5CmY2zYmn+ME6DIRDb4fbu+ygfDFcXv2waMqoLpBDr7/TbG+OXMgmD mO0vZr1asdwcr2bNqNMZay3m/WZ38bgf5JNVbdWO+5L9x6dZXVHq2nqCYhM3+m7172rSSh4S Zfbr6/IuX2hvfryM06gugB6d3bYVRNeN4NK3sNtcLDqKLHmj1bGulWSfMlyNKkmlvdI76Uh5 oncTvuTgYddNSGK8tVrdQeAQJrm5eRjEBBKSRm4+/PnH42yoLp9//rm9RXWB4IKt3b4bMb8F 0YVMjHZkhvq44OVZoy3SXC6b8UBuuBzkw4m7+eI+HixqB5n97aLq40ze8kxvh3mC4AKt3UMv aiZRooxef/7+vNPX+9c/fj4PUP7A/v32oQ86fWEnzrgLYAnQ4eDl4mTdTwfSnbnWKJT7y1kt LBfeZG6mBRfDuPJADJKQHdt9D+xAibJ6ednNxqPReL5/fUF1Aen0NzJZqTTVIZXJbxjjzGmb QdoXrk5WU3U0X/QVn+9NZm+NgpR2ZDW9B9offLvvRQUSJcp2rzXySiajFJrTB6gLFuroW+SH dzsfVlWviSIBjGIBjEvZWZJEnlv3Em6PMtg+bFezfkl2SPmjnWeZ44NMiKG6vh/EBRo6ymQ7 qQTddgB3uDbborpA8Z9iSP2+uY+4LIIgmC2SMlxPq0G7WRCTndXyLmhzJrqb7+txMyfbeHfu WuYa2YlyZbFXU1bWHL7X9VbEylIURRtssY6+grrAQK7s9frHXFGfnia1dDwWi4ZkOdmcr9Rq MhxR7mf6KC+ZHcn+Zqs10rLdaHB9LRNCTxlvoQBwjvRA1woSKu1oXPBAzPXTDpMtpe5m770L etnw6cfjfNjr9Tp3hXg0312stG6zNZitJrchKyfmtIfdqJbyOziTKztatGLeRGc5yjppyp5R l210S6QQ7ejToiSISu+9g0AZjDbHPcVtBv9shmn7ufaZQ63ty/PDZq3rK62ZkoO59nS5mEPt UW+jTpPgv129PK369VxEsoup9rAWEsN1tZ200RAwLfU2yEMCmm5q0+mtbHPHy9XkucESRjFZ LcdcVl9lumiGzjWeMHmynclsoo3H41G3EnHZvYlqZ6iq/WYhhExLdbfPT9uFNmhmg75wvpz0 2LypSg7aM8nfZMsp1IuhRWb6k/uYwybKsps7TQQ4xbllWbTYwndT9eRxcDrOCN5YJnsAJRl0 8QbO4UeIZFiyGFhLqD5d61NV1aACFoLeG78omCyS7LWxBMFavX7JDMUNqmzwVu0qIs/xvIE6 TYaoL/I8xzmT7dFd9L1nQ/PiLDbHAew2s5EmSEDYnU6b2UCRrEsZLKetUrbQGK9XrZhT4I3Q so08x0JvhTGQhwPQ/nHWnWn1yrJAk+SHYRT6PUnSnDffaX+cTQ5zAET2EdABNBjQNE2RMH6w EkSeWor4Q9nuettP2BiggKmEPIy5h8XBKDBULrZu445Tu0JxewSctoYr9+WPM9hp6/KLAQAG 1M+NlqNaMhIv9nW9DZXmku78B0NYtFzLeKCbnnHHBWF0JyvlGMya1ztXhG+/oGP0Tpv0GtV6 R1uMyjdoePwSYIx3x3KpG/Mpfk5UhwE1G0et/YT6+y8G0Z5q9IaDwXA06lXCts+uOzFAMRoM HkeVEw590dshEBQ/6fKR5nINnMRIrgrTUKOSCdgNf+MfePhY7RbDtTnojWS3Xb6RLmV8+sMp o1WSw9Fo6AYeWuTbcPGJDBCHB97Vow/RwVuQZf6ndx8EMW3gBIvFbGL/y0E0eZ+G7A9K/Qf0 B4rPS3QGtbkPaXdN9G/cZ2jUCmVuZHN0cmVhbQplbmRvYmoKNDQgMCBvYmoKMjE0NQplbmRv YmoKNDcgMCBvYmoKPDwgL0xlbmd0aCA0OCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAyNyAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9E ZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9G aWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AWWSbVPaQBSF2d28kpiikYoN0GAtVhuJ qSjQFqQQTQBx2CQ0xOkICDM4jv//cxcxIep+SXaTc/c8595EIlwAkgVAuI09AaI5nqXg+28A sVJ6RxZoGPt99QppKXekFzMC9U6Gkhm93akfyOxbGaBT+03/DldzAnojg1zGuJk/jq8Ot5jX MkBJhbr/8DTHZ0oSvTIC2fSxdXs/m/p/iik6XhEgMV+98YeOP+r92OXjFSGzddh2B+aF7eHG lw9xGUoq5Wv36lSr9Ye2/pFby4jzr00XNw7U48sh/qVurLGXzq8D/Luofm/9DWxtO8IG1MZe w5+OzLJe6fybej/zEfbSeW+ymDj2ZXc4e7izImyAhHzNmy8mIxe7wf1ihs9DbOL8mxmMg0HX sqwevh2vsVHyU7nv41a5pGla6bzt+CH20vmF4zSPlG1ZltNZreXg+gobcjsnHa9j7AoMTdOM qJx2vRdsJH6u9geN/VU8zzUG/UpeRAnSjr2abZ6EoZKbDdOqFSQKEN6cXjHUMFPIpApGpZQj YQHEy1lV2eReGggQt6moWZkncwApXpQENpoIMnWCJHIUSR9ARFEoNpnRwX8Oy0SuCmVuZHN0 cmVhbQplbmRvYmoKNDggMCBvYmoKNDUxCmVuZG9iago1MSAwIG9iago8PCAvTGVuZ3RoIDUy IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEwOCAvSGVpZ2h0 IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xh dGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AbVWWXuqyBaNyiggimgExBlxHlCcNeIIKihOiTE5J31Pn/5u3///A25hTtLd9+G+ ZT/t2rVrL4raq1bduVxuj2Nut9t197XmckOolyBJgsBR2PO1aG6YCPKxRCIu8iEah790bx6c zSi9waDXaVYyEQr5SjAPGVONw9HeWht9WI5SsPvrzgyiM9rj9+e9Ze1P9qzCeT1fiOWXF9fX ndbtTXdPhwfJD39df0CB3OJynpQSyZJ2uKyqIRQ0/4e5HFzXbQS8T+fd+5wDrLnR5tdRv3PI GTgTNwOEcrIB1vzR7sT9tNAwL1YjgnlgFEMRFPN6MRgkeRAM9zp8cAN2YCDkugMx1CEI4AuC YQgEIThJUYQz53J5YMyhEAYDFGcalALrEQig3bB27ShFcvXVeaPc4wgZDLNMMBIVwj4MRknm XojyIb8XQYhAmPWhHjeE+9kg5TjeQIilvYQ/Ek8lo6FbCKPDYiIRBWshkBcKBZkQH+UYL+R2 sBZPh6EU4aSedZgVgpg3nCnmJbnSbBSiAR8r5mrNVqOS4f1UMJ6XRRqBMDZZyEV9MISHUvms wN6nqp1+r5kXfCjsZZNltdtVi3HGiwdiuUJWKihqLc1inhvW9bru1pTh5rTtp3yYL9maaP2e tlz08mJUVscLw9Dnw1oyEi32BhWeQOlkezYGLYv6062hmo1l20vTXM06cpggwnJ7qhvGUlPT LM2Vh5NhdzjXtXqUhFxgX8tvv1+3K/P08my2YhQWyE8Pe2MyXSyG1VxloJtrXV9Z5lzNpmsT YyQHqUht9XwaSwGKr8+Nfl5q6KejudC6BY5mpZ5hGrOZsVmoyUiivTmYM2221BSRumHpb//+ 8Xx+en172falIMmWVtfLqtdQGrVyfbS2loOm0pmYu4War2qW3hDD6eHTHz+sejQsDa1VW5K6 28t+2q4VEyFGbK72m5Gqjje7WTWRHR5f9poKKkn3gLjOvr7/fLXX6+3hfFiqCTZS2bw8Toox XojLbWOntySBi5fH2+24WuqtrYdCuqp/+/OPx1EurSx3s7KYUK2LPa5moiGazWqns94qljrG 0ezI+YfT1VTTAs+FwO13w3p5MQf1qtKbb/dLJR6trp93bdGHk6w02G6HEuPFKL623OvNXH22 M3rN0e7lt7eL0WmOLbOXCt4XZ4ej3skJASpcNsA/6dZqPeNgDQrFh8N5lmcJHL9xxenDy/FB 5kL3idr8dNQKybpxNiqA07BfGtvrJo97bu5u05bknmmvFpvj0QY3mrG09stqhPCJjaVt6718 hOEV69t1M2q3B/PVXJULI9seJEjIITQgM8CaPwJ+kSjmT/YPzyslq+jHRYGB7yA6q9mr+j0K dk+lhjuznYxVl+fL5XIyRpr5CBx7mKERNJBUptZ+M8wLseb29UnvKjVFbStyIjfcWp2o9+M6 v2FtWwIBI1S8d3wxm7Ki72f5AHTn8aUfbLMlkjCEMjkNbDEazgxP//r5ZvdLtenTj5/fzAbv hRAylKg+WCerL6cb6+ejVs0kk6l0QuDAGWxaAv43LMDlQSbkZ/jC9PG6qksAa5pzsIhYx7S1 IkdTTEJd7RflMM0p2x//eTMqsWR7//PPl6kcAPQNhIV0fX56XNYyldnpoJXjPCeIIheRBtZG 5f+BdX02WgU5X3/YgZPLJ2u/sNxYuDyzzVFFSuXUuW0N0jQeyM5efn8apYLhov79x7EjEjDG xCS5oExPz2slKXXNw6pXkqRcIZcU5eE/sfzy/Pr2uJ5pU313OsyrolCebzXZD925IF+8pe/M +WigGdvtpBzBYa/Qsh5XNdAQ8Z59XhRZBCK4YmcwGG/O53mJ5wvj7X49HQ5Go3YhKffXRoP7 a1++1Oj4ej3td7vddj2uigwrDxfdlA+6u3NjTKa9sCzLtKy1VnVEG2Hk/rSTphEsVBxNmjEK 8ni58mi5Nu39qp0I0HxZM+2dtVmDGy6Wbk61yj32cV4egq+MjfVKX860QVPmfbhPrDSLPAH0 2eXBg8laH9xW83G7IPjAY8RDcHJZCuMeiIrmS6kgUDs0mG6MZouFpmaCOEoJxe50uVxMuqVY iJOVWiqAONrlmBulhWypUimXCtkkzxAwhAWEGEeDRnfAMJpL5cuVUjYWIp13jxuhQhxLAnFC 6XAEKIXLBXnZmFyulmWRwSEPTIYT+Uq1nE9xfsIXFqMsyLkhOeVQ0s+wbDDI+CkcccQRJSgC fX8qAuXDfQwbCvpJ1FE7kI7gjg4CTURwLwZE6c4NYWSADbMBEigakE+MCrAhlvEBfUS8JAne gb+gwGq3B3436F2qQQB4v74FqDgEIwgCZPk9clP4G6qj+7cgqA8j6EfKxwhcFk6lv0p9Iv4/ Bwj7x19w0j5Hn84t9rec/1nwWfu/d8pD4AplbmRzdHJlYW0KZW5kb2JqCjUyIDAgb2JqCjE4 MDIKZW5kb2JqCjQ5IDAgb2JqCjw8IC9MZW5ndGggNTAgMCBSIC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNl R3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25l bnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVtmSolgQLfbdBVfAHXFf UVQsNxRRyg1Fy9q6H2Y6YmL+/wfmYlV1T8fEvFW+QObNPCTck+dydwcMghFgMAx5ztcYhGAk w3EsTaBfBgujpD+azMoZKczhyNc0C6F0JNsYjCcjrZLw4/BXvD2EUJGCbu2do/MwbQg08hWg MBaQh5vTab/b71e9DId+CSgVb63dg6lrg9GonfoaUIRNDx132cpKSbmQjXqv/0Ewb8sg+HeD QBC6BSHv8snD9xBI/aAlwuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQBE6QNE0RBEl5nINgFCdJ HEFQnGI5lsIR+D0E8iiawj1aImx25D4uazEGB4Yh7wTLZBJRH4kgGBuKhvlQPJGIhULRKM9i MIzRwWjYR5FsSExn0wLPYAhKBSKREB8REwJPo/AdTEva7skZl+Ic6AOGUTqcrWu6rlXTPIXR 0Xy1rBQb3W4tL5eqSpxBUToqVxQxyEvF9kDvtxWBw4lAqlQpKBVVa8lhErmD8VDJcJ+cWTMd Ag9BqGixv1jb9srQZJ4OZHtz435orKyx2hxM9WKYJIL5/qSbT2RbE8u218tRTeTYeG08H+vj 5dpoJ1gUglBGbJjuk7seFOMsTvDK0N7ZpmlvLS0djJQX7smeL6zlWG2N7HU/7eMk1bLvK8XO YruxTGvzMK3E+FR/6+5Mw1wZapJDoTsY46T67HC9HmZ10edLdh9O24mmzbaOWROF+sPr88Ow o6r1QkGznUU1HilM9xu91p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3mB8a5eGlgX57dRV2Kl4zL 47pXrQ3s866XTTS3b9d5NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23DcRfVRH58ed1psiQKEe42 6YA3dCjTXrgv7rSaV73W9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV2X53X6lOL2+nWafZnR/c ZSOtjN1HsxxmQBrmaZLHYZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts2o92I0J4vCZC5fnxYC13 R6slV+bP38+m3tNna3tcTimj43GUYT36eOoJuE4QGIoxQnP95M574+O3p7WutlStryqi1Fif rQqPecOFsKnB/ul6vTojRSrNn785s26r3e1rtbSQHx32gwT9KXEwxgR5P02QQWV2viz79/uX s9HMZ7M5OSOE4o31ySwHbyoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+TkXDISke8P255EfYIiVDij ZIVQMF42zq6hdq2La9TToiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8L9nbP276iiSIyZQYDsv3 +60m/gJlpLquq9Vifbi57PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ//HB7CYaKVM2TM1dL+UIZ jFfsP6AJ1dzYy7m1P5/mVUmqzA6nzWI8mkz6JUmsLw9GMfAushDmz0/P12UlRGBcSrNPh9V0 NJ6OWllB1jd2R/jZKUxFK5PN8XRyzweznfD7xbqxOzp7MC7DkhArjS095/tQbpiKNw2zmwS7 TPDyYH08HnZb22ino2l1YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1suZ6LREMJhvdqsh8nDGg 1VStnuMJoI9USO5MrfXKnHSVaCBWUFu5IO5JsGcQgnPRdLHebFRyMR8QR4yNZsqNZr2cE/wU FZRSgp/47AAhA3FP3CBQRgYlpdZs1gopwHkumkyEvfiHAYUl2UA4EuY56qbLKMkFPddHAaEk GI4hfp7bYAJohgSCeWuG8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J8BQMJzwXSDqYNqDsP5OB D/5kbi6oQj1d99a9+9/y3gvAkfOrFBxD//Z+Qno3v638X94/+3vn2QplbmRzdHJlYW0KZW5k b2JqCjUwIDAgb2JqCjE0MDgKZW5kb2JqCjQ1IDAgb2JqCjw8IC9MZW5ndGggNDYgMCBSIC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTkgL0hlaWdodCAzNCAvQ29s b3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUg L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGV VfmTolYQHrlExQtkxhtwUPEWL9QRFG9QDnXwmJ2ZZJNUpfL//wN5aO1uUtnUzvYP8IrX3+vu 93V/3HkgCL4aBHk8dz9jHgjFAwSwgB9HYehnwBBK0GmW4zgmHScJL/wTWNj3IHRHijwaSqKQ IX3Ix7FIiBsazvPOMg192uUp/ONx0Whp+enXi73d2s+HTT8XwaCPXhVKVvX3N0Pp9RTdOemt hA/+OLS2eXUUIZ3O9zbnZyUXRK5kfblrwN2NPJe6G5GAxevpKFnbXKxOMuin8pPjeSGQOB4I BgOAKeDggRCvz3+lzotAEIL5iCDhw24kAqh+MVtxnzfMyc7LuhqnHrJcLvsQxmHgi4diiQzD stl41I95CSrJcEyCDKDuhbhRX3YSQ0YSlfnpvKxzfE0ayf06S+IIGqDZSrv/NHrqVbMkEUkV xf5AEvOJoIt1oW/nebNQaCjWeafUKh1VN21r2ctF8cCD0J9pxt456MNigmaaylLT1otRNUkA /gF0+/k3ZzVRV5azn7VK9aeFtrEcZy2mwrHCk2YalvP6upOFNCvOtpvlfLnRx2Uah1yo8cdf n4+2vdsbaiPHCK1et6cYp4PM32daa0sbyyvnxerzTEW1d4t+e7C0twM2iFyhv//5vtfXS1Uq pSgqxeXYx/rMOc3LqcehYSi1Uk971ttcrmuc7XGjLKr2YVaKoh434V/eTbldr+QzMQL3h2P3 CaY2O15W1TQ/NDbD4qO42K2aXEF2XveTdqMztQ6LagyD3GsCLVFMxshwwIsgGEGlchVpfQY8 pdjO2lA7zSfdnlUZQb28P88HvcFkrclF6gZ1WyKAoQggEsZJptKWZP10ARQnyqplakvd2gz4 VHF6ebMnnabYkbrVTOiasH4xmjR2bS4IC7MtWZYkdXdcVWiSG5in497URqU4zSvOZSMJOTb3 mMtQfsSt9Qa9tiWEP9Sn2qRVGxiOVruPZrrb09GY9oR4MJTpmceNlE8lkpls0h3sf0PhQEYy drNWbWiejU6GZiXDsdRWPh7y+ujqfG9PWwJfKJXzcdATKFlZO3o9hl6jwv50z3jWnnqT/aeD XMwWlf3ZGjcfExGfN5TtantrNR7J41GTcWuNFMbbaYm8Qd2E59Z2psys405tCOLy/H7U5HaZ iRF+6rG/3u0sY6upYjaIeBAi0xyITAi51YqGGVFRR1JfmU2HojgyXt5Ou81K7RXuiUDssT1e rldzpZOngSJA3miay5D4TRs8sDeSypcEPscL5XK9v7L35nqx2prakI/ivmgqX200qoVszB07 4EyECPyLEHpgLBChyEg4QtKpsmJai36j3lHNw7oZ9yFYIEzRNBUhwNzfhAABzXDNFzw8EIxi KIogKE4WJ7YhV1imKOmO0U35YQhGMGDA/SYxX0Bf357rD8SDhHIjwxg38nx1qB9cwXPPB5v/ A/uKv7uD/cnmfLMErTVabLdjgfJ+Te0fXt9dQliEa4/nwJarhVy7CsN3Hf/70QNGIVu+KlNf LCSCH9d2UBbsDdJpjs/zbNIVwR/X+C2+q8KBUDgSDvqxKxvftn68AlQhwMAgfyfk3xd71dwK ZW5kc3RyZWFtCmVuZG9iago0NiAwIG9iagoxMTkwCmVuZG9iago0MCAwIG9iago8PCAvVHlw ZSAvUHJvcGVydHlMaXN0IC9TdHlsZSA8PCAvVHlwZSAvU3R5bGUgL1N1YnR5cGUgL1NoYWRv dyAvT2Zmc2V0IFsgMAotMSBdIC9SYWRpdXMgMyAvQ29sb3JTcGFjZSA4IDAgUiAvQ29sb3Ig WyAwIDAgMCAwLjUwMDAwMDAgXSA+PiA+PgplbmRvYmoKNjAgMCBvYmoKPDwgL0xlbmd0aCA2 MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBtVhNbxs3EL3zV0xvElDT /OYyN9tJihZt4VQCeqh7cBQpdiNZsddqkH/fN+SutJJWlvPRCAEtanfImXnz5pH39IbuSZFR pJVxFENFD1P6k+7o9KLWNKlJUz3Zf2JGSgaV/9EtP2sEnlX50/88L6SVouATVcbi79RZypSl dF5OdG3jrWz1BL/hdd7hZEHnY6pcmcfovVTRGUOVpfGCTl9rCYdoPBN/0eBiufxwO61fDCkl GtD56vPt3XsaPa5msyH9TeNf6NUYYTgYiPVmRHGUd5odlV7pFFTFAdJBkfVYNHIks2czMvSJ HP2Ww0MXI+yIP6MLuhdrn+BRlT3KFkzqWhg12zo9O7v89cXo8fN8SqeXc03nLy/yfjs/XCzv Hqd3j+L8t+any+nDZPrxcXU9p4dbjj12yB/r8Kcnp5BdhOrnhVb0ctms9Kp5ewsRog8RMFjC D5eCJufbtNiyzAnGQC7s5+NqcHY1pMvVw5CAuMHk5rqe0m4m2o10PPx614G4xnOjA9kQWs/1 /+W5D9IGHwFIoLABJHI+ntHg8vr9dEjjfzaoa33dCnpbG2v0NWWW0SfgThd9waMGDKZoQdFU yIaiOVXKNLPzPOuTxuwNKnDz9EwcBukmw2uQ8qsmxPVC1lbNQnlWlIV0iuuF2qe/K5YrnxMK T0MVyGvbJtR8Y0JzaBCmwjAdKFsnlXYhUtwwTEkoGGY0BZYZ8IN/h6RBMvm71mCb5+JaHC5p OljSJpYwYFfakYupDYMVT1d0C64tju9U9FYYRCcMwcqUvDbguGoNbOCEgX32DFS3VNKL6g6m FXOqYfwinBp57uVUscWpPXBlC8x7HQuHcPhVCeAoMLNggwYg9JkEBXOqOwLEYxkwylIwUewB UWupo0WfC24nAQDiecOpS/Q6GnyqGYdNhxOlwz3JNb7pV3vZaeKsDvWuAL4zETsyroIssBo8 FLyVMSEQPGct/JmTtQaBMsAQWvGcRtgUS4e29+esBxdhoorkrZIYDdsKCV+ZaoJLsrIeoVbM sI6nmoWEt0niyYZ7eszMABH+ZIGSe2LOHpSFU0n6aCMFHaRvom6aDofRgfGgWVoqhw0gHgHf 6WLM7fTH9H41rR9L5EXWFp3S2l6pIZrOSlpJoKpKKOft5cTgavDp9vGGip6hm+n1u+nD1XBT dd20dVZck7d1DokwWtjo4a2KiKx1QUaHP210MikoFwQUGsaAYpEgyAIOWE6MRR6T0ZAOxkmT TKCF4ITCIzxqPYxXyJNTTgYGKOZa405bqVLTfnrs0Axcyp/9zFinpVMoMK/8frT68sKarz8v 9cflXY3muxF93ZBl3bLTVYVJdt3sDBBQumqZLc3OAvZtV22fLtKvuMRyL4dQEYCWk8H4Yuy6 xPsvLdtDkxXjZbYYR6jXxtunexhMHFGFh1vIdic1VeC9MYH5byQw9g+h2Sewvk6K+JR6eqqT ik3aWKu3TPYFCrENA8K1I463O6nxoKQShnAkDG1De6qTMkL2eLy3kzYS8TmdtG0ghzi77Y2F s3cAyNtBgqTn04sDG6TKMBCDN1JbtHeeswk8jiI2SdgUJc56/JXR18PZTsaokHFlZZUgk5iz QSqFT8DZPiYob4OWYHSETFyvhNVA9+CNXENgqF07T5B2SNK4yOydYYszYYdI+6ihh7JfQ7Hh FLJ8WNBo9XZxW9e3y7thB2ud4nWdBfe5yHAPdDpuM7dgafQlzL1HQ1nAOAiZcrRkxB3hF94b v+XR0DoH0u9KHDvHSZ1syxzxSMm0yD1UMnycNF7tM8f+cZLzefw4Kb6JLHDsXJOFyCdpKIxG 9OH4j0Dn6mbOrL7Ac74uyf2ug6/G832ysFHGYADuznGycOZgtJpMpnU9FM8+UR5ijPaGQome lsV74naO5m0IFz8yQAFk/VDJ6KHm8F+m2OgHDd2us8pDqfcyBu5K8LuFuMd7kISsGC1fTeA2 h8UEn58R2wjmsLjXYS1RFhK6qqQyrZboMfMEYdgglbdgCQV/xFfxRRNvqLyumtiTeZXGLlmy QG81+exwk47SAeJ9mlLsaJeuWulA5Wn7zH0uij25OgbZ8Z3L9QfcvfA5tabL+fVk+kN3lXwR Jm1zuQcsbN1LMP2M6PQnXA6+r7kTbC4JDeFWj0nKc4nP8g3V9lz3XlEJiL2ORyC49goJDYgL 7ASjJxyjsx+mudLjmocfJxUNVhjYi6HgoS7f3pXhugyfy/AjBryA4zgPv5dJnJL4PZzZi5U8 LIqxt1uTfLzHk83rtnzbtmnKpNoaUreRvPkPNLfaCQplbmRzdHJlYW0KZW5kb2JqCjYxIDAg b2JqCjE3MjIKZW5kb2JqCjU5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIg L1Jlc291cmNlcyA2MiAwIFIgL0NvbnRlbnRzIDYwIDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0 IDc4OF0gPj4KZW5kb2JqCjYyIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1h Z2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMiA4 IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkg MCBSIC9GMi4wIDExIDAgUgo+PiAvWE9iamVjdCA8PCAvSW0xMiA2NyAwIFIgL0ltMTUgNzMg MCBSIC9JbTEzIDY5IDAgUiAvSW0xNiA3NSAwIFIgL0ltMTEgNjUgMCBSCi9JbTE4IDc5IDAg UiAvSW0xMCA2MyAwIFIgL0ltMTcgNzcgMCBSIC9JbTE0IDcxIDAgUiA+PiAvUHJvcGVydGll cyA8PCAvUGwxCjQwIDAgUiA+PiA+PgplbmRvYmoKNjcgMCBvYmoKPDwgL0xlbmd0aCA2OCAw IFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4 IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA4MiAwIFIgL0Jp dHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt0AEN AAAAwqD3T20ON4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMDA08AAG+QAAQplbmRz dHJlYW0KZW5kb2JqCjY4IDAgb2JqCjU1CmVuZG9iago3MyAwIG9iago8PCAvTGVuZ3RoIDc0 IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQg MjggL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDg0IDAgUiAv Qml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3Q AQ0AAADCoPdPbQ43iEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwMDTwAAb5AABCmVu ZHN0cmVhbQplbmRvYmoKNzQgMCBvYmoKNTUKZW5kb2JqCjY5IDAgb2JqCjw8IC9MZW5ndGgg NzAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjcgL0hlaWdo dCAyNyAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgODYgMCBS IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB Y2AYBaMhMBoCoyEwGgKjITAaAqMhMGAhAAAIiwABCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBv YmoKMzIKZW5kb2JqCjc1IDAgb2JqCjw8IC9MZW5ndGggNzYgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjcgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQo4IDAg UiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgODggMCBSIC9CaXRzUGVyQ29tcG9uZW50IDgg L0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITAaAqMh MGAhAAAIiwABCmVuZHN0cmVhbQplbmRvYmoKNzYgMCBvYmoKMzIKZW5kb2JqCjY1IDAgb2Jq Cjw8IC9MZW5ndGggNjYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggNTkgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAv U01hc2sgOTAgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUK Pj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9tCU+IQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgz8 BwYXggABCmVuZHN0cmVhbQplbmRvYmoKNjYgMCBvYmoKNTAKZW5kb2JqCjc5IDAgb2JqCjw8 IC9MZW5ndGggODAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg OTcgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01h c2sgOTIgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCngB7dAxAQAAAMKg9U9tDQ+IQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgw8Dgwf1AABCmVuZHN0cmVhbQplbmRvYmoKODAgMCBvYmoKNTkKZW5kb2JqCjYzIDAg b2JqCjw8IC9MZW5ndGggNjQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMTYwIC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRy dWUgL1NNYXNrIDk0IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp4Ae3QMQEAAADCoPVPbQhfiEBhwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMvAMDP8AA AQplbmRzdHJlYW0KZW5kb2JqCjY0IDAgb2JqCjk1CmVuZG9iago3NyAwIG9iago8PCAvTGVu Z3RoIDc4IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2MCAv SGVpZ2h0IDM0IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA5 NiAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJl YW0KeAHt0DEBAAAAwqD1T20IX4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDLwDAz/AAAEKZW5kc3RyZWFt CmVuZG9iago3OCAwIG9iago5NQplbmRvYmoKNzEgMCBvYmoKPDwgL0xlbmd0aCA3MiAwIFIg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMDggL0hlaWdodCAyOCAv Q29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgOTggMCBSIC9CaXRz UGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dCBAAAA AMOg+VNf4QCFUGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAwDswI3AA AQplbmRzdHJlYW0KZW5kb2JqCjcyIDAgb2JqCjYzCmVuZG9iago4OCAwIG9iago8PCAvTGVu Z3RoIDg5IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9I ZWlnaHQgMjcgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRl cnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBZZJtU9pAFIXZ3bySmKKRig3QYC1WG4mpKNAWpBBNAHHYJDTE6QgIMziO //9zFzEh6n5JdpNz9zzn3kQiXACSBUC4jT0BojmepeD7bwCxUnpHFmgY+331Cmkpd6QXMwL1 ToaSGb3dqR/I7FsZoFP7Tf8OV3MCeiODXMa4mT+Orw63mNcyQEmFuv/wNMdnShK9MgLZ9LF1 ez+b+n+KKTpeESAxX73xh44/6v3Y5eMVIbN12HYH5oXt4caXD3EZSirla/fqVKv1h7b+kVvL iPOvTRc3DtTjyyH+pW6ssZfOrwP8u6h+b/0NbG07wgbUxl7Dn47Msl7p/Jt6P/MR9tJ5b7KY OPZldzh7uLMibICEfM2bLyYjF7vB/WKGz0Ns4vybGYyDQdeyrB6+Ha+xUfJTue/jVrmkaVrp vO34IfbS+YXjNI+UbVmW01mt5eD6ChtyOycdr2PsCgxN04yonHa9F2wkfq72B439VTzPNQb9 Sl5ECdKOvZptnoShkpsN06oVJAoQ3pxeMdQwU8ikCkallCNhAcTLWVXZ5F4aCBC3qahZmSdz AClelAQ2mggydYIkchRJH0BEUSg2mdHBfw7LRK4KZW5kc3RyZWFtCmVuZG9iago4OSAwIG9i ago0NTEKZW5kb2JqCjgyIDAgb2JqCjw8IC9MZW5ndGggODMgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2 aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21w b25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVtmSolgQLfbdBVfA HXFfUVQsNxRRyg1Fy9q6H2Y6YmL+/wfmYlV1T8fEvFW+QObNPCTck+dydwcMghFgMAx5ztcY hGAkw3EsTaBfBgujpD+azMoZKczhyNc0C6F0JNsYjCcjrZLw4/BXvD2EUJGCbu2do/MwbQg0 8hWgMBaQh5vTab/b71e9DId+CSgVb63dg6lrg9GonfoaUIRNDx132cpKSbmQjXqv/0Ewb8sg +HeDQBC6BSHv8snD9xBI/aAlwuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQBE6QNE0RBEl5nINg FCdJHEFQnGI5lsIR+D0E8iiawj1aImx25D4uazEGB4Yh7wTLZBJRH4kgGBuKhvlQPJGIhULR KM9iMIzRwWjYR5FsSExn0wLPYAhKBSKREB8REwJPo/AdTEva7skZl+Ic6AOGUTqcrWu6rlXT PIXR0Xy1rBQb3W4tL5eqSpxBUToqVxQxyEvF9kDvtxWBw4lAqlQpKBVVa8lhErmD8VDJcJ+c WTMdAg9BqGixv1jb9srQZJ4OZHtz435orKyx2hxM9WKYJIL5/qSbT2RbE8u218tRTeTYeG08 H+vj5dpoJ1gUglBGbJjuk7seFOMsTvDK0N7ZpmlvLS0djJQX7smeL6zlWG2N7HU/7eMk1bLv K8XOYruxTGvzMK3E+FR/6+5Mw1wZapJDoTsY46T67HC9HmZ10edLdh9O24mmzbaOWROF+sPr 88Owo6r1QkGznUU1HilM9xu91p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3mB8a5eGlgX57dRV2K l4zL47pXrQ3s866XTTS3b9d5NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23DcRfVRH58ed1psiQK Ee426YA3dCjTXrgv7rSaV73W9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV2X53X6lOL2+nWafZ nR/cZSOtjN1HsxxmQBrmaZLHYZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts2o92I0J4vCZC5fnx YC13R6slV+bP38+m3tNna3tcTimj43GUYT36eOoJuE4QGIoxQnP95M574+O3p7WutlStryqi 1FifrQqPecOFsKnB/ul6vTojRSrNn785s26r3e1rtbSQHx32gwT9KXEwxgR5P02QQWV2viz7 9/uXs9HMZ7M5OSOE4o31ySwHbyoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+TkXDISke8P255EfYIi VDijZIVQMF42zq6hdq2La9TToiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8L9nbP276iiSIyZQY Dsv3+60m/gJlpLquq9Vifbi57PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ//HB7CYaKVM2TM1dL +UIZjFfsP6AJ1dzYy7m1P5/mVUmqzA6nzWI8mkz6JUmsLw9GMfAushDmz0/P12UlRGBcSrNP h9V0NJ6OWllB1jd2R/jZKUxFK5PN8XRyzweznfD7xbqxOzp7MC7DkhArjS095/tQbpiKNw2z mwS7TPDyYH08HnZb22ino2l1YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1suZ6LREMJhvdqsh8 nDGg1VStnuMJoI9USO5MrfXKnHSVaCBWUFu5IO5JsGcQgnPRdLHebFRyMR8QR4yNZsqNZr2c E/wUFZRSgp/47AAhA3FP3CBQRgYlpdZs1gopwHkumkyEvfiHAYUl2UA4EuY56qbLKMkFPddH AaEkGI4hfp7bYAJohgSCeWuG8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J8BQMJzwXSDqYNqDs P5OBD/5kbi6oQj1d99a9+9/y3gvAkfOrFBxD//Z+Qno3v638X94/+3vn2QplbmRzdHJlYW0K ZW5kb2JqCjgzIDAgb2JqCjE0MDgKZW5kb2JqCjg2IDAgb2JqCjw8IC9MZW5ndGggODcgMCBS IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjcgL0hlaWdodCAyNyAv Q29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRy dWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAFlkm1T2kAUhdndvJKYopGKDdBgLVYbiako0BakEE0AcdgkNMTpCAgzOI7//3MXMSHqfkl2 k3P3POfeRCJcAJIFQLiNPQGiOZ6l4PtvALFSekcWaBj7ffUKaSl3pBczAvVOhpIZvd2pH8js WxmgU/tN/w5XcwJ6I4NcxriZP46vDreY1zJASYW6//A0x2dKEr0yAtn0sXV7P5v6f4opOl4R IDFfvfGHjj/q/djl4xUhs3XYdgfmhe3hxpcPcRlKKuVr9+pUq/WHtv6RW8uI869NFzcO1OPL If6lbqyxl86vA/y7qH5v/Q1sbTvCBtTGXsOfjsyyXun8m3o/8xH20nlvspg49mV3OHu4syJs gIR8zZsvJiMXu8H9YobPQ2zi/JsZjINB17KsHr4dr7FR8lO57+NWuaRpWum87fgh9tL5heM0 j5RtWZbTWa3l4PoKG3I7Jx2vY+wKDE3TjKicdr0XbCR+rvYHjf1VPM81Bv1KXkQJ0o69mm2e hKGSmw3TqhUkChDenF4x1DBTyKQKRqWUI2EBxMtZVdnkXhoIELepqFmZJ3MAKV6UBDaaCDJ1 giRyFEkfQERRKDaZ0cF/DstErgplbmRzdHJlYW0KZW5kb2JqCjg3IDAgb2JqCjQ1MQplbmRv YmoKOTggMCBvYmoKPDwgL0xlbmd0aCA5OSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAxMDggL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAv RGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAv RmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1Vll7qsgWjcooIIpoBMQZcR5QnDXi CCooTokxOSd9T5/+bt///wNuYU7S3ffhvmU/7dq1ay+K2qtW3blcbo9jbrfbdfe15nJDqJcg SYLAUdjztWhumAjysUQiLvIhGoe/dG8enM0ovcGg12lWMhEK+UowDxlTjcPR3lobfViOUrD7 684MojPa4/fnvWXtT/aswnk9X4jllxfX153W7U13T4cHyQ9/XX9Agdzicp6UEsmSdrisqiEU NP+HuRxc120EvE/n3fucA6y50ebXUb9zyBk4EzcDhHKyAdb80e7E/bTQMC9WI4J5YBRDERTz ejEYJHkQDPc6fHADdmAg5LoDMdQhCOALgmEIBCE4SVGEM+dyeWDMoRAGAxRnGpQC6xEIoN2w du0oRXL11Xmj3OMIGQyzTDASFcI+DEZJ5l6I8iG/F0GIQJj1oR43hPvZIOU43kCIpb2EPxJP JaOhWwijw2IiEQVrIZAXCgWZEB/lGC/kdrAWT4ehFOGknnWYFYKYN5wp5iW50mwUogEfK+Zq zVajkuH9VDCel0UagTA2WchFfTCEh1L5rMDep6qdfq+ZF3wo7GWTZbXbVYtxxosHYrlCVioo ai3NYp4b1vW67taU4ea07ad8mC/Zmmj9nrZc9PJiVFbHC8PQ58NaMhIt9gYVnkDpZHs2Bi2L +tOtoZqNZdtL01zNOnKYIMJye6obxlJT0yzNlYeTYXc417V6lIRcYF/Lb79ftyvz9PJstmIU FshPD3tjMl0shtVcZaCba11fWeZczaZrE2MkB6lIbfV8GksBiq/PjX5eauino7nQugWOZqWe YRqzmbFZqMlIor05mDNtttQUkbph6W///vF8fnp9e9n2pSDJllbXy6rXUBq1cn20tpaDptKZ mLuFmq9qlt4Qw+nh0x8/rHo0LA2tVVuSutvLftquFRMhRmyu9puRqo43u1k1kR0eX/aaCipJ 94C4zr6+/3y11+vt4XxYqgk2Utm8PE6KMV6Iy21jp7ckgYuXx9vtuFrqra2HQrqqf/vzj8dR Lq0sd7OymFCtiz2uZqIhms1qp7PeKpY6xtHsyPmH09VU0wLPhcDtd8N6eTEH9arSm2/3SyUe ra6fd23Rh5OsNNhuhxLjxSi+ttzrzVx9tjN6zdHu5be3i9Fpji2zlwreF2eHo97JCQEqXDbA P+nWaj3jYA0KxYfDeZZnCRy/ccXpw8vxQeZC94na/HTUCsm6cTYqgNOwXxrb6yaPe27ubtOW 5J5prxab49EGN5qxtPbLaoTwiY2lbeu9fIThFevbdTNqtwfz1VyVCyPbHiRIyCE0IDPAmj8C fpEo5k/2D88rJavox0WBge8gOqvZq/o9CnZPpYY7s52MVZfny+VyMkaa+Qgce5ihETSQVKbW fjPMC7Hm9vVJ7yo1RW0rciI33FqdqPfjOr9hbVsCASNUvHd8MZuyou9n+QB05/GlH2yzJZIw hDI5DWwxGs4MT//6+Wb3S7Xp04+f38wG74UQMpSoPlgnqy+nG+vno1bNJJOpdELgwBlsWgL+ NyzA5UEm5Gf4wvTxuqpLAGuac7CIWMe0tSJHU0xCXe0X5TDNKdsf/3kzKrFke//zz5epHAD0 DYSFdH1+elzWMpXZ6aCV4zwniCIXkQbWRuX/gXV9NloFOV9/2IGTyydrv7DcWLg8s81RRUrl 1LltDdI0HsjOXn5/GqWC4aL+/cexIxIwxsQkuaBMT89rJSl1zcOqV5KkXCGXFOXhP7H88vz6 9rieaVN9dzrMq6JQnm812Q/duSBfvKXvzPlooBnb7aQcwWGv0LIeVzXQEPGefV4UWQQiuGJn MBhvzud5iecL4+1+PR0ORqN2ISn310aD+2tfvtTo+Ho97Xe73XY9rooMKw8X3ZQPurtzY0ym vbAsy7SstVZ1RBth5P60k6YRLFQcTZoxCvJ4ufJouTbt/aqdCNB8WTPtnbVZgxsulm5Otco9 9nFeHoKvjI31Sl/OtEFT5n24T6w0izwB9NnlwYPJWh/cVvNxuyD4wGPEQ3ByWQrjHoiK5kup IFA7NJhujGaLhaZmgjhKCcXudLlcTLqlWIiTlVoqgDja5ZgbpYVsqVIplwrZJM8QMIQFhBhH g0Z3wDCaS+XLlVI2FiKdd48boUIcSwJxQulwBCiFywV52ZhcrpZlkcEhD0yGE/lKtZxPcX7C FxajLMi5ITnlUNLPsGwwyPgpHHHEESUoAn1/KgLlw30MGwr6SdRRO5CO4I4OAk1EcC8GROnO DWFkgA2zARIoGpBPjAqwIZbxAX1EvCQJ3oG/oMBqtwd+N+hdqkEAeL++Bag4BCMIAmT5PXJT +Buqo/u3IKgPI+hHyscIXBZOpb9KfSL+PwcI+8dfcNI+R5/OLfa3nP9Z8Fn7v3fKQ+AKZW5k c3RyZWFtCmVuZG9iago5OSAwIG9iagoxODAyCmVuZG9iago5MCAwIG9iago8PCAvTGVuZ3Ro IDkxIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU5IC9IZWln aHQgMzQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBv bGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBlVX5k6JWEB65RMULZMYbcFDxFi/UERRvUA518JidmWSTVKXy//8DeWjtblLZ 1M72D/CK19/r7vd1f9x5IAi+GgR5PHc/Yx4IxQMEsIAfR2HoZ8AQStBpluM4Jh0nCS/8E1jY 9yB0R4o8GkqikCF9yMexSIgbGs7zzjINfdrlKfzjcdFoafnp14u93drPh00/F8Ggj14VSlb1 9zdD6fUU3TnprYQP/ji0tnl1FCGdzvc252clF0SuZH25a8DdjTyXuhuRgMXr6ShZ21ysTjLo p/KT43khkDgeCAYDgCng4IEQr89/pc6LQBCC+Ygg4cNuJAKofjFbcZ83zMnOy7oapx6yXC77 EMZh4IuHYokMw7LZeNSPeQkqyXBMggyg7oW4UV92EkNGEpX56bysc3xNGsn9OkviCBqg2Uq7 /zR66lWzJBFJFcX+QBLziaCLdaFv53mzUGgo1nmn1CodVTdta9nLRfHAg9CfacbeOejDYoJm mspS09aLUTVJAP4BdPv5N2c1UVeWs5+1SvWnhbaxHGctpsKxwpNmGpbz+rqThTQrzrab5Xy5 0cdlGodcqPHHX5+Ptr3bG2ojxwitXrenGKeDzN9nWmtLG8sr58Xq80xFtXeLfnuwtLcDNohc ob//+b7X10tVKqUoKsXl2Mf6zDnNy6nHoWEotVJPe9bbXK5rnO1xoyyq9mFWiqIeN+Ff3k25 Xa/kMzEC94dj9wmmNjteVtU0PzQ2w+KjuNitmlxBdl73k3ajM7UOi2oMg9xrAi1RTMbIcMCL IBhBpXIVaX0GPKXYztpQO80n3Z5VGUG9vD/PB73BZK3JReoGdVsigKEIIBLGSabSlmT9dAEU J8qqZWpL3doM+FRxenmzJ52m2JG61UzomrB+MZo0dm0uCAuzLVmWJHV3XFVokhuYp+Pe1Eal OM0rzmUjCTk295jLUH7ErfUGvbYlhD/Up9qkVRsYjla7j2a629PRmPaEeDCU6ZnHjZRPJZKZ bNId7H9D4UBGMnazVm1ono1OhmYlw7HUVj4e8vro6nxvT1sCXyiV83HQEyhZWTt6PYZeo8L+ dM941p56k/2ng1zMFpX92Ro3HxMRnzeU7Wp7azUeyeNRk3FrjRTG22mJvEHdhOfWdqbMrONO bQji8vx+1OR2mYkRfuqxv97tLGOrqWI2iHgQItMciEwIudWKhhlRUUdSX5lNh6I4Ml7eTrvN Su0V7olA7LE9Xq5Xc6WTp4EiQN5omsuQ+E0bPLA3ksqXBD7HC+Vyvb+y9+Z6sdqa2pCP4r5o Kl9tNKqFbMwdO+BMhAj8ixB6YCwQochIOELSqbJiWot+o95RzcO6GfchWCBM0TQVIcDc34QA Ac1wzRc8PBCMYiiKIChOFie2IVdYpijpjtFN+WEIRjBgwP0mMV9AX9+e6w/Eg4RyI8MYN/J8 dagfXMFzzweb/wP7ir+7g/3J5nyzBK01Wmy3Y4Hyfk3tH17fXUJYhGuP58CWq4VcuwrDdx3/ +9EDRiFbvipTXywkgh/XdlAW7A3SaY7P82zSFcEf1/gtvqvCgVA4Eg76sSsb37Z+vAJUIcDA IH8n5N8Xe9XcCmVuZHN0cmVhbQplbmRvYmoKOTEgMCBvYmoKMTE5MAplbmRvYmoKOTQgMCBv YmoKPDwgL0xlbmd0aCA5NSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAxNjAgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsg MCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAG9WGeb4jgSbmyMbcAYY7JJNk3OmGRyxmSb0HT3zM7M 7uzd7HPP/f/PV4Kmm57bdPdh9AEkVUl6VaV6VfLd3bkYMCiGm+pt/aJy/QVV/FyuA66CP/2/ LHCZ9U8Vf1dowAmSJHA0HKoUTRrPYM/dJhy7GWPAjCbaYoViAa3ziBvpH1bRTJTpMusfKv2h wICTDGe3EAAEqjaXhz/X7zDCbHewtPFm2wactntDoihGQn4XSxMvRv/DqS8CtADvtL+b6S+G 3IoxE+sLBxwUmAMjbMF0Ie61IFAYaQ+IQQd9YybMZA/nlU6n3VIquaiHMd0a93bOd3WD0eqL JUIc+be03w2FBkYw/kQm6qTxuzvc7C2M5p0Ej6bCSD6az0UcN9NilCc/3h332mazmrWzAoOM /pcFMzni9VbOZ4YV/udiwM2epFyKIhgGwn7fP33SG0ELMqaJk2SlELK9gcDNgbr+6afjZrXZ HbVhzos29ZcFI935sVoPWf+O8vezYaTjvtIsBhlwKUZ5S5tf//V5mnKA58AtgWK3lb0BgVtC rcOnh6lSVcba4657byduTuf3U1/bMG15vmmLzP+BD0AES71W2k0hQDaxc/rt37/qVQH5AiOd yfZIARBXL+KWcOvwtJAlIZwb7J8WBTeFA9EY7gwvDIKI6lJQ54WLMMAnL7cdyUbgOFKGODxL XijqqnbZqeHMX6+BBxhS3YkisWAIjHTlZs+/fP35NIgjwxiMTLg+Gxd9r15E+HbHYYK3MIK8 ftbqQYY+EwfwDgUUhXiENJGU2UwROOIiK8NYKJPZJy+1XtzJWC3QD3sxkmYrYzWfKQfI56KG JIjfgL9A7QUheKymTmXBDObDraHG5nTcnR6XZR+NIoTyFqfLdpS9cswF3yBmJ2lPYfm8a4pu lwuIAzPSdhfPUKSVdzsdvDcguG0UaXH4wpIU8thZv7zcjQtSKBRws5QRN1l5ISJFBERkmJGy e8OSGHAxJGyJYt3BSCQAw8+0YSC45GAzyblIFA+O1GivjXvqQe9GkUENhCM13E7zrmsII3z7 0yTjtfNiffu8bcTEeBKIAye5cDLmszGe+0wqlshX5HSQ54VEudlp17MhT6iyflh3q5VaNSfy NMX4k3Kz06okfAxhpJ1SodFqVlKCjSTMTjFXVZRqJnzhNRQRC32YsIOFcLNQWe2nclZZH1U4 WWBAnJE62roO4Xw564Cvffy4bWXi6drs+DArxbINRBxGsz/fqsdcvFQbDlrNwWzayoj3pf58 vVmr7UxIrG4/npaj4VQd16I86021ZuuttuplvRbKLtVn6/Vi3Ei4LRZ3oj5S5/PZoHomlDtw b1PbdSUILSCXWH+vdxOR3OSotyLngDYHFW3fj9qMb/hOv3zcjPqj5f64bMSl8pk4CGu4oY5y Pg84YDcfjqbTTjlfm2j6Sp2O27mIVNM/f1gPOqOVPpfD7nB5oC5WuwetE+MYb1E9HtbTgZL2 sc5Yc76ej8fz1bQaZsCDRltseNw1Q2AgZMrVk96ORzLDhyc16wSnYpSvuj3N0hzxiq/z9O0f H/aavtPURswXrpyJwwR23sxLgi+3+PC0aMpluVSsTXR9ppTy+YwkRGraT8dRKV0a6rt+Ughn a/WqMjmc5gUvF6htn3ajejETcTmClcVu1a1W+yttnEWnysilZo96XaAxCFape/r5cVwp1Ocf fz4gzAZg1vLmeVVwmi7Bj/z7+M+vj5v5bNQuik67gIhDZABfd7soB3z51cfTMBPyC5F0a7NX ZdHr8nh4PljdPC7lsCckL+HoBHyhqCgmlM3jthrghMrmSe8X7gMu1hkfHB/UWibbmB/WtQBw HOHILZ61qpfCELksv3z7slMni+PX3z7NEEcbTM7C+sO27IbwQQXhe/hymjaKuaTkY2kLEMd7 fEtEOjba6oz39G1bslMkSVFWPxzsUZI386nxflEWOIfbG4g11k9wU9ldmfH+oDaSAse4c3Mw v1IsNuf7jRKG+4bg86sPmuwhMTiJyuHXb18e9/r+6ZdvX/Ua4uiLvOKlXvGd+Vn0ODmGJowX 4r213/xhjsKdsMcHu1UFWAqxL434rxu1mWz3PX0p+1m7J5wo9vUPeyVkswXlma6rzZTX4S9v Pn1Ydev19mQxkVFUntffym4SyCU5fvr8pC1ms9lSf/584ejfwXfmZ9oE/IsuhjIsLIF/o10N +TenHqZpB3FnZAHfsgz7BquD2quZO9pSDjh98WJVGWrPOyVkpTmxPNrsVp2UEKpsf3pUlXKx XK2XYy64FsC/y+et7CVxs7+yPunDSj6bzeZro90JcTR+8S+y79W/rd3hNZ4x0lNe6P0YS7Gx gb4849uNU5wR4g4stWkErXCn4EZkv8sxEDvbZVUMpZVus9aaHzUlxFBWV6TQ2xw3rURUXj4f BoV7UZSiER8LOYCRS88etaqPNtljvd2unxacPM+7AtnhTu8AR5Pu0uZ5XbyJD8DXi9oufGgw uQrz/STrZr252XEtg/1mu1ES8KHTst0Psz4W5do2oXKDrxZPNdWZki8N93pL5BjOLURLk+Np VrzPj4/7QS7s9wnBoMeG8LHAL1ojYDF7ivPDvOSzmAiCMFkFeXEAjqZpb2X7qGbAYzf2e8NH ONKT/UqJRxItHdzwhg8SxcLssO0VYhFItd3h6g2+eqo43q2audLocBik/N5wPJEuj47Py7IY U9b7RTMbiyXTyTBkzHe4NdLS9HbEZgs31lr3Ht1qkF4AVffg3ggx1kBDOwxib/wMZtE7iM7P xWiTWhtdbVWb6unjuiR4s5PtAC4jmIGVlNVem3abjUoqLFXUFTA+wURaK7WaLIwP2rCmqI9P ajkazTXa7f7q4WGS9fvT/e1uOeq0u9160g3nDzuHVj/mcEiKijKVl3Nm9pfGM0Xk7HC/bRVE 3+eCmf3lqVp7zTRx2pPtr9bqaDTXd+OM153oTBUJdmPAKVeitdC0zVLtl6RIvj+uBCyEJVAZ 9wtSornaqr2euj/Oa8l4qTdbrvXdoh7hWH9usNa1zWo5bSZdAAYygPRoM864HaFCvRS5mA8i zmQXS/V8kHMmh9tZAcL7BR/pjFdqKffLNmA4I2Sbg0FHabbbsuiwB/OVjB/txmA0u2NybzKd DhrpgC9alBMu2ki7EnJR8vpTSr+n1JqDcacghuJydwxq1XueJhkho4xms+lQyQbQ+TPgTKQx n5YDnDMQETjw+LnA9jkhEnCyvsJk1XnxOkgwwuoOhb1vzw7MxHjEZDoRFSUpyFvMnBDysRdS MdKccJ/J59NRH8c6A0EPQ+AE4wkGnIzNLSZTcSkaT8WDTs4dSuQKuQS8xIw4zB9J5Qu5FLA/ iTIsOMi5wawhcVbGZjn3vAAkLTbGwoaqk1HR/5qfGjCCZhiz6fVJhzpsDt7BMjablSKMpIW5 zmLATWaWd7l41kJCogrZKI66rKBmQmM4luUcwPIkbeWcbidnhfQPMleK4Zwup8NGvzzICZtY G3bSLrgNQH4xH/xCmm0kKD7eHDbuudf8/tz933omwogKYmz8TXqewmQyoX4cSVHGf66gudEY oAokhAaJ+P4cmi8t4/X7BEa5Us1OMWC95shvEHGLL9dqZjyv5nsVva9AWv6+460Fot+Xnfuv QqT1pvaucX6l5eryJR18mxhqcIlGUJDcvC/fyX9QA30TyObvXShfflfg5Snlsu/e5+/kP6gB seoISiEHdXP6zktjJAffN/jb7xs/CNL7ZQAgyzuswDbvC0ZYOP7996H3Cj+qheEminrjjOuy 6C0K3d/Dvop/4D/KIb/3LiwP3dco/4Fgbpf6D38C3cUKZW5kc3RyZWFtCmVuZG9iago5NSAw IG9iagoyODczCmVuZG9iago5NiAwIG9iago8PCAvTGVuZ3RoIDk3IDAgUiAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2MCAvSGVpZ2h0IDM0IC9Db2xvclNwYWNl Ci9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1Bl ckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1YZ5viOBJu bIxtwBhjskk2Tc6YZHLGZJvQdPfMzszu7N3sc8/9/89Xgqabntt092H0ASRVSXpVpXpV8t3d uRgwKIab6m39onL9BVX8XK4DroI//b8scJn1TxV/V2jACZIkcDQcqhRNGs9gz90mHLsZY8CM JtpihWIBrfOIG+kfVtFMlOky6x8q/aHAgJMMZ7cQAASqNpeHP9fvMMJsd7C08WbbBpy2e0Oi KEZCfhdLEy9G/8OpLwK0AO+0v5vpL4bcijET6wsHHBSYAyNswXQh7rUgUBhpD4hBB31jJsxk D+eVTqfdUiq5qIcx3Rr3ds53dYPR6oslQhz5t7TfDYUGRjD+RCbqpPG7O9zsLYzmnQSPpsJI PprPRRw302KUJz/eHffaZrOatbMCg4z+lwUzOeL1Vs5nhhX+52LAzZ6kXIoiGAbCft8/fdIb QQsypomTZKUQsr2BwM2Buv7pp+NmtdkdtWHOizb1lwUj3fmxWg9Z/47y97NhpOO+0iwGGXAp RnlLm1//9XmacoDnwC2BYreVvQGBW0Ktw6eHqVJVxtrjrntvJ25O5/dTX9swbXm+aYvM/4EP QARLvVbaTSFANrFz+u3fv+pVAfkCI53J9kgBEFcv4pZw6/C0kCUhnBvsnxYFN4UD0RjuDC8M gojqUlDnhYswwCcvtx3JRuA4UoY4PEteKOqqdtmp4cxfr4EHGFLdiSKxYAiMdOVmz798/fk0 iCPDGIxMuD4bF32vXkT4dsdhgrcwgrx+1upBhj4TB/AOBRSFeIQ0kZTZTBE44iIrw1gok9kn L7Ve3MlYLdAPezGSZitjNZ8pB8jnooYkiN+Av0DtBSF4rKZOZcEM5sOtocbmdNydHpdlH40i hPIWp8t2lL1yzAXfIGYnaU9h+bxrim6XC4gDM9J2F89QpJV3Ox28NyC4bRRpcfjCkhTy2Fm/ vNyNC1IoFHCzlBE3WXkhIkUERGSYkbJ7w5IYcDEkbIli3cFIJADDz7RhILjkYDPJuUgUD47U aK+Ne+pB70aRQQ2EIzXcTvOuawgjfPvTJOO182J9+7xtxMR4EogDJ7lwMuazMZ77TCqWyFfk dJDnhUS52WnXsyFPqLJ+WHerlVo1J/I0xfiTcrPTqiR8DGGknVKh0WpWUoKNJMxOMVdVlGom fOE1FBELfZiwg4Vws1BZ7adyVlkfVThZYECckTraug7hfDnrgK99/LhtZeLp2uz4MCvFsg1E HEazP9+qx1y8VBsOWs3BbNrKiPel/ny9WavtTEisbj+elqPhVB3XojzrTbVm66226mW9Fsou 1Wfr9WLcSLgtFneiPlLn89mgeiaUO3BvU9t1JQgtIJdYf693E5Hc5Ki3IueANgcVbd+P2oxv +E6/fNyM+qPl/rhsxKXymTgIa7ihjnI+DzhgNx+OptNOOV+baPpKnY7buYhU0z9/WA86o5U+ l8PucHmgLla7B60T4xhvUT0e1tOBkvaxzlhzvp6Px/PVtBpmwINGW2x43DVDYCBkytWT3o5H MsOHJzXrBKdilK+6Pc3SHPGKr/P07R8f9pq+09RGzBeunInDBHbezEuCL7f48LRoymW5VKxN dH2mlPL5jCREatpPx1EpXRrqu35SCGdr9aoyOZzmBS8XqG2fdqN6MRNxOYKVxW7VrVb7K22c RafKyKVmj3pdoDEIVql7+vlxXCnU5x9/PiDMBmDW8uZ5VXCaLsGP/Pv4z6+Pm/ls1C6KTruA iENkAF93uygHfPnVx9MwE/ILkXRrs1dl0evyeHg+WN08LuWwJyQv4egEfKGoKCaUzeO2GuCE yuZJ7xfuAy7WGR8cH9RaJtuYH9a1AHAc4cgtnrWql8IQuSy/fPuyUyeL49ffPs0QRxtMzsL6 w7bshvBBBeF7+HKaNoq5pORjaQsQx3t8S0Q6NtrqjPf0bVuyUyRJUVY/HOxRkjfzqfF+URY4 h9sbiDXWT3BT2V2Z8f6gNpICx7hzczC/Uiw25/uNEob7huDzqw+a7CExOInK4ddvXx73+v7p l29f9Rri6Iu84qVe8Z35WfQ4OYYmjBfivbXf/GGOwp2wxwe7VQVYCrEvjfivG7WZbPc9fSn7 WbsnnCj29Q97JWSzBeWZrqvNlNfhL28+fVh16/X2ZDGRUVSe19/KbhLIJTl++vykLWaz2VJ/ /nzh6N/Bd+Zn2gT8iy6GMiwsgX+jXQ35N6cepmkHcWdkAd+yDPsGq4Paq5k72lIOOH3xYlUZ as87JWSlObE82uxWnZQQqmx/elSVcrFcrZdjLrgWwL/L563sJXGzv7I+6cNKPpvN5muj3Qlx NH7xL7Lv1b+t3eE1njHSU17o/RhLsbGBvjzj241TnBHiDiy1aQStcKfgRmS/yzEQO9tlVQyl lW6z1pofNSXEUFZXpNDbHDetRFRePh8GhXtRlKIRHws5gJFLzx61qo822WO93a6fFpw8z7sC 2eFO7wBHk+7S5nldvIkPwNeL2i58aDC5CvP9JOtmvbnZcS2D/Wa7URLwodOy3Q+zPhbl2jah coOvFk811ZmSLw33ekvkGM4tREuT42lWvM+Pj/tBLuz3CcGgx4bwscAvWiNgMXuK88O85LOY CIIwWQV5cQCOpmlvZfuoZsBjN/Z7w0c40pP9SolHEi0d3PCGDxLFwuyw7RViEUi13eHqDb56 qjjerZq50uhwGKT83nA8kS6Pjs/LshhT1vtFMxuLJdPJMGTMd7g10tL0dsRmCzfWWvce3WqQ XgBV9+DeCDHWQEM7DGJv/Axm0TuIzs/FaJNaG11tVZvq6eO6JHizk+0ALiOYgZWU1V6bdpuN SiosVdQVMD7BRFortZosjA/asKaoj09qORrNNdrt/urhYZL1+9P97W456rS73XrSDecPO4dW P+ZwSIqKMpWXc2b2l8YzReTscL9tFUTf54KZ/eWpWnvNNHHak+2v1upoNNd344zXnehMFQl2 Y8ApV6K10LTNUu2XpEi+P64ELIQlUBn3C1KiudqqvZ66P85ryXipN1uu9d2iHuFYf26w1rXN ajltJl0ABjKA9GgzzrgdoUK9FLmYDyLOZBdL9XyQcyaH21kBwvsFH+mMV2op98s2YDgjZJuD QUdpttuy6LAH85WMH+3GYDS7Y3JvMp0OGumAL1qUEy7aSLsSclHy+lNKv6fUmoNxpyCG4nJ3 DGrVe54mGSGjjGaz6VDJBtD5M+BMpDGflgOcMxAROPD4ucD2OSEScLK+wmTVefE6SDDC6g6F vW/PDszEeMRkOhEVJSnIW8ycEPKxF1Ix0pxwn8nn01EfxzoDQQ9D4ATjCQacjM0tJlNxKRpP xYNOzh1K5Aq5BLzEjDjMH0nlC7kUsD+JMiw4yLnBrCFxVsZmOfe8ACQtNsbChqqTUdH/mp8a MIJmGLPp9UmHOmwO3sEyNpuVIoykhbnOYsBNZpZ3uXjWQkKiCtkojrqsoGZCYziW5RzA8iRt 5ZxuJ2eF9A8yV4rhnC6nw0a/PMgJm1gbdtIuuA1AfjEf/EKabSQoPt4cNu651/z+3P3feibC iApibPxNep7CZDKhfhxJUcZ/rqC50RigCiSEBon4/hyaLy3j9fsERrlSzU4xYL3myG8QcYsv 12pmPK/mexW9r0Ba/r7jrQWi35ed+69CpPWm9q5xfqXl6vIlHXybGGpwiUZQkNy8L9/Jf1AD fRPI5u9dKF9+V+DlKeWy797n7+Q/qAGx6ghKIQd1c/rOS2MkB983+NvvGz8I0vtlACDLO6zA Nu8LRlg4/v33ofcKP6qF4SaKeuOM67LoLQrd38O+in/gP8ohv/cuLA/d1yj/gWBul/oPfwLd xQplbmRzdHJlYW0KZW5kb2JqCjk3IDAgb2JqCjI4NzMKZW5kb2JqCjg0IDAgb2JqCjw8IC9M ZW5ndGggODUgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUg L0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0lu dGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAGtVtmSolgQLfbdBVfAHXFfUVQsNxRRyg1Fy9q6H2Y6YmL+/wfmYlV1 T8fEvFW+QObNPCTck+dydwcMghFgMAx5ztcYhGAkw3EsTaBfBgujpD+azMoZKczhyNc0C6F0 JNsYjCcjrZLw4/BXvD2EUJGCbu2do/MwbQg08hWgMBaQh5vTab/b71e9DId+CSgVb63dg6lr g9GonfoaUIRNDx132cpKSbmQjXqv/0Ewb8sg+HeDQBC6BSHv8snD9xBI/aAlwuUmrjsrhFnW zwcZHL4RjGUZEoNBLkaQBE6QNE0RBEl5nINgFCdJHEFQnGI5lsIR+D0E8iiawj1aImx25D4u azEGB4Yh7wTLZBJRH4kgGBuKhvlQPJGIhULRKM9iMIzRwWjYR5FsSExn0wLPYAhKBSKREB8R EwJPo/AdTEva7skZl+Ic6AOGUTqcrWu6rlXTPIXR0Xy1rBQb3W4tL5eqSpxBUToqVxQxyEvF 9kDvtxWBw4lAqlQpKBVVa8lhErmD8VDJcJ+cWTMdAg9BqGixv1jb9srQZJ4OZHtz435orKyx 2hxM9WKYJIL5/qSbT2RbE8u218tRTeTYeG08H+vj5dpoJ1gUglBGbJjuk7seFOMsTvDK0N7Z pmlvLS0djJQX7smeL6zlWG2N7HU/7eMk1bLvK8XOYruxTGvzMK3E+FR/6+5Mw1wZapJDoTsY 46T67HC9HmZ10edLdh9O24mmzbaOWROF+sPr88Owo6r1QkGznUU1HilM9xu91p47x+Wgo1vO Vs/Fc6Pz28nQ1E5Lid3mB8a5eGlgX57dRV2Kl4zL47pXrQ3s866XTTS3b9d5NSWK8YhQnjmb fj7XWTtLtaaDjZg2K23DcRfVRH58ed1psiQKEe426YA3dCjTXrgv7rSaV73W9FZraLt7PZ9q bl6cftJHURTJJbWNY3bV2X53X6lOL2+nWafZnR/cZSOtjN1HsxxmQBrmaZLHYZTwiVXj/LzT m7rz/XU76fdHy4dlJ5ts2o92I0J4vCZC5fnxYC13R6slV+bP38+m3tNna3tcTimj43GUYT36 eOoJuE4QGIoxQnP95M574+O3p7WutlStryqi1FifrQqPecOFsKnB/ul6vTojRSrNn785s26r 3e1rtbSQHx32gwT9KXEwxgR5P02QQWV2viz79/uXs9HMZ7M5OSOE4o31ySwHbyoDE5Ha6uXP H2+bthSRJ5fnTb+Uy+TkXDISke8P255EfYIiVDijZIVQMF42zq6hdq2La9TToiAlkzE+3lid FqV3UAjlsqPrX3+/zgu8L9nbP276iiSIyZQYDsv3+60m/gJlpLquq9Vifbi57PRSebhzH4Y1 RSlVSumY+C/QO5iMtXZ//HB7CYaKVM2TM1dL+UIZjFfsP6AJ1dzYy7m1P5/mVUmqzA6nzWI8 mkz6JUmsLw9GMfAushDmz0/P12UlRGBcSrNPh9V0NJ6OWllB1jd2R/jZKUxFK5PN8XRyzwez nfD7xbqxOzp7MC7DkhArjS095/tQbpiKNw2zmwS7TPDyYH08HnZb22ino2l1YTRi5Oc39Qaq OpivbHt5X0/6CQK4+mK1suZ6LREMJhvdqsh8nDGg1VStnuMJoI9USO5MrfXKnHSVaCBWUFu5 IO5JsGcQgnPRdLHebFRyMR8QR4yNZsqNZr2cE/wUFZRSgp/47AAhA3FP3CBQRgYlpdZs1gop wHkumkyEvfiHAYUl2UA4EuY56qbLKMkFPddHAaEkGI4hfp7bYAJohgSCeWuG8YeAigZYAkWA XrOg+hPTW4cRzBPoj18J8BQMJzwXSDqYNqDsP5OBD/5kbi6oQj1d99a9+9/y3gvAkfOrFBxD //Z+Qno3v638X94/+3vn2QplbmRzdHJlYW0KZW5kb2JqCjg1IDAgb2JqCjE0MDgKZW5kb2Jq CjkyIDAgb2JqCjw8IC9MZW5ndGggOTMgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggOTcgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVj b2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmls dGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVmmXosgSLXaURQRZ3FlEccOt3NCy3RVx A7XK6j7v/f+fMcnUdFkzpz9WfCEumRn3JBE3gqcnYBAMI8BgCArRtxsEo3iEZhiKxADHt4d/ ghCc4lOqrucULoJ+PwME47G01RlNXoZNQ4yi334FGGOzzal39s+HVc+I4/B3fyMkotiL8+V8 OBy9H1WZ/G4CCI0ZL+fLbtLrOeO+JUW+nQAXquvbaVTKpNVCIcMRCAwMJAKULniGGYE+avgj /X8Cf6fts9T/cwIixIb3tu9k2CjDxdkIhhEkgSEQhIQOKCrgkFGGoaN/BBRNg+oG3GDbZ6nD KBGeiOBh1UN4wt7dz0ONIzEcxzCciosCjcMwTgtiPIrCKMlKGc3Q0gKFIf8BMSmrqhmJJcNt nJLXtYzIEChOJzKqnk+Gx58gjCvNb2/bdp6PAp0hpKCVC3IUQaJywVIFEo8mtHpv/OK0TYki /gUosNIdDrvVPB/BIwm9MRg5z+V0LBpLlbvOqN/QExEEekKoTNe737b9ksISCEplW+OeHkPR mN4bNzMMJZUGqz2osMWzGme+AlYq9Rdb193MuoZA83p/czjslgNLjqfqU++43/xo5VgMeoKJ eGG4f309Thv5OImzxng3r/AYxlfm7sgQRHPk+afdZg3CSHLxC5BMxz24y6W7X3dVMd3c3q6H 9WxYScvmi//mu8tJW+UAAYREhEJ/e71ftz1DoLji7LypJ3A8Ud+cpiUl391dDtPnRsMuZWX1 ATIhCPaTbne6Py/tnD44vQeLfrOqykpldb97445dTDGAIGTg1ebsdH/bD3QhUZoHWzsksF1/ Vs6Vp/55UklLkiwKsjX7BLxkzW6v2161NnCvh4FZ6B3f/WmjkBFjCWvx+ub2y6rCkSAHIQPB Ji3HA7SdrGJ9JajqrW2waSoUQZAkLTcegJJs99f7bthsOu7l6Jj5+vJy3Q6sNEfF8oPj62na 0EQaA7INBYVgUUHv7d9vUytbmfufN5jXzK7nz4rgUwKBRZT2A5By6/j/X/tJvz9e7VbPqqx2 Nr6/dcoKQ4nW5BAcZy01Dm4QDgMCx1AyboyDd7epV+e+2xBxXGy4/rxW7Hn+1GRRcFGYVDqf ACLk9ul/9+2w3Wx3++2iHBO09uIY7F/KEs0o5dHOP687oIpgCCFZPk6TOJXq7O/7jlGZ+buW TJJy2wvmtcLzLlhWEySKIGhEaT0AKTW9n9dZo6BpuqEmOYoR1caP4+3o6DzNpUr9zeWyskHv BN06VTBzUlzI9w6vbkuzJv5xkOfi6vB8nVdUewVSqAkMTdOMXF8/gFRd3i6zej6VTGezCs/x UtporW5vGzslJJRc2QFJd/IUAuN8oTvq21a5swyui0paHxz9ha1pjdX9bWGlzfH5su2XdTWf kZUi6Lu/gWwMD5edUzNNq2JpyaRqlirtxe2n19FyRsmqO4eft4lOhwTFsbvfLJZucN338kLS XvuHWb83Pf16nZlSyl4GF28+HvYaeirXeIBkujo9Bd7iZTyZ9CuqVh+Mx1Mg2HXTKLVH48nK Bx0uRyEQxuaf16cgCK4Xb1QEStN6m6O3mq/2l4OjcVy2tTj6p727HJQUMf8AMp+uzw7++bj3 1k4lp9mTjXfwg93AzBV7QN6n4DSvSWSYZMFoT1bbsKeYUhSLCEZnMv8xGjgvw6pCkbFszZmv 18uXlgay9wlUnmLT1eFis1nPh7WcKBc6k+UaNBRTFjLV4Xy9WY7raQYIAUYj8XShYjfqxawA /irQCJ81K2VT00BxsDiKM5Jq1e1aKZeI4sQXgOG0pJbBubIOiohO5Er1Rr2UFahILGlUbLui KyweTikYwaMsL4oJjgLjDAiKoDhB4FiGZaJgZIBOz8QTYiLOgK7/R8CzERzFSDqekBJxmkBR PBoTRFEA0+tzCqJg2ODox28XoMCAoQj68SLEYBUD4UFr/AJCkWJ/qzScrf/4IAbYA8RL/I4H NAoMAvbh/QO/gI/lx4uvW7+eC/3fQR7uX2mQF7kKZW5kc3RyZWFtCmVuZG9iago5MyAwIG9i agoxNTE0CmVuZG9iagoxMDEgMCBvYmoKPDwgL0xlbmd0aCAxMDIgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4AbVYTW8bNxC976+Y3iSgpvnNZW62kxQt6saJBPRQ96Ao q9iNbMVeu0b+fd+Quxb1ZSVOYyFgRHGHw5k3bx73ht7SDUnSkpTUloKv6bahP+maDk9aRdOW FLXTzRUzksLL9EeXvFZXWCvTZ/t63khJSd5FqrXB/2Oxlc5bqbRdVdrGU8nqAX7D4+zh9IqO x1TbPI9RuShkHWuqDY2v6PC1EjgQjWfVXzQ4WSw+XTbtiyHFSAM6Gb17PaS/afwbvRrj+DsD UDrxeEDhpIpe1v1BlZdkHDYLHMF0ohlpeiBLpyks2A+e8Gd0whHoz4KT1HWFkyQLOpYWRp1b h0dHZ7+/GN19mTd0eDZXdPzyJPlb/HCyuL5rru+q49Pup7Pmdtp8vrufzOn2knd0Ie1pECYf yEpkFSH69UpFernodnrVPb2ChGobEoojKK/Iuj4dJif/AGMQjqwvMlGNZ4RMnA9Oz4d0Opkj FTR4mNwOCU4MmiFpjcysZ6V3qjhtCkO1Owy0MwxAHTuIKGjlyXjfRUHL6ukoFCBd1sOuKFRF FJwXxrugqQYSS1DS4GzyEYce/7NEYH/WrQlYRyLXCg5TYBElp6Umh3AqXW9HYvUUEjkabIHR WFjYhcRnpUB1ZQMHtTLkEnQqIFGrPUjclwMtDXkduJxADEUOlBIqGLCCt2s5AByPgT9w3mCR 4dg2+N7xQpV5YWtWemdcV+Ub2eniLFPFV6sVz3GujRFaB0TBwj0HQuM5KYIxGnNSxIiIzMkY hZzUAiyr8XUEp5iHeqaUTMy1tiIGnMKZIBRQDVMoPYd/c/wICCoPXDiUpFaB57qNKmcDLIeI uYttZmYbbMW+G2uEN9aRCdjYsuvGeoHmoSqeglX2tbY4SbTsOm/KMDI2MmDJwmNjQNp4Ege0 Kh3VaRECQGGlFcChqXD8zi6WGGEdUMOebjEz6wg29Z1EeanU0TAsPAo2OvJKduBAZJkHDjDC W0IjWq1N4GKToIgLlt41N/dNezesls2jzH3iv8eahDPegWyiwS5XFBj02AyhQTLz7JxnKwNo 8sHK1bmFqF1tgxPByy0i3Bt33iFmbDzPJuMc7Efj/epdNf2s7lK7FE6czteeNP7BNy5pvaek 9zUXPh+HBuZWS9oAVcqik4Vl6lBkucOMuIa5BQ3+7XoLfwfEfnB30bnHYggKSXco0hwG853d ZSUMZXfxBjThFBgbrLoK4cHRN/SWr2OxNd2SAeiFiwEoDF7UxukqgRJ8i+aPKdBNJjFNBkUQ 8QcoMvg2SMyj0oNC4Iw0IDHp2ZSP+Mo1750SwTlDRmsRdeIXhCVtZEDwoYZ6ShW0bgZ1NwM0 +LOFG3wU2sJHKxNogbI93MBi8uy+axrTi0nbEJQk3B4sbq9odP/+6rJtLxfXj10kabVH/rfF hptkBKrWwYKibVhP5/ng4fLugrKOpYtm8qG5PR92OUZTeJKEUkMHG28I1J3s0otSdJTyqf+V Ntgr/iRR6qACTV8w9jt5g0WphiDf4A2/Kkm7y8H54AiSdC2rZQL5etDLgHUh+izGjB1VQKVF D72VKI4Z0/2ok0MZBK8B7kKIZsYcjO6n06Ztv4IvdqqeKl//+ntOVj1b+IKVg7EgbRed8JqV CnQEKruOmIKY8AENzCMertA82+gCVkSsQSeaxUIWPSwlFCxBNjjs44OuVI3uaJhBHvcBzoQ0 3IVZSGxaeUJJGC8kOEh/i5BYg1UXbOiI9vPium1KIXGzjFitJLaSkFhwPsO4ICYVhAW+15RL d8Fa3bCE8VfbZ0VhQ7XaUUB8YzAdi+XJJ4hmvrS1dDafTJufyl1WmKiXQhUXepKqkpzGrQWZ ryP6Bqp0ThHyN89CvWDWRe4arEiXqx/lEFC75RbNQeLl2vPFMxvn2GXjeTYbVyi+znjVr34G r227ZVbpsr2UQzU0gIOg7XSA31PcfXmhNyp+k5I6Vpk0DgdCs0Fr2+QQnl7Koer75NCzOA7V zUmHHKrBORaXjC4MYU8Y9qnChIptYfBa6LrGjbKUQx3JnX4DvW1okzIHUgvDF3rIXOG6Fm67 /o4xlY5e795v3pyNUCTlZV8K0706A5o3bvwjOvwFr94+tiyUlq8cIKNyO3aMlVnSFqtz5Vs7 WaHiCt8hAHoygWbk5BxgROft3k3o7oUZv6ZBqR/UNLjHkN7OVDygR/DwIQ+TPHzJw88Y8ABe 4PDwR57ErZofgA7PVtJwNUzG3q9MskTHyu5xk7+t2tR5Uq4MsSTQt/8BoD2vVAplbmRzdHJl YW0KZW5kb2JqCjEwMiAwIG9iagoxNzAwCmVuZG9iagoxMDAgMCBvYmoKPDwgL1R5cGUgL1Bh Z2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDEwMyAwIFIgL0NvbnRlbnRzIDEwMSAwIFIg L01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iagoxMDMgMCBvYmoKPDwgL1Byb2NT ZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2Ug PDwgL0NzMSA3IDAgUgovQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMSAxMiAwIFIg Pj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSCj4+IC9YT2JqZWN0IDw8IC9J bTIyIDExMCAwIFIgL0ltMjAgMTA2IDAgUiAvSW0yMSAxMDggMCBSIC9JbTE5IDEwNCAwIFIg L0ltMjMKMTEyIDAgUiAvSW0yNyAxMjAgMCBSIC9JbTI1IDExNiAwIFIgL0ltMjQgMTE0IDAg UiAvSW0yNiAxMTggMCBSID4+IC9Qcm9wZXJ0aWVzCjw8IC9QbDEgNDAgMCBSID4+ID4+CmVu ZG9iagoxMTAgMCBvYmoKPDwgL0xlbmd0aCAxMTEgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50 ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgMTIzIDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ43iEBhwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwMDTwAAb5AABCmVuZHN0cmVhbQplbmRvYmoKMTExIDAgb2Jq CjU1CmVuZG9iagoxMDYgMCBvYmoKPDwgL0xlbmd0aCAxMDcgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTkgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4IDAg UiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgMTI1IDAgUiAvQml0c1BlckNvbXBvbmVudCA4 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QMQEAAADCoPVPbQlPiEBhwIAB AwYMGDBgwIABAwYMGDBgwIABAwYM/AcGF4IAAQplbmRzdHJlYW0KZW5kb2JqCjEwNyAwIG9i ago1MAplbmRvYmoKMTA4IDAgb2JqCjw8IC9MZW5ndGggMTA5IDAgUiAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEwOCAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjgg MCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAxMjcgMCBSIC9CaXRzUGVyQ29tcG9uZW50 IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dCBAAAAAMOg+VNf4QCFUGHA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAwDswI3AAAQplbmRzdHJlYW0K ZW5kb2JqCjEwOSAwIG9iago2MwplbmRvYmoKMTA0IDAgb2JqCjw8IC9MZW5ndGggMTA1IDAg UiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE1NyAvSGVpZ2h0IDM0 IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAxMjkgMCBSIC9C aXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dAx AQAAAMKg9U/tbwaIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBn5gPo4AAQplbmRzdHJlYW0KZW5kb2JqCjEw NSAwIG9iago5MwplbmRvYmoKMTEyIDAgb2JqCjw8IC9MZW5ndGggMTEzIDAgUiAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3Bh Y2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDEzMSAwIFIgL0JpdHNQZXJDb21w b25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAFjYBgFoyEwGgKjITAa AqMhMBoCoyEwYCEAAAiLAAEKZW5kc3RyZWFtCmVuZG9iagoxMTMgMCBvYmoKMzIKZW5kb2Jq CjEyMCAwIG9iago8PCAvTGVuZ3RoIDEyMSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCAyNiAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBv bGF0ZSB0cnVlIC9TTWFzayAxMzMgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAv RmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITAaAqMhQGwIAAAIOgAB CmVuZHN0cmVhbQplbmRvYmoKMTIxIDAgb2JqCjMyCmVuZG9iagoxMTYgMCBvYmoKPDwgL0xl bmd0aCAxMTcgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOTcg L0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sg MTM1IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0 cmVhbQp4Ae3QMQEAAADCoPVPbQ0PiEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMPA4MH9QAAQplbmRzdHJlYW0KZW5kb2JqCjExNyAwIG9iago1OQplbmRvYmoKMTE0IDAg b2JqCjw8IC9MZW5ndGggMTE1IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDE2MCAvSGVpZ2h0IDM0IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0 cnVlIC9TTWFzayAxMzcgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVE ZWNvZGUKPj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9tCF+IQGHAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgy8AwM/ wAABCmVuZHN0cmVhbQplbmRvYmoKMTE1IDAgb2JqCjk1CmVuZG9iagoxMTggMCBvYmoKPDwg L0xlbmd0aCAxMTkgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg ODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01h c2sgMTM5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+ CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ43iEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wMDTwAAb5AABCmVuZHN0cmVhbQplbmRvYmoKMTE5IDAgb2JqCjU1CmVuZG9iagoxMzkgMCBv YmoKPDwgL0xlbmd0aCAxNDAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsg MCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVtmSolgQLfbdBVfAHXFfUVQsNxRRyg1Fy9q6H2Y6 YmL+/wfmYlV1T8fEvFW+QObNPCTck+dydwcMghFgMAx5ztcYhGAkw3EsTaBfBgujpD+azMoZ KczhyNc0C6F0JNsYjCcjrZLw4/BXvD2EUJGCbu2do/MwbQg08hWgMBaQh5vTab/b71e9DId+ CSgVb63dg6lrg9GonfoaUIRNDx132cpKSbmQjXqv/0Ewb8sg+HeDQBC6BSHv8snD9xBI/aAl wuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQBE6QNE0RBEl5nINgFCdJHEFQnGI5lsIR+D0E8iia wj1aImx25D4uazEGB4Yh7wTLZBJRH4kgGBuKhvlQPJGIhULRKM9iMIzRwWjYR5FsSExn0wLP YAhKBSKREB8REwJPo/AdTEva7skZl+Ic6AOGUTqcrWu6rlXTPIXR0Xy1rBQb3W4tL5eqSpxB UToqVxQxyEvF9kDvtxWBw4lAqlQpKBVVa8lhErmD8VDJcJ+cWTMdAg9BqGixv1jb9srQZJ4O ZHtz435orKyx2hxM9WKYJIL5/qSbT2RbE8u218tRTeTYeG08H+vj5dpoJ1gUglBGbJjuk7se FOMsTvDK0N7ZpmlvLS0djJQX7smeL6zlWG2N7HU/7eMk1bLvK8XOYruxTGvzMK3E+FR/6+5M w1wZapJDoTsY46T67HC9HmZ10edLdh9O24mmzbaOWROF+sPr88Owo6r1QkGznUU1HilM9xu9 1p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3mB8a5eGlgX57dRV2Kl4zL47pXrQ3s866XTTS3b9d5 NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23DcRfVRH58ed1psiQKEe426YA3dCjTXrgv7rSaV73W 9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV2X53X6lOL2+nWafZnR/cZSOtjN1HsxxmQBrmaZLH YZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts2o92I0J4vCZC5fnxYC13R6slV+bP38+m3tNna3tc Timj43GUYT36eOoJuE4QGIoxQnP95M574+O3p7WutlStryqi1FifrQqPecOFsKnB/ul6vToj RSrNn785s26r3e1rtbSQHx32gwT9KXEwxgR5P02QQWV2viz79/uXs9HMZ7M5OSOE4o31ySwH byoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+TkXDISke8P255EfYIiVDijZIVQMF42zq6hdq2La9TT oiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8L9nbP276iiSIyZQYDsv3+60m/gJlpLquq9Vifbi5 7PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ//HB7CYaKVM2TM1dL+UIZjFfsP6AJ1dzYy7m1P5/m VUmqzA6nzWI8mkz6JUmsLw9GMfAushDmz0/P12UlRGBcSrNPh9V0NJ6OWllB1jd2R/jZKUxF K5PN8XRyzweznfD7xbqxOzp7MC7DkhArjS095/tQbpiKNw2zmwS7TPDyYH08HnZb22ino2l1 YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1suZ6LREMJhvdqsh8nDGg1VStnuMJoI9USO5MrfXK nHSVaCBWUFu5IO5JsGcQgnPRdLHebFRyMR8QR4yNZsqNZr2cE/wUFZRSgp/47AAhA3FP3CBQ RgYlpdZs1gopwHkumkyEvfiHAYUl2UA4EuY56qbLKMkFPddHAaEkGI4hfp7bYAJohgSCeWuG 8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J8BQMJzwXSDqYNqDsP5OBD/5kbi6oQj1d99a9+9/y 3gvAkfOrFBxD//Z+Qno3v638X94/+3vn2QplbmRzdHJlYW0KZW5kb2JqCjE0MCAwIG9iagox NDA4CmVuZG9iagoxMjkgMCBvYmoKPDwgL0xlbmd0aCAxMzAgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTU3IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKL0Rl dmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29t cG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvZhnk+LGFoYH5QAI iSCSQGQQOSMYMgOInMXM7M7OeLxe79q+vv//022Rht111a0tl00V0OF096PT3W+f1s3N4aOD zh/dsQD86v6q8M1ad2WpNb7KXxq/mVx6/fEEhGA4jmE4SWAwdGqug1Atj2o1l8JDHQRjBImj 0HnoYx655IGRDvRI4Ch8NvlxpEsLCCEZltEbzXaepZAjnQ7GjVa7laENLMeQyNUoOphgQI0R Pw0NIRTL8xyNnh8L9At6NFnMBuyq6DLajyV0CGURPA6LI5ROh3j6CALhJk88IwkWq9sncOSV DyDUKEiZuMeEH4bWITQPGgYtJPw2LISz3mjIrr9+qLfaH0gBT5h98ajXGSgPx02JpzQQCGPE Yn/cirscwVRS5I4gh14hwhpvTfpFkdEco4Mpm9QcD0oe/RUcTDlTtXKIxa48/gNIb6YQZhLT hbjHGes9vqitqIWAwXozCIXJ0/O84LEH8nLaY3ybNIh0FhbPT5OCYADrDiYs0Zb68tAJMchb n7BelIfdpBX/m3BgWpxJuRyx2+PK638+bWoBFocR2pEafvj9y67isQiZRi1hf5s0iHLL6pff PwzTDhqBcTZQ23z646dh1HQNZ/DXZ8OM7e/CQbg5Um0WvKxFGv/85x/P05KXIShbrK3++t/f VFlgrNHbrhw0XVynwe1/+++v+45kowjGW5w+//HnqxJjEaA9MAwDVbmBjYHmYpQDj6TltN2r ic05AdLADj4WnAXrYAnk61KjWSN6T6HbTvF6TlJevnx6UQdZgbOFbxfvP375tK249UZvedDL OC6u0+B2nz5/fFrWwzZOyA7Ul18/vwxjLIbglN6gpzAEQg5weaeBJDQ9AWKDa8JyUBggMRhB Gwy0VnUqASpGkaAdjBK0Xg9qDuBg5ZtjrVEzwpKsNHz/8qiqq142HKtOtur9h+d1xU1T9kx/ fBtgzjtPg1s/P93vd5OqFM52V6r6+PJuEONIvdkl+kWXmUZRDW5cFHmbBUjOSVi0BMXarCzD 8h6f38MzxKHKajVzVqfbwdE4ydgEUXTbjGDdA8/BlLs4mlRFPQ7gHvaT/mS9HDQ7k/VCUdaP y4qbwrlYZ95PWc8bFsBVVo8rRVlupp3mYLme9Kf7+75kZZ3RfLVeK0QcBuIAV46EYhGBwRDC 4pOibiOKkFa/FPV5gqnybb2SEjkCAYoVlcIhKVfMBHjO5ksWZbkY9x7FCzEGm4tJwUlirDTY r1rF2mi3V9X9olOujtVFxU2iYHEvpmWBPkmFBrdUR3Kpu9yru/12VCu21/t+3OGM1QbT+WLS TNgNJs1zciJTvU05aZzxlXutlIPCTYFSQ06nSp3RbDHvl/wmnLIn6p26XL8bdvIhn1TpDhVl 0C4GNPHSYebEYDPKWHEUwKnzSiRWnb9/fVF7mXCmv9PgEEqQF+tWwHjajRrcYneXDmfu1JfX 97NqLCov1H7CJebaw9FktVvUQ2ZOg6vEcx2lETEb7JnRw7YVYg3O7N2oXSzU75TxfLsdZp20 XihN1tNeuzfolFOZujJVej0FqKjXgOogwp6fqsM4hx7gZkWPM9JcPz2Mcl6X1NtqcDDhKM7V gcSiYBWAzwFu2405vbnRw9O6EXF6S3MA5/YmSuWifLdRlbTDAuZjVIokWrNhXrAF6vtfXmdZ ty1Un03q6VShXCw1puq67meM3trm3apdzOVz6Wx9spo0isXWZNFLgGV0mKN9H+jAES7vNPFS cwT0n7NEukc43JabPUzSlpPcH+E6YTMHzpAROFJMLgAPppX3BHy+iDzbz4uCTYMr+ALl8awp BdLDp8+/qI1oIDdY3GX9Xr9fDKS6W7UX4Rixvn2cFgMupxDI9ne7YSmeqCibaclNwTDtvV2r vTBzhrNTensknfCyFHuGwyzp6eM8d1bUM5yJYr2JdNiupx0FACdZGc5md4cq0/tlxcuHNJ0T nPHuQqkWGot3L8/3SqXQmk1rQStnsTm8ye7ufiCZGfF2vevFLDRpdGXH7+5HciZTVdYz2auH wTnT2KqdkPEMxxMobeZtDI6ZwkfPQag5NXlcFOzE8Sw6wYUYDGdsvJnGSLsGFzPrGd4bybSW j2tZPMI5zaI8XY76k81mudoulcFsNUg7DAazyx8vD/cPw7jFJN4ul7eiHoFJPjd7epw0yuXb u9FdHmxAWO9rbHad4BscOLtAHIfCCPN/4IwIkEwSR2DiACdZTY5wpih3Fg+rE1zWbuRTg939 /f1WabSnKkgs60FWb/bG8+X6SL0/wNXmMyBYkA7nc/P3+6Gcy+SK5VzISh6ndaed2qc1x+PQ 8ay5wMHHac2DmqsNoTn7aAj2lOY5TUrkRrVUU7YL2XfwXJanmUB9+9PH52UtkenuXz8+TfNO Iyvm6vVyub3cDTTP1eaTkouEdJg1PX7YtNNBn88fEB0g5gFzJC93vcgV3HHybq7gbNnZwzTz zYYAcAfWmxNc0hOWhwM5le2sl7WAMwzWXJYnSUdu/vrlWUl5fOXVx8/vuhHOYE91lFYuKU+3 SpJnfbXZpOgEcCgb623X7aTX6XAJAm8EcEBKZrs+0ImL576D0zyz19TmBKPp3Fbz3NdwvkR3 Nakms93Npi15Yy0NjgArt/fu533Db7bFhx9eNxXBYBDK02U3l6zO9tOCYA3cHuFuEL23Ml2P qolQKCpFvRw4wTBLcrgZJi0YaorebcbZ854Engu1V1PgcHDAVRab9hsM5SpNV02wTM9wfG6y 6SbERHez6JTk4f5+mAsnmtMBCJlgYDxTRxk7bfRWl7t+3ELQ7tJ0o9RKrdXj+jbkClbHSt5B QmAGrLHWfDXu1m8bjXLUBiINwNBajnN2AjUG66Nu4jx5N7DBJyu9tJ1AtONrLnsuxxdpz9wp FfEc+UK4Ndkd3YbBMJP5sNkcrrdKKSbJd03JgkEYF6l1KwEGA/Fzo1PwGFCCT/Xmk26jO98t W5LgP8REBDistMCyPV0uZpNxvxq1Al6YFsrjccVDo7QrVc75GPQ0rTDliJfyQQ7D2GhnPkjb Lgc/zgXzJekSfupQkz9XTrrN9qjcasqlartXT/v98UJaBJ3BtCOSDAE3IAZ3LOE34zDKeLON 9m250uh2SiGHK5LL+A/xPAi/XXG5Oxj0O3LCDdbcDXjuRHdUD5kw3OQSBfNb2IYZHaLHSqOE LXU3qQcv1OAJrR7RoTU+fHQwaRFEp4ky2HzRWNgfCMfCHpvF4XGB0AKEZAarw6JHIQioop2j EHCtM7lCsWjQH4xG/XaTiRfcFlAM+oJQvU2MpdLJmN/BaJc7HWL0VfrtpA1EL7RRT5xuhtrN BaMNehJF9ELxrptxXqhBH6TBQGGHiEvDgxBCb6RxBCWNnJllGJZjjRQJGmudgW7IQ/CoJahT CW0ycybGxHEMjYMAFYxyUimEMLAWq4Uzksc7L0TwicNiQGAYQY6x89EjkJaHMS5U7VSC7CVM BzH3XxlqsTeCYiiCoCgK2sHgq8Wzh8D72wSwOxqC4Py6MxAYg1s86OQY1Guu8+YalYjlvKYO ZOcfbc0ka9U4/+a4c9Vf/eu0lxKHn6vaS/6SOJm85b+2Pq16rRDccEKFcsJ5uk1f2WmVqEnM llPC1dXwa4N/OAcu/Hw4Lf31+BDO+ZOJry7V/zDON92DTcL7fA5wRf6mAmTBewXwOgLs4StX f2/1T5ZAKM2aTV+9rTkPd6j6+kXOuepf+gd7BCfwr95hnUfWgbDo6r3Yufjf/Aexz+lq/t2o x7Dou+J/peB/JSfxSwplbmRzdHJlYW0KZW5kb2JqCjEzMCAwIG9iagoyODM1CmVuZG9iagox MjcgMCBvYmoKPDwgL0xlbmd0aCAxMjggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMTA4IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0Rl Y29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0Zp bHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBtVZZe6rIFo3KKCCKaATEGXEeUJw14ggq KE6JMTknfU+f/m7f//8DbmFO0t334b5lP+3atWsvitqrVt25XG6PY26323X3teZyQ6iXIEmC wFHY87VobpgI8rFEIi7yIRqHv3RvHpzNKL3BoNdpVjIRCvlKMA8ZU43D0d5aG31YjlKw++vO DKIz2uP3571l7U/2rMJ5PV+I5ZcX19ed1u1Nd0+HB8kPf11/QIHc4nKelBLJkna4rKohFDT/ h7kcXNdtBLxP5937nAOsudHm11G/c8gZOBM3A4RysgHW/NHuxP200DAvViOCeWAUQxEU83ox GCR5EAz3OnxwA3ZgIOS6AzHUIQjgC4JhCAQhOElRhDPncnlgzKEQBgMUZxqUAusRCKDdsHbt KEVy9dV5o9zjCBkMs0wwEhXCPgxGSeZeiPIhvxdBiECY9aEeN4T72SDlON5AiKW9hD8STyWj oVsIo8NiIhEFayGQFwoFmRAf5Rgv5HawFk+HoRThpJ51mBWCmDecKeYludJsFKIBHyvmas1W o5Lh/VQwnpdFGoEwNlnIRX0whIdS+azA3qeqnX6vmRd8KOxlk2W121WLccaLB2K5QlYqKGot zWKeG9b1uu7WlOHmtO2nfJgv2Zpo/Z62XPTyYlRWxwvD0OfDWjISLfYGFZ5A6WR7NgYti/rT raGajWXbS9NczTpymCDCcnuqG8ZSU9MszZWHk2F3ONe1epSEXGBfy2+/X7cr8/TybLZiFBbI Tw97YzJdLIbVXGWgm2tdX1nmXM2maxNjJAepSG31fBpLAYqvz41+Xmrop6O50LoFjmalnmEa s5mxWajJSKK9OZgzbbbUFJG6Yelv//7xfH56fXvZ9qUgyZZW18uq11AatXJ9tLaWg6bSmZi7 hZqvapbeEMPp4dMfP6x6NCwNrVVbkrrby37arhUTIUZsrvabkaqON7tZNZEdHl/2mgoqSfeA uM6+vv98tdfr7eF8WKoJNlLZvDxOijFeiMttY6e3JIGLl8fb7bha6q2th0K6qn/784/HUS6t LHezsphQrYs9rmaiIZrNaqez3iqWOsbR7Mj5h9PVVNMCz4XA7XfDenkxB/Wq0ptv90slHq2u n3dt0YeTrDTYbocS48Uovrbc681cfbYzes3R7uW3t4vRaY4ts5cK3hdnh6PeyQkBKlw2wD/p 1mo942ANCsWHw3mWZwkcv3HF6cPL8UHmQveJ2vx01ArJunE2KoDTsF8a2+smj3tu7m7TluSe aa8Wm+PRBjeasbT2y2qE8ImNpW3rvXyE4RXr23UzarcH89VclQsj2x4kSMghNCAzwJo/An6R KOZP9g/PKyWr6MdFgYHvIDqr2av6PQp2T6WGO7OdjFWX58vlcjJGmvkIHHuYoRE0kFSm1n4z zAux5vb1Se8qNUVtK3IiN9xanaj34zq/YW1bAgEjVLx3fDGbsqLvZ/kAdOfxpR9ssyWSMIQy OQ1sMRrODE//+vlm90u16dOPn9/MBu+FEDKUqD5YJ6svpxvr56NWzSSTqXRC4MAZbFoC/jcs wOVBJuRn+ML08bqqSwBrmnOwiFjHtLUiR1NMQl3tF+UwzSnbH/95MyqxZHv/88+XqRwA9A2E hXR9fnpc1jKV2emgleM8J4giF5EG1kbl/4F1fTZaBTlff9iBk8sna7+w3Fi4PLPNUUVK5dS5 bQ3SNB7Izl5+fxqlguGi/v3HsSMSMMbEJLmgTE/PayUpdc3DqleSpFwhlxTl4T+x/PL8+va4 nmlTfXc6zKuiUJ5vNdkP3bkgX7yl78z5aKAZ2+2kHMFhr9CyHlc10BDxnn1eFFkEIrhiZzAY b87neYnnC+Ptfj0dDkajdiEp99dGg/trX77U6Ph6Pe13u912Pa6KDCsPF92UD7q7c2NMpr2w LMu0rLVWdUQbYeT+tJOmESxUHE2aMQryeLnyaLk27f2qnQjQfFkz7Z21WYMbLpZuTrXKPfZx Xh6Cr4yN9UpfzrRBU+Z9uE+sNIs8AfTZ5cGDyVof3Fbzcbsg+MBjxENwclkK4x6IiuZLqSBQ OzSYboxmi4WmZoI4SgnF7nS5XEy6pViIk5VaKoA42uWYG6WFbKlSKZcK2STPEDCEBYQYR4NG d8Awmkvly5VSNhYinXePG6FCHEsCcULpcAQohcsFedmYXK6WZZHBIQ9MhhP5SrWcT3F+whcW oyzIuSE55VDSz7BsMMj4KRxxxBElKAJ9fyoC5cN9DBsK+knUUTuQjuCODgJNRHAvBkTpzg1h ZIANswESKBqQT4wKsCGW8QF9RLwkCd6Bv6DAarcHfjfoXapBAHi/vgWoOAQjCAJk+T1yU/gb qqP7tyCoDyPoR8rHCFwWTqW/Sn0i/j8HCPvHX3DSPkefzi32t5z/WfBZ+793ykPgCmVuZHN0 cmVhbQplbmRvYmoKMTI4IDAgb2JqCjE4MDIKZW5kb2JqCjEyMyAwIG9iago8PCAvTGVuZ3Ro IDEyNCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVp Z2h0IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJw b2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4Aa1W2ZKiWBAt9t0FV8AdcV9RVCw3FFHKDUXL2rofZjpiYv7/B+ZiVXVPx8S8 Vb5A5s08JNyT53J3BwyCEWAwDHnO1xiEYCTDcSxNoF8GC6OkP5rMyhkpzOHI1zQLoXQk2xiM JyOtkvDj8Fe8PYRQkYJu7Z2j8zBtCDTyFaAwFpCHm9Npv9vvV70Mh34JKBVvrd2DqWuD0aid +hpQhE0PHXfZykpJuZCNeq//QTBvyyD4d4NAELoFIe/yycP3EEj9oCXC5SauOyuEWdbPBxkc vhGMZRkSg0EuRpAETpA0TREESXmcg2AUJ0kcQVCcYjmWwhH4PQTyKJrCPVoibHbkPi5rMQYH hiHvBMtkElEfiSAYG4qG+VA8kYiFQtEoz2IwjNHBaNhHkWxITGfTAs9gCEoFIpEQHxETAk+j 8B1MS9ruyRmX4hzoA4ZROpyta7quVdM8hdHRfLWsFBvdbi0vl6pKnEFROipXFDHIS8X2QO+3 FYHDiUCqVCkoFVVryWESuYPxUMlwn5xZMx0CD0GoaLG/WNv2ytBkng5ke3PjfmisrLHaHEz1 Ypgkgvn+pJtPZFsTy7bXy1FN5Nh4bTwf6+Pl2mgnWBSCUEZsmO6Tux4U4yxO8MrQ3tmmaW8t LR2MlBfuyZ4vrOVYbY3sdT/t4yTVsu8rxc5iu7FMa/MwrcT4VH/r7kzDXBlqkkOhOxjjpPrs cL0eZnXR50t2H07biabNto5ZE4X6w+vzw7CjqvVCQbOdRTUeKUz3G73WnjvH5aCjW85Wz8Vz o/PbydDUTkuJ3eYHxrl4aWBfnt1FXYqXjMvjuletDezzrpdNNLdv13k1JYrxiFCeOZt+PtdZ O0u1poONmDYrbcNxF9VEfnx53WmyJAoR7jbpgDd0KNNeuC/utJpXvdb0Vmtou3s9n2puXpx+ 0kdRFMkltY1jdtXZfndfqU4vb6dZp9mdH9xlI62M3UezHGZAGuZpksdhlPCJVeP8vNObuvP9 dTvp90fLh2Unm2zaj3YjQni8JkLl+fFgLXdHqyVX5s/fz6be02dre1xOKaPjcZRhPfp46gm4 ThAYijFCc/3kznvj47enta62VK2vKqLUWJ+tCo95w4WwqcH+6Xq9OiNFKs2fvzmzbqvd7Wu1 tJAfHfaDBP0pcTDGBHk/TZBBZXa+LPv3+5ez0cxnszk5I4TijfXJLAdvKgMTkdrq5c8fb5u2 FJEnl+dNv5TL5ORcMhKR7w/bnkR9giJUOKNkhVAwXjbOrqF2rYtr1NOiICWTMT7eWJ0WpXdQ COWyo+tff7/OC7wv2ds/bvqKJIjJlBgOy/f7rSb+AmWkuq6r1WJ9uLns9FJ5uHMfhjVFKVVK 6Zj4L9A7mIy1dn/8cHsJhopUzZMzV0v5QhmMV+w/oAnV3NjLubU/n+ZVSarMDqfNYjyaTPol SawvD0Yx8C6yEObPT8/XZSVEYFxKs0+H1XQ0no5aWUHWN3ZH+NkpTEUrk83xdHLPB7Od8PvF urE7OnswLsOSECuNLT3n+1BumIo3DbObBLtM8PJgfTwedlvbaKejaXVhNGLk5zf1Bqo6mK9s e3lfT/oJArj6YrWy5notEQwmG92qyHycMaDVVK2e4wmgj1RI7kyt9cqcdJVoIFZQW7kg7kmw ZxCCc9F0sd5sVHIxHxBHjI1myo1mvZwT/BQVlFKCn/jsACEDcU/cIFBGBiWl1mzWCinAeS6a TIS9+IcBhSXZQDgS5jnqpssoyQU910cBoSQYjiF+nttgAmiGBIJ5a4bxh4CKBlgCRYBes6D6 E9NbhxHME+iPXwnwFAwnPBdIOpg2oOw/k4EP/mRuLqhCPV331r373/LeC8CR86sUHEP/9n5C eje/rfxf3j/7e+fZCmVuZHN0cmVhbQplbmRvYmoKMTI0IDAgb2JqCjE0MDgKZW5kb2JqCjEz NSAwIG9iago8PCAvTGVuZ3RoIDEzNiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCA5NyAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNv ZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0 ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1WaZeiyBItdpRFBFncWURxw63c0LLdFXED tcrqPu/9/58xydR0WTOnP1Z8IS6ZGfckETeCpydgEAwjwGAICtG3GwSjeIRmGIrEAMe3h3+C EJziU6qu5xQugn4/AwTjsbTVGU1ehk1DjKLffgUYY7PNqXf2z4dVz4jj8Hd/IySi2Ivz5Xw4 HL0fVZn8bgIIjRkv58tu0us5474lRb6dABeq69tpVMqk1UIhwxEIDAwkApQueIYZgT5q+CP9 fwJ/p+2z1P9zAiLEhve272TYKMPF2QiGESSBIRCEhA4oKuCQUYaho38EFE2D6gbcYNtnqcMo EZ6I4GHVQ3jC3t3PQ40jMRzHMJyKiwKNwzBOC2I8isIoyUoZzdDSAoUh/wExKauqGYklw22c kte1jMgQKE4nMqqeT4bHnyCMK81vb9t2no8CnSGkoJULchRBonLBUgUSjya0em/84rRNiSL+ BSiw0h0Ou9U8H8EjCb0xGDnP5XQsGkuVu86o39ATEQR6QqhM17vftv2SwhIISmVb454eQ9GY 3hs3MwwllQarPaiwxbMaZ74CVir1F1vX3cy6hkDzen9zOOyWA0uOp+pT77jf/GjlWAx6gol4 Ybh/fT1OG/k4ibPGeDev8BjGV+buyBBEc+T5p91mDcJIcvELkEzHPbjLpbtfd1Ux3dzerof1 bFhJy+aL/+a7y0lb5QABhESEQn97vV+3PUOguOLsvKkncDxR35ymJSXf3V0O0+dGwy5lZfUB MiEI9pNud7o/L+2cPji9B4t+s6rKSmV1v3vjjl1MMYAgZODV5ux0f9sPdCFRmgdbOySwXX9W zpWn/nlSSUuSLAqyNfsEvGTNbq/bXrU2cK+HgVnoHd/9aaOQEWMJa/H65vbLqsKRIAchA8Em LccDtJ2sYn0lqOqtbbBpKhRBkCQtNx6Akmz31/tu2Gw67uXomPn68nLdDqw0R8Xyg+PradrQ RBoDsg0FhWBRQe/t329TK1uZ+583mNfMrufPiuBTAoFFlPYDkHLr+P9f+0m/P17tVs+qrHY2 vr91ygpDidbkEBxnLTUObhAOAwLHUDJujIN3t6lX577bEHFcbLj+vFbsef7UZFFwUZhUOp8A IuT26X/37bDdbHf77aIcE7T24hjsX8oSzSjl0c4/rzugimAIIVk+TpM4lers7/uOUZn5u5ZM knLbC+a1wvMuWFYTJIogaERpPQApNb2f11mjoGm6oSY5ihHVxo/j7ejoPM2lSv3N5bKyQe8E 3TpVMHNSXMj3Dq9uS7Mm/nGQ5+Lq8HydV1R7BVKoCQxN04xcXz+AVF3eLrN6PpVMZ7MKz/FS 2mitbm8bOyUklFzZAUl38hQC43yhO+rbVrmzDK6LSlofHP2FrWmN1f1tYaXN8fmy7Zd1NZ+R lSLou7+BbAwPl51TM02rYmnJpGqWKu3F7afX0XJGyao7h5+3iU6HBMWxu98slm5w3ffyQtJe +4dZvzc9/XqdmVLKXgYXbz4e9hp6Ktd4gGS6Oj0F3uJlPJn0K6pWH4zHUyDYddMotUfjycoH HS5HIRDG5p/XpyAIrhdvVARK03qbo7ear/aXg6NxXLa1OPqnvbsclBQx/wAyn67PDv75uPfW TiWn2ZONd/CD3cDMFXtA3qfgNK9JZJhkwWhPVtuwp5hSFIsIRmcy/zEaOC/DqkKRsWzNma/X y5eWBrL3CVSeYtPV4WKzWc+HtZwoFzqT5Ro0FFMWMtXhfL1ZjutpBggBRiPxdKFiN+rFrAD+ KtAInzUrZVPTQHGwOIozkmrV7Vopl4jixBeA4bSklsG5sg6KiE7kSvVGvZQVqEgsaVRsu6Ir LB5OKRjBoywvigmOAuMMCIqgOEHgWIZlomBkgE7PxBNiIs6Arv9HwLMRHMVIOp6QEnGaQFE8 GhNEUQDT63MKomDY4OjHbxegwIChCPrxIsRgFQPhQWv8AkKRYn+rNJyt//ggBtgDxEv8jgc0 CgwC9uH9A7+Aj+XHi69bv54L/d9BHu5faZAXuQplbmRzdHJlYW0KZW5kb2JqCjEzNiAwIG9i agoxNTE0CmVuZG9iagoxMjUgMCBvYmoKPDwgL0xlbmd0aCAxMjYgMCBSIC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTkgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQov RGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJD b21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVVfmTolYQHrlE xQtkxhtwUPEWL9QRFG9QDnXwmJ2ZZJNUpfL//wN5aO1uUtnUzvYP8IrX3+vu93V/3HkgCL4a BHk8dz9jHgjFAwSwgB9HYehnwBBK0GmW4zgmHScJL/wTWNj3IHRHijwaSqKQIX3Ix7FIiBsa zvPOMg192uUp/ONx0Whp+enXi73d2s+HTT8XwaCPXhVKVvX3N0Pp9RTdOemthA/+OLS2eXUU IZ3O9zbnZyUXRK5kfblrwN2NPJe6G5GAxevpKFnbXKxOMuin8pPjeSGQOB4IBgOAKeDggRCv z3+lzotAEIL5iCDhw24kAqh+MVtxnzfMyc7LuhqnHrJcLvsQxmHgi4diiQzDstl41I95CSrJ cEyCDKDuhbhRX3YSQ0YSlfnpvKxzfE0ayf06S+IIGqDZSrv/NHrqVbMkEUkVxf5AEvOJoIt1 oW/nebNQaCjWeafUKh1VN21r2ctF8cCD0J9pxt456MNigmaaylLT1otRNUkA/gF0+/k3ZzVR V5azn7VK9aeFtrEcZy2mwrHCk2YalvP6upOFNCvOtpvlfLnRx2Uah1yo8cdfn4+2vdsbaiPH CK1et6cYp4PM32daa0sbyyvnxerzTEW1d4t+e7C0twM2iFyhv//5vtfXS1UqpSgqxeXYx/rM Oc3LqcehYSi1Uk971ttcrmuc7XGjLKr2YVaKoh434V/eTbldr+QzMQL3h2P3CaY2O15W1TQ/ NDbD4qO42K2aXEF2XveTdqMztQ6LagyD3GsCLVFMxshwwIsgGEGlchVpfQY8pdjO2lA7zSfd nlUZQb28P88HvcFkrclF6gZ1WyKAoQggEsZJptKWZP10ARQnyqplakvd2gz4VHF6ebMnnabY kbrVTOiasH4xmjR2bS4IC7MtWZYkdXdcVWiSG5in497URqU4zSvOZSMJOTb3mMtQfsSt9Qa9 tiWEP9Sn2qRVGxiOVruPZrrb09GY9oR4MJTpmceNlE8lkpls0h3sf0PhQEYydrNWbWiejU6G ZiXDsdRWPh7y+ujqfG9PWwJfKJXzcdATKFlZO3o9hl6jwv50z3jWnnqT/aeDXMwWlf3ZGjcf ExGfN5TtantrNR7J41GTcWuNFMbbaYm8Qd2E59Z2psys405tCOLy/H7U5HaZiRF+6rG/3u0s Y6upYjaIeBAi0xyITAi51YqGGVFRR1JfmU2HojgyXt5Ou81K7RXuiUDssT1erldzpZOngSJA 3miay5D4TRs8sDeSypcEPscL5XK9v7L35nqx2prakI/ivmgqX200qoVszB074EyECPyLEHpg LBChyEg4QtKpsmJai36j3lHNw7oZ9yFYIEzRNBUhwNzfhAABzXDNFzw8EIxiKIogKE4WJ7Yh V1imKOmO0U35YQhGMGDA/SYxX0Bf357rD8SDhHIjwxg38nx1qB9cwXPPB5v/A/uKv7uD/cnm fLMErTVabLdjgfJ+Te0fXt9dQliEa4/nwJarhVy7CsN3Hf/70QNGIVu+KlNfLCSCH9d2UBbs DdJpjs/zbNIVwR/X+C2+q8KBUDgSDvqxKxvftn68AlQhwMAgfyfk3xd71dwKZW5kc3RyZWFt CmVuZG9iagoxMjYgMCBvYmoKMTE5MAplbmRvYmoKMTMzIDAgb2JqCjw8IC9MZW5ndGggMTM0 IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI2IC9IZWlnaHQg MjcgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0 ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBjdLbU9pAFAdgs5t7IBckJIhcnGKQ6AhIuRTrgJoCCbEgEZbKoGRshw7Vtv//U7cY tDp9cN/OfnPOwzm/DQL8fcTG+hGrD1wTgGQ4loYgEAJQQQ0oYVPXFJ58JAIyoqqrIgsJyKnZ QmFXE8jVQMDIqf2iuS1SgAyna91e09R4iAnQUqbS7rVMlQGkZFhTH7X2ongAoMLJ9+7NvF+O c4CS8/bdz8XV8TuFgaQQP+ze3i/H9QQWxXS+/nqYX1TTEsvH8qfo++8fqL69EttfLnzUKSUj MePjYPZtuRgF0p35U4SGVsnIN9wR+nI799ZyPXHbrnfZaZ653sC2vellIJ3JsFU5dsYThCaD s1qjhwZrQf16Lt/oz+58ZBWNYnv8LJ8rqa1c07u5do7SCdMa/SPlLVkzm067kolEc+cvROdD eq5wkFZ45ZVoLN65FpMYWjZe9mh4NfguFMR7fC3g8Zb/keDebxJ579NVrxRjnnp2T4cXVXwF UsyeOOcHUToQGN75YFsFnQVQSBzWjnYkai18fL9azkZogCORyCQ3ORikCtBiPJNScWBwjAQx xAahwvmDtBAOcRQOGQEgScLnkD7VfwDKclpzCmVuZHN0cmVhbQplbmRvYmoKMTM0IDAgb2Jq CjQ1NQplbmRvYmoKMTM3IDAgb2JqCjw8IC9MZW5ndGggMTM4IDAgUiAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2MCAvSGVpZ2h0IDM0IC9Db2xvclNwYWNlCi9E ZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNv bXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1YZ5viOBJubIxt wBhjskk2Tc6YZHLGZJvQdPfMzszu7N3sc8/9/89Xgqabntt092H0ASRVSXpVpXpV8t3duRgw KIab6m39onL9BVX8XK4DroI//b8scJn1TxV/V2jACZIkcDQcqhRNGs9gz90mHLsZY8CMJtpi hWIBrfOIG+kfVtFMlOky6x8q/aHAgJMMZ7cQAASqNpeHP9fvMMJsd7C08WbbBpy2e0OiKEZC fhdLEy9G/8OpLwK0AO+0v5vpL4bcijET6wsHHBSYAyNswXQh7rUgUBhpD4hBB31jJsxkD+eV TqfdUiq5qIcx3Rr3ds53dYPR6oslQhz5t7TfDYUGRjD+RCbqpPG7O9zsLYzmnQSPpsJIPprP RRw302KUJz/eHffaZrOatbMCg4z+lwUzOeL1Vs5nhhX+52LAzZ6kXIoiGAbCft8/fdIbQQsy pomTZKUQsr2BwM2Buv7pp+NmtdkdtWHOizb1lwUj3fmxWg9Z/47y97NhpOO+0iwGGXApRnlL m1//9XmacoDnwC2BYreVvQGBW0Ktw6eHqVJVxtrjrntvJ25O5/dTX9swbXm+aYvM/4EPQARL vVbaTSFANrFz+u3fv+pVAfkCI53J9kgBEFcv4pZw6/C0kCUhnBvsnxYFN4UD0RjuDC8Mgojq UlDnhYswwCcvtx3JRuA4UoY4PEteKOqqdtmp4cxfr4EHGFLdiSKxYAiMdOVmz798/fk0iCPD GIxMuD4bF32vXkT4dsdhgrcwgrx+1upBhj4TB/AOBRSFeIQ0kZTZTBE44iIrw1gok9knL7Ve 3MlYLdAPezGSZitjNZ8pB8jnooYkiN+Av0DtBSF4rKZOZcEM5sOtocbmdNydHpdlH40ihPIW p8t2lL1yzAXfIGYnaU9h+bxrim6XC4gDM9J2F89QpJV3Ox28NyC4bRRpcfjCkhTy2Fm/vNyN C1IoFHCzlBE3WXkhIkUERGSYkbJ7w5IYcDEkbIli3cFIJADDz7RhILjkYDPJuUgUD47UaK+N e+pB70aRQQ2EIzXcTvOuawgjfPvTJOO182J9+7xtxMR4EogDJ7lwMuazMZ77TCqWyFfkdJDn hUS52WnXsyFPqLJ+WHerlVo1J/I0xfiTcrPTqiR8DGGknVKh0WpWUoKNJMxOMVdVlGomfOE1 FBELfZiwg4Vws1BZ7adyVlkfVThZYECckTraug7hfDnrgK99/LhtZeLp2uz4MCvFsg1EHEaz P9+qx1y8VBsOWs3BbNrKiPel/ny9WavtTEisbj+elqPhVB3XojzrTbVm66226mW9Fsou1Wfr 9WLcSLgtFneiPlLn89mgeiaUO3BvU9t1JQgtIJdYf693E5Hc5Ki3IueANgcVbd+P2oxv+E6/ fNyM+qPl/rhsxKXymTgIa7ihjnI+DzhgNx+OptNOOV+baPpKnY7buYhU0z9/WA86o5U+l8Pu cHmgLla7B60T4xhvUT0e1tOBkvaxzlhzvp6Px/PVtBpmwINGW2x43DVDYCBkytWT3o5HMsOH JzXrBKdilK+6Pc3SHPGKr/P07R8f9pq+09RGzBeunInDBHbezEuCL7f48LRoymW5VKxNdH2m lPL5jCREatpPx1EpXRrqu35SCGdr9aoyOZzmBS8XqG2fdqN6MRNxOYKVxW7VrVb7K22cRafK yKVmj3pdoDEIVql7+vlxXCnU5x9/PiDMBmDW8uZ5VXCaLsGP/Pv4z6+Pm/ls1C6KTruAiENk AF93uygHfPnVx9MwE/ILkXRrs1dl0evyeHg+WN08LuWwJyQv4egEfKGoKCaUzeO2GuCEyuZJ 7xfuAy7WGR8cH9RaJtuYH9a1AHAc4cgtnrWql8IQuSy/fPuyUyeL49ffPs0QRxtMzsL6w7bs hvBBBeF7+HKaNoq5pORjaQsQx3t8S0Q6NtrqjPf0bVuyUyRJUVY/HOxRkjfzqfF+URY4h9sb iDXWT3BT2V2Z8f6gNpICx7hzczC/Uiw25/uNEob7huDzqw+a7CExOInK4ddvXx73+v7pl29f 9Rri6Iu84qVe8Z35WfQ4OYYmjBfivbXf/GGOwp2wxwe7VQVYCrEvjfivG7WZbPc9fSn7Wbsn nCj29Q97JWSzBeWZrqvNlNfhL28+fVh16/X2ZDGRUVSe19/KbhLIJTl++vykLWaz2VJ//nzh 6N/Bd+Zn2gT8iy6GMiwsgX+jXQ35N6cepmkHcWdkAd+yDPsGq4Paq5k72lIOOH3xYlUZas87 JWSlObE82uxWnZQQqmx/elSVcrFcrZdjLrgWwL/L563sJXGzv7I+6cNKPpvN5muj3QlxNH7x L7Lv1b+t3eE1njHSU17o/RhLsbGBvjzj241TnBHiDiy1aQStcKfgRmS/yzEQO9tlVQyllW6z 1pofNSXEUFZXpNDbHDetRFRePh8GhXtRlKIRHws5gJFLzx61qo822WO93a6fFpw8z7sC2eFO 7wBHk+7S5nldvIkPwNeL2i58aDC5CvP9JOtmvbnZcS2D/Wa7URLwodOy3Q+zPhbl2jahcoOv Fk811ZmSLw33ekvkGM4tREuT42lWvM+Pj/tBLuz3CcGgx4bwscAvWiNgMXuK88O85LOYCIIw WQV5cQCOpmlvZfuoZsBjN/Z7w0c40pP9SolHEi0d3PCGDxLFwuyw7RViEUi13eHqDb56qjje rZq50uhwGKT83nA8kS6Pjs/LshhT1vtFMxuLJdPJMGTMd7g10tL0dsRmCzfWWvce3WqQXgBV 9+DeCDHWQEM7DGJv/Axm0TuIzs/FaJNaG11tVZvq6eO6JHizk+0ALiOYgZWU1V6bdpuNSios VdQVMD7BRFortZosjA/asKaoj09qORrNNdrt/urhYZL1+9P97W456rS73XrSDecPO4dWP+Zw SIqKMpWXc2b2l8YzReTscL9tFUTf54KZ/eWpWnvNNHHak+2v1upoNNd344zXnehMFQl2Y8Ap V6K10LTNUu2XpEi+P64ELIQlUBn3C1KiudqqvZ66P85ryXipN1uu9d2iHuFYf26w1rXNajlt Jl0ABjKA9GgzzrgdoUK9FLmYDyLOZBdL9XyQcyaH21kBwvsFH+mMV2op98s2YDgjZJuDQUdp ttuy6LAH85WMH+3GYDS7Y3JvMp0OGumAL1qUEy7aSLsSclHy+lNKv6fUmoNxpyCG4nJ3DGrV e54mGSGjjGaz6VDJBtD5M+BMpDGflgOcMxAROPD4ucD2OSEScLK+wmTVefE6SDDC6g6FvW/P DszEeMRkOhEVJSnIW8ycEPKxF1Ix0pxwn8nn01EfxzoDQQ9D4ATjCQacjM0tJlNxKRpPxYNO zh1K5Aq5BLzEjDjMH0nlC7kUsD+JMiw4yLnBrCFxVsZmOfe8ACQtNsbChqqTUdH/mp8aMIJm GLPp9UmHOmwO3sEyNpuVIoykhbnOYsBNZpZ3uXjWQkKiCtkojrqsoGZCYziW5RzA8iRt5Zxu J2eF9A8yV4rhnC6nw0a/PMgJm1gbdtIuuA1AfjEf/EKabSQoPt4cNu651/z+3P3feibCiApi bPxNep7CZDKhfhxJUcZ/rqC50RigCiSEBon4/hyaLy3j9fsERrlSzU4xYL3myG8QcYsv12pm PK/mexW9r0Ba/r7jrQWi35ed+69CpPWm9q5xfqXl6vIlHXybGGpwiUZQkNy8L9/Jf1ADfRPI 5u9dKF9+V+DlKeWy797n7+Q/qAGx6ghKIQd1c/rOS2MkB983+NvvGz8I0vtlACDLO6zANu8L Rlg4/v33ofcKP6qF4SaKeuOM67LoLQrd38O+in/gP8ohv/cuLA/d1yj/gWBul/oPfwLdxQpl bmRzdHJlYW0KZW5kb2JqCjEzOCAwIG9iagoyODczCmVuZG9iagoxMzEgMCBvYmoKPDwgL0xl bmd0aCAxMzIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjcg L0hlaWdodCAyNyAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0lu dGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAFlkm1T2kAUhdndvJKYopGKDdBgLVYbiako0BakEE0AcdgkNMTpCAgz OI7//3MXMSHqfkl2k3P3POfeRCJcAJIFQLiNPQGiOZ6l4PtvALFSekcWaBj7ffUKaSl3pBcz AvVOhpIZvd2pH8jsWxmgU/tN/w5XcwJ6I4NcxriZP46vDreY1zJASYW6//A0x2dKEr0yAtn0 sXV7P5v6f4opOl4RIDFfvfGHjj/q/djl4xUhs3XYdgfmhe3hxpcPcRlKKuVr9+pUq/WHtv6R W8uI869NFzcO1OPLIf6lbqyxl86vA/y7qH5v/Q1sbTvCBtTGXsOfjsyyXun8m3o/8xH20nlv spg49mV3OHu4syJsgIR8zZsvJiMXu8H9YobPQ2zi/JsZjINB17KsHr4dr7FR8lO57+NWuaRp Wum87fgh9tL5heM0j5RtWZbTWa3l4PoKG3I7Jx2vY+wKDE3TjKicdr0XbCR+rvYHjf1VPM81 Bv1KXkQJ0o69mm2ehKGSmw3TqhUkChDenF4x1DBTyKQKRqWUI2EBxMtZVdnkXhoIELepqFmZ J3MAKV6UBDaaCDJ1giRyFEkfQERRKDaZ0cF/DstErgplbmRzdHJlYW0KZW5kb2JqCjEzMiAw IG9iago0NTEKZW5kb2JqCjE0MiAwIG9iago8PCAvTGVuZ3RoIDE0MyAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBbVDBToNAEL3vV7wjm1i6MxQKR22qiQcT0008NB4Q W0MibVrUpB/q/zjLYIRaOLzd2Zn35r0DHnGAAzuQ4xnmWY7jBk/YYbpoCVULQlv979jCxZnr PtShl430uu6/3B+EyDmk8wy5SFHBAylWKerkzJBbpjrWibzJeNiwanDjkc+0LkjEcV4kGYhT +AbTW4rFEfzWrBEtyt23RVIg+sCybOt3CzmfICB4bSHbRF9WNkK0r18tnuHvsfSSTZdOnKhR s1qI4llUK0zvJKi3dhwYIwHNZYc0mNx2RH81c5axCxkPjDLo1yVx756Rik91x707rE3kLSY5 ok8B2X+j0CqIl1AsFU4KVwIyIPYDPGhxb03olBQGLI3eXkbFo9768URvY05WMqdvPRSjXH8A reeE+gplbmRzdHJlYW0KZW5kb2JqCjE0MyAwIG9iagozMDYKZW5kb2JqCjE0MSAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMTQ0IDAgUiAvQ29udGVu dHMgMTQyIDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjE0NCAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBS IC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAv RjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjE0NyAwIG9iago8PCAvTGVu Z3RoIDE0OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBdVJBbqNAELzP K+oIUoKnBzBwzFrZlXKIFBkphygHgmFFZIziwSvlQXnS/md7aKwwzgYONTQ9XTU19YYHvEHD aJA2CbJ1jmODRxyw2lhCbUGw9deOFjpa6+lB53qN4l49vf/vd0SkNdJsjZypqDALKiNUNNGp 5WzeNU295n+83Smse/wokSdSZyQyUV7Ea5BJUfZY/aSIT4SyVU8INtXhb4i4QDDitrLdPgSv 38HAeBOC1QR/QlaEYOh2IZ5R3uG2ZG/OookNcqKTVKtPfzzRniEXotNMz6IzinIjumVpClBq IjJZojzlCD5ClK+i49t5yTyMMWMfGM5DlDs+gvum2cE29XDYoa3qcThiHDA2+z26Fvb00nfW dsOB3fieTInjF2QFMyy9BnvNDKdqf3a4rvoG7VEcHnpsu7FBqGbbfZt1FM952m7YoItEbrH6 xXn8bb1cKoMYxOZS6rLUTvfl15ZR1i7KCysN6Bwmmn1kTDlOchVmDpE7WBniOkdwYuCYNAJW gCPjipXAu8AVA2/g4zq4l+IgwGFbTOnl68Ursmmuha/FbY/l60qGzUUjRe1B4cX3H76d2O4K ZW5kc3RyZWFtCmVuZG9iagoxNDggMCBvYmoKNDQyCmVuZG9iagoxNDYgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDE0OSAwIFIgL0NvbnRlbnRzIDE0 NyAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iagoxNDkgMCBvYmoKPDwg L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3My IDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAg OSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iagoxNTEgMCBvYmoKPDwgL0xlbmd0aCAx NTIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZWTzW6bQBSF9/MUZwlS g2eG/2VipZW6SFUZqYuqC4IhojKgAK6UB+oj9X16hgEZnHpRe3HgMnPvmW/ufcVXvEJCSyip A8RRgr7EN7TY7QeFYoDCULxfUUF6kZx+qM1aLbhWTv9/rzeFlJQI4wgJS6lUr0ppW0pN5cQ6 N3dNWe/4jduNw6LBQ4YksHGqUtpLUj+C0iGyBruPyuOJkFXiO5x93v5x4adwRjzmQ31ywec3 UKj3LujG+eXSEZyuPrr4gewzHjOyWUwrAjKmg1CKC5+N6Q2QK9NhLGfTsfISbX3bR51ChdpT Og7Exjmc3y6yn9bHzXzBnIwakwNlSSLM8eE8leURQ1l07RFVXoxdj7HDWJ5OqCsM5+emHoa6 a0njdjFhiV8VS1lhzRpkzQrn/LQQLvKmRNVbwl2DQz2WcMWM/YL55vHe4YoCkNSEi8XF5aL/ G5eSKTTTLUeYeX3p65e6vcCY5sPz51Y/7Hl3V8NywO4TR+VlWEaGmTgCGj4U712Fps2rqZW2 sfWUSbNlhUFDmT4X7HM1XzE1ZKdbw3rub8M8c3GXwDlT2MGllcEKu9kEc1cYebNvHyjcwCs3 8mSDnRXOwSpLY9+eN8HeJpu3+/bbNqe2QbmRdDNZfwEjyfnmCmVuZHN0cmVhbQplbmRvYmoK MTUyIDAgb2JqCjQ4NAplbmRvYmoKMTUwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQg MyAwIFIgL1Jlc291cmNlcyAxNTMgMCBSIC9Db250ZW50cyAxNTEgMCBSIC9NZWRpYUJveApb MCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKMTUzIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0R1N0 YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAg UiA+PiA+PgplbmRvYmoKMTU1IDAgb2JqCjw8IC9MZW5ndGggMTU2IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVMGOmzAQvfsr3hGkDbENBDi20bZSD1utgtRDtwdC YEUbQAmk0n5QP6n/02dMGsg2lSo1HJ49sWfevJnxAY84QEJLKKkDRKsYxwKf0GC57hTyDgpd /vpECemt5PBDZc5qwbNy+P583gRSUiKMVogZSiV6EkrbUGoIJ6a+eWvwuuB/vG4Y5jXepogD aycqpb048VdQOkRaY/lOecwIaSk+w1lnzU8XfgKnx33WVXsXXL+AQHzjgmyc7y4ZwWmrnYsv SD/gPqU2Z9KKAhnSQSjFRZ8Z6ZkgV6TDSI6kI+XF2vK2S51AhdpTOgrEjDmcHy7Sr5bHTX/B 6IwYUQfC2Ykw6cN5KIoduiJvmx3KLO/bI/oWfbHfoyrRnbZ11XVV21CN28GEVfwqWMIIU61B rRnhlO3PCudZXaA8WoXbGpuqL+CKUfaLzDfTeyXXKgCVGuRicHEp9D/LpWQCTXfnFEa9Ph6r 56r5mxi3KklffhD9j0oaar4fXVGjupsip5imT4ueZfxGYc26wZNT1NuCrcvtjgWvGpTDpj3W T+6ko8Uw754/ju5mzV68Gv4Nlu85+s/d/AnQ8KHYxyo0Y1viURwwt01fDWlejUlZNdR5btXY ssSQk2vLqMd5NT2UuljEcE4Ek52FzgJTNMbMwouFOwIvsIUXsXAerLG1wLmeeKntbjszUlJz ZLgOx7e7O1f89glHW6OcQTLRFY+/AKAfKJkKZW5kc3RyZWFtCmVuZG9iagoxNTYgMCBvYmoK NTQ1CmVuZG9iagoxNTQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVz b3VyY2VzIDE1NyAwIFIgL0NvbnRlbnRzIDE1NSAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3 ODhdID4+CmVuZG9iagoxNTcgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0Nv bG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dz MSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVu ZG9iagoxNjAgMCBvYmoKPDwgL0xlbmd0aCAxNjEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4Ac1YTW8bNxC981dMbxJa0/xeMjdbiYsWdepEAnpoelBcKVYrWbVlJ8i/ 7xtyV9rVh5XGaFELASOKO+TMvHnzuHf0hu5IkVGklXFUhUj3E/qFbul0sNJ0vSJNq+vdFVNS Mqj8RzNeawTWqvzZv5430kpR8Imisfh/am1lylY6byfatvFUtnqC3/A4n/B6Qecjiq7MY3Ra Ol8pS9HSaEGnF1rCIRpNxa/UGwzfXrzoU0rUo5/vZx9mt/RyMsUE9Sa3q0mffqPRj/RqhFAc DMb6QKI4y6dV0iudgoqN0zoosh4bVxzN7N2UDH0iR5c5RDQY4lT8GQ7oTqz9glcxe5UtmNS2 MKyPdXp2dvXTi+HD5/mETq/mms5fDvJ5Wz8MlrcPk9sHcX5Z/3Q1ub+e/PXwOJ7T/Yzj76t8 WOtIh4qcQoYRrh8WJtLLZb3Tq/rpDirEPlTA4Do1QZPzTWpsAcIJxkp6cqGVFTGaErLyrnf5 rk+X43lOxKfxfZ80Z6RPxiBR21lpDtXyNodBHA4DHQwDEMgHRBSMDmRDaKKQxNNRaAF2UxuH oiBaUfBB2uArQxGobAOUelfjD3B69McGgY2vexOwRmJddhmJHSyi/Iwy5BFOjbzuRaLoIHGT xjUS2QKjsWXhEBK/KgW6Lhsc0GhLPkNHAIkI2vNyYEADwVSikEQrB1pLXVkwRHBbOQAcz4E/ 8F9vWeC4muB7zQui8MLerDSA8HWV72SnjrM6VPFgQmkcgOiiTDZpWoAclay8CXmuskjjnKzV SGqUIFyNr0OciTm3IU3FHB21kxF2yJskvQHIYct6mfBH3kY8F3WQXntP3iUZPdhgLtbbeZuk CQDonG72GpsygzQFv0aKdUYGhomtrIw6VmKByvJSVcHkOZvgC/a2lkyElynxURhNFk7bgHln PE5cWZzYImNOG6ywXstoUxJOeYkVOOzGsIOzQVUOczd77UxxVP7kZpS5rzm5q5ysXPIUtKpR Ymq3MDrwFbpTt0gBkF2mIq5ceju5e5ysHvpi00XaIMhEuG4UOEzwSHay2GVBFaMfmyE4KLcy O+dZYYFR9qy9uvSS4hX3jz254OUusQvFuA9eFONlNhtHtDfGm9WHivur2kz0OdbwLkTAGP9K lwGIn67tY12G/ePQ7NS2dVJph5YGDDWpQ38trWbIxcy9qPexbjL8Xet/u82Y0mwxVBpJ9yjX 3GyteWab6YSh3WaCRXl5VA/TaxMH4ARx6J39gybzZXS2F4BBoqBR0RFVkKoAMsBppdExTynm NaYzUAOKoMUFO3QWHEx5MKJJSToVHZsKiaxi9AaQQzKQCuBHqXXFlNJsZFUlE6q8VNC2GZTG FNA4wA0BHOgq0IDKoIXMPMINrDCvHuvucX0zXk3oAijjVnK/oOHj+8VstZotb9ftJIu2NY26 1oa7ZFRJZYxjaVVtpTMrqE+zhxsaLJd/zib0ba1ts9IVPYK6am/5JCflRu+Amm3hiiAhVAfI hp/ytmo/9TSLiDtqybdarB5WaWy/lmk6eKhD29SPfWb9aETUQKhnGunUT1eq1vzxrncGqbqV 5HZw+doAeYCm3PHwmE4/7DpYjD3n9oB7hA6OocHiyB0h0EaPdC5vrU5Re74rjqAHtNfI5q5A vRjP5pPf/wv2sKhV46Mh3Cyl1Z5LnjVC8OhYHjTgU1YBgZGHAi0qYoc5cAfjuymumHgkcCWz rHBC46bIsiJIV4GUNShKK8d6Z72JhkBxynFLhqzYYyfLCtTEHlnhYC73cV0j6xh18DWIUSVY eNbUgVgzmeSrELTF6q/l1hW1lcwIRWsMqMYCJAXLR8iKd3y93ILyN20or3kCF92dCy6kIsQl phHQmCA1UENzSriRl1lIDcwyZ2cJ2axGFr9Au7BxE/i6WIzbrFjZeJnNxoVOLAOhT1urn2ad bk22WKeU6/YVeaNdIho2SqIhHX+k9I5plxw8hCYnCinLFc6q5P+pXUJhIBACGMFVGWDMQOGZ 3NsJQ4d7jcT1APfAPdrl8gD7SFu/ghoOROe2zDw4pNPv8Qrrw6r7KguSobQsz4umuR135kT7 7Ve+WbVqDk2yeckBmcVJPMGI7lTf60394okrbdQXJ5F6jxCb5c0GD6vyDXzK38Zl+FyG7zDg Abz84OF1mcSNlFd+hLGNlUWZfF8GvD/g31jVYqgft+Vb16Ypk6oYU+VbahPAm78B1XeH3wpl bmRzdHJlYW0KZW5kb2JqCjE2MSAwIG9iagoxNjYxCmVuZG9iagoxNTggMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCAxNTkgMCBSIC9SZXNvdXJjZXMgMTYyIDAgUiAvQ29udGVudHMg MTYwIDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjE2MiAwIG9iago8 PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3Mx IDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIKPj4gL1hPYmpl Y3QgPDwgL0ltMzAgMTY3IDAgUiAvSW0zNCAxNzUgMCBSIC9JbTI5IDE2NSAwIFIgL0ltMzIg MTcxIDAgUiAvSW0zNgoxNzkgMCBSIC9JbTI4IDE2MyAwIFIgL0ltMzEgMTY5IDAgUiAvSW0z MyAxNzMgMCBSIC9JbTM1IDE3NyAwIFIgPj4gL1Byb3BlcnRpZXMKPDwgL1BsMSA0MCAwIFIg Pj4gPj4KZW5kb2JqCjE2NyAwIG9iago8PCAvTGVuZ3RoIDE2OCAwIFIgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMDggL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4 IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgMTgyIDAgUiAvQml0c1BlckNvbXBvbmVu dCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QgQAAAADDoPlTX+EAhVBh wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwMA7MCNwAAEKZW5kc3RyZWFt CmVuZG9iagoxNjggMCBvYmoKNjMKZW5kb2JqCjE3NSAwIG9iago8PCAvTGVuZ3RoIDE3NiAw IFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA3MyAvSGVpZ2h0IDI4 IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAxODQgMCBSIC9C aXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dAB DQAAAMKg909tDwcRKAwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgIGHgQEX9AABCmVuZHN0cmVh bQplbmRvYmoKMTc2IDAgb2JqCjUwCmVuZG9iagoxNjUgMCBvYmoKPDwgL0xlbmd0aCAxNjYg MCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTkgL0hlaWdodCAz NCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgMTg2IDAgUiAv Qml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3Q MQEAAADCoPVPbQlPiEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYM/AcGF4IAAQplbmRzdHJl YW0KZW5kb2JqCjE2NiAwIG9iago1MAplbmRvYmoKMTcxIDAgb2JqCjw8IC9MZW5ndGggMTcy IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQg MjcgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDE4OCAwIFIg L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAFj YBgFoyEwGgKjITAaAqMhMBoCoyEwYCEAAAiLAAEKZW5kc3RyZWFtCmVuZG9iagoxNzIgMCBv YmoKMzIKZW5kb2JqCjE3OSAwIG9iago8PCAvTGVuZ3RoIDE4MCAwIFIgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNiAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjgg MCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAxOTAgMCBSIC9CaXRzUGVyQ29tcG9uZW50 IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITAa AqMhQGwIAAAIOgABCmVuZHN0cmVhbQplbmRvYmoKMTgwIDAgb2JqCjMyCmVuZG9iagoxNjMg MCBvYmoKPDwgL0xlbmd0aCAxNjQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMTU3IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRl IHRydWUgL1NNYXNrIDE5MiAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0 ZURlY29kZQo+PgpzdHJlYW0KeAHt0DEBAAAAwqD1T+1vBohAYcCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGfmA+ jgABCmVuZHN0cmVhbQplbmRvYmoKMTY0IDAgb2JqCjkzCmVuZG9iagoxNjkgMCBvYmoKPDwg L0xlbmd0aCAxNzAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg ODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01h c2sgMTk0IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+ CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ43iEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wMDTwAAb5AABCmVuZHN0cmVhbQplbmRvYmoKMTcwIDAgb2JqCjU1CmVuZG9iagoxNzMgMCBv YmoKPDwgL0xlbmd0aCAxNzQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggMTYwIC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRy dWUgL1NNYXNrIDE5NiAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURl Y29kZQo+PgpzdHJlYW0KeAHt0DEBAAAAwqD1T20IX4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDLwDAz/A AAEKZW5kc3RyZWFtCmVuZG9iagoxNzQgMCBvYmoKOTUKZW5kb2JqCjE3NyAwIG9iago8PCAv TGVuZ3RoIDE3OCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4 NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFz ayAxOTggMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA wNPAABvkAAEKZW5kc3RyZWFtCmVuZG9iagoxNzggMCBvYmoKNTUKZW5kb2JqCjE5OCAwIG9i ago8PCAvTGVuZ3RoIDE5OSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAw IDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1W2ZKiWBAt9t0FV8AdcV9RVCw3FFHKDUXL2rofZjpi Yv7/B+ZiVXVPx8S8Vb5A5s08JNyT53J3BwyCEWAwDHnO1xiEYCTDcSxNoF8GC6OkP5rMyhkp zOHI1zQLoXQk2xiMJyOtkvDj8Fe8PYRQkYJu7Z2j8zBtCDTyFaAwFpCHm9Npv9vvV70Mh34J KBVvrd2DqWuD0aid+hpQhE0PHXfZykpJuZCNeq//QTBvyyD4d4NAELoFIe/yycP3EEj9oCXC 5SauOyuEWdbPBxkcvhGMZRkSg0EuRpAETpA0TREESXmcg2AUJ0kcQVCcYjmWwhH4PQTyKJrC PVoibHbkPi5rMQYHhiHvBMtkElEfiSAYG4qG+VA8kYiFQtEoz2IwjNHBaNhHkWxITGfTAs9g CEoFIpEQHxETAk+j8B1MS9ruyRmX4hzoA4ZROpyta7quVdM8hdHRfLWsFBvdbi0vl6pKnEFR OipXFDHIS8X2QO+3FYHDiUCqVCkoFVVryWESuYPxUMlwn5xZMx0CD0GoaLG/WNv2ytBkng5k e3PjfmisrLHaHEz1Ypgkgvn+pJtPZFsTy7bXy1FN5Nh4bTwf6+Pl2mgnWBSCUEZsmO6Tux4U 4yxO8MrQ3tmmaW8tLR2MlBfuyZ4vrOVYbY3sdT/t4yTVsu8rxc5iu7FMa/MwrcT4VH/r7kzD XBlqkkOhOxjjpPrscL0eZnXR50t2H07biabNto5ZE4X6w+vzw7CjqvVCQbOdRTUeKUz3G73W njvH5aCjW85Wz8Vzo/PbydDUTkuJ3eYHxrl4aWBfnt1FXYqXjMvjuletDezzrpdNNLdv13k1 JYrxiFCeOZt+PtdZO0u1poONmDYrbcNxF9VEfnx53WmyJAoR7jbpgDd0KNNeuC/utJpXvdb0 Vmtou3s9n2puXpx+0kdRFMkltY1jdtXZfndfqU4vb6dZp9mdH9xlI62M3UezHGZAGuZpksdh lPCJVeP8vNObuvP9dTvp90fLh2Unm2zaj3YjQni8JkLl+fFgLXdHqyVX5s/fz6be02dre1xO KaPjcZRhPfp46gm4ThAYijFCc/3kznvj47enta62VK2vKqLUWJ+tCo95w4WwqcH+6Xq9OiNF Ks2fvzmzbqvd7Wu1tJAfHfaDBP0pcTDGBHk/TZBBZXa+LPv3+5ez0cxnszk5I4TijfXJLAdv KgMTkdrq5c8fb5u2FJEnl+dNv5TL5ORcMhKR7w/bnkR9giJUOKNkhVAwXjbOrqF2rYtr1NOi ICWTMT7eWJ0WpXdQCOWyo+tff7/OC7wv2ds/bvqKJIjJlBgOy/f7rSb+AmWkuq6r1WJ9uLns 9FJ5uHMfhjVFKVVK6Zj4L9A7mIy1dn/8cHsJhopUzZMzV0v5QhmMV+w/oAnV3NjLubU/n+ZV SarMDqfNYjyaTPolSawvD0Yx8C6yEObPT8/XZSVEYFxKs0+H1XQ0no5aWUHWN3ZH+NkpTEUr k83xdHLPB7Od8PvFurE7OnswLsOSECuNLT3n+1BumIo3DbObBLtM8PJgfTwedlvbaKejaXVh NGLk5zf1Bqo6mK9se3lfT/oJArj6YrWy5notEQwmG92qyHycMaDVVK2e4wmgj1RI7kyt9cqc dJVoIFZQW7kg7kmwZxCCc9F0sd5sVHIxHxBHjI1myo1mvZwT/BQVlFKCn/jsACEDcU/cIFBG BiWl1mzWCinAeS6aTIS9+IcBhSXZQDgS5jnqpssoyQU910cBoSQYjiF+nttgAmiGBIJ5a4bx h4CKBlgCRYBes6D6E9NbhxHME+iPXwnwFAwnPBdIOpg2oOw/k4EP/mRuLqhCPV331r373/Le C8CR86sUHEP/9n5Ceje/rfxf3j/7e+fZCmVuZHN0cmVhbQplbmRvYmoKMTk5IDAgb2JqCjE0 MDgKZW5kb2JqCjE4MiAwIG9iago8PCAvTGVuZ3RoIDE4MyAwIFIgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMDggL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2 aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21w b25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1Vll7qsgWjcooIIpo BMQZcR5QnDXiCCooTokxOSd9T5/+bt///wNuYU7S3ffhvmU/7dq1ay+K2qtW3blcbo9jbrfb dfe15nJDqJcgSYLAUdjztWhumAjysUQiLvIhGoe/dG8enM0ovcGg12lWMhEK+UowDxlTjcPR 3lobfViOUrD7684MojPa4/fnvWXtT/aswnk9X4jllxfX153W7U13T4cHyQ9/XX9Agdzicp6U EsmSdrisqiEUNP+HuRxc120EvE/n3fucA6y50ebXUb9zyBk4EzcDhHKyAdb80e7E/bTQMC9W I4J5YBRDERTzejEYJHkQDPc6fHADdmAg5LoDMdQhCOALgmEIBCE4SVGEM+dyeWDMoRAGAxRn GpQC6xEIoN2wdu0oRXL11Xmj3OMIGQyzTDASFcI+DEZJ5l6I8iG/F0GIQJj1oR43hPvZIOU4 3kCIpb2EPxJPJaOhWwijw2IiEQVrIZAXCgWZEB/lGC/kdrAWT4ehFOGknnWYFYKYN5wp5iW5 0mwUogEfK+ZqzVajkuH9VDCel0UagTA2WchFfTCEh1L5rMDep6qdfq+ZF3wo7GWTZbXbVYtx xosHYrlCViooai3NYp4b1vW67taU4ea07ad8mC/Zmmj9nrZc9PJiVFbHC8PQ58NaMhIt9gYV nkDpZHs2Bi2L+tOtoZqNZdtL01zNOnKYIMJye6obxlJT0yzNlYeTYXc417V6lIRcYF/Lb79f tyvz9PJstmIUFshPD3tjMl0shtVcZaCba11fWeZczaZrE2MkB6lIbfV8GksBiq/PjX5eauin o7nQugWOZqWeYRqzmbFZqMlIor05mDNtttQUkbph6W///vF8fnp9e9n2pSDJllbXy6rXUBq1 cn20tpaDptKZmLuFmq9qlt4Qw+nh0x8/rHo0LA2tVVuSutvLftquFRMhRmyu9puRqo43u1k1 kR0eX/aaCipJ94C4zr6+/3y11+vt4XxYqgk2Utm8PE6KMV6Iy21jp7ckgYuXx9vtuFrqra2H Qrqqf/vzj8dRLq0sd7OymFCtiz2uZqIhms1qp7PeKpY6xtHsyPmH09VU0wLPhcDtd8N6eTEH 9arSm2/3SyUera6fd23Rh5OsNNhuhxLjxSi+ttzrzVx9tjN6zdHu5be3i9Fpji2zlwreF2eH o97JCQEqXDbAP+nWaj3jYA0KxYfDeZZnCRy/ccXpw8vxQeZC94na/HTUCsm6cTYqgNOwXxrb 6yaPe27ubtOW5J5prxab49EGN5qxtPbLaoTwiY2lbeu9fIThFevbdTNqtwfz1VyVCyPbHiRI yCE0IDPAmj8CfpEo5k/2D88rJavox0WBge8gOqvZq/o9CnZPpYY7s52MVZfny+VyMkaa+Qgc e5ihETSQVKbWfjPMC7Hm9vVJ7yo1RW0rciI33FqdqPfjOr9hbVsCASNUvHd8MZuyou9n+QB0 5/GlH2yzJZIwhDI5DWwxGs4MT//6+Wb3S7Xp04+f38wG74UQMpSoPlgnqy+nG+vno1bNJJOp dELgwBlsWgL+NyzA5UEm5Gf4wvTxuqpLAGuac7CIWMe0tSJHU0xCXe0X5TDNKdsf/3kzKrFk e//zz5epHAD0DYSFdH1+elzWMpXZ6aCV4zwniCIXkQbWRuX/gXV9NloFOV9/2IGTyydrv7Dc WLg8s81RRUrl1LltDdI0HsjOXn5/GqWC4aL+/cexIxIwxsQkuaBMT89rJSl1zcOqV5KkXCGX FOXhP7H88vz69rieaVN9dzrMq6JQnm812Q/duSBfvKXvzPlooBnb7aQcwWGv0LIeVzXQEPGe fV4UWQQiuGJnMBhvzud5iecL4+1+PR0ORqN2ISn310aD+2tfvtTo+Ho97Xe73XY9rooMKw8X 3ZQPurtzY0ymvbAsy7SstVZ1RBth5P60k6YRLFQcTZoxCvJ4ufJouTbt/aqdCNB8WTPtnbVZ gxsulm5Otco99nFeHoKvjI31Sl/OtEFT5n24T6w0izwB9NnlwYPJWh/cVvNxuyD4wGPEQ3By WQrjHoiK5kupIFA7NJhujGaLhaZmgjhKCcXudLlcTLqlWIiTlVoqgDja5ZgbpYVsqVIplwrZ JM8QMIQFhBhHg0Z3wDCaS+XLlVI2FiKdd48boUIcSwJxQulwBCiFywV52ZhcrpZlkcEhD0yG E/lKtZxPcX7CFxajLMi5ITnlUNLPsGwwyPgpHHHEESUoAn1/KgLlw30MGwr6SdRRO5CO4I4O Ak1EcC8GROnODWFkgA2zARIoGpBPjAqwIZbxAX1EvCQJ3oG/oMBqtwd+N+hdqkEAeL++Bag4 BCMIAmT5PXJT+Buqo/u3IKgPI+hHyscIXBZOpb9KfSL+PwcI+8dfcNI+R5/OLfa3nP9Z8Fn7 v3fKQ+AKZW5kc3RyZWFtCmVuZG9iagoxODMgMCBvYmoKMTgwMgplbmRvYmoKMTg0IDAgb2Jq Cjw8IC9MZW5ndGggMTg1IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDczIC9IZWlnaHQgMjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAg MSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBbZXZdqJKFIajzIgiICgQFXFCJVEcg0NwFpxRM3anc7ov zjrv/wSn0CRmdbIvWFJ/1eeu2rt+Lnw+P/Qefr/v4kuACSC+EY4zP1SfH8bIAHWMAI5CXxaA CSiOIV+FE+dD9cMkJyWUY1wKIezzglOuMBGOcEHU/yVVbwAsZ/ijCuGRTLXd7XY7nXZdEyn4 nBLINUARGMEmtWzss/AJ6cdYRcvEAvAFRMUbzv7gbtbr5biRCiNnEISHRVmgQ/J1p5Vl0LPw CQQF5Eq3mQbL4FCm//D6vFvOnVm/mqTPIB9MSZqejkZSpj264rHvQcFU2xmWONQH0/nJ84vb b1arlZLKk+etgf9IXNc0ic/01nZF+B4E8rA2dpkHoHB+8nQ/0hOxWJQPkwjk97rBKzfISMyX 0gKfsbZzIwpAoA/etOPmvFqgTG7gOhWQrwd6cNtJmsBxDIUh0AxUkCJR2O+DCC6uSAz3BvKD ShNAI1DI66pj31Bh8Wqyn38FIRjFyYqqyFwA8UM4e5mIhdkTCIdQipOSqaTIAg1kg4X4SyWj d9YPy3fQx9YYmpG1WrvXqefFIAIHxFxRFSInEIHRct64MVtGFmgQDLqi1Gj3hqvnl7Vx2tr0 56/d4HjYmYSid2arzXZp6TESC6eb3UoimvXOKEbRicrt1HHsSVeXKJTgMo2RM5+vH3//3ryB Zq//vh5WXvkbxVJzaM+Xu/ttLxsmI6Wh085IOQCqioxcGS0X0/F0MbeKAsWoLXuznI6mu9d/ zqD//jy6XkPe6EWj1WqYk8ODUxYo4dreWHn5CLqMaf2tO7mpmdPt0kzxl8bMXVmGbgwOP1bv W3v58+BYXXBFSmpSTadSeXP9uGlIIaHsuIMTqJZU6qvHrVUuGoPtflRK5Hvbbb8o8XHDuVu8 H/bzk13LpRTlMsYxnBC7zN6sntybOB39BFJz3bufu36tXB9u9pNKpjzZzWsSRbDaaHcu/66b 5oIUFSBwMhxN5it998fejIc/geqZ4uDp12FsNs2+7fT0XM3eTYosAoey54Yc329aMgl77oYG xVylYQ63zzsz8Rdo+PSy7dcrRr3V0NVU1XZHWvgLqCHhnt9ARLRg3rabHedu+xdI1ay7p0VL UxU1rcZj8vXUneo8joY/XRGQ0RsIDqmmPTOvjeHe7ShsrHI+bCXdWt8vWllZlOIJiY9q1mbR SrGhaOl8RT5APoQtjHbL9pUxOhwG+ahszN+rVo3L+ni3HVa1TK5QzEpCsuGsx6BE+ZvVw6lq dG64X9ZEb2s+hCmMDtth07Qfn+xKMmHM1rc5KdNdzSoiB5buNjOr27O6FSUi5Lvz5aRn9pz7 58XRRoJq2xldC5h3RnAo1V5ubMuy93dOXU3q1qSlRpXG2CryFJu+sV13s1o6AyMRDsWKHe/C LHaPd+Mii/ogUtRbVfXkpBAhaGbfMpvtwbh3lRDVcr0gMjGtVlZojODSNWtqz8a39SxPYlQ0 W21bw/HMHtWVEOzzo7SoxCMnZ/QjASGlFXJqOlfIxTk6AmyEJkPRhMwSMIQzclYvl/VcIhJA IIRkJTVf1K90Lcnh0IUPQgPArODT18aPECGWY2iaYZkggeFUkEQRlKQo3DM6NEBzPM+FKQy8 +SGUDDEsF+GYIFA9p4Ng+Oh54JC8FwRFYBhBEDAIQeAB/BU0q+e94AcK4m32cSGYd5z53ZfB 5/OM1Ht8E2D8e+Hif3y+9UMKZW5kc3RyZWFtCmVuZG9iagoxODUgMCBvYmoKMTI5NAplbmRv YmoKMTg4IDAgb2JqCjw8IC9MZW5ndGggMTg5IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkg L0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDgg L0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBZZJtU9pAFIXZ3bySmKKRig3QYC1W G4mpKNAWpBBNAHHYJDTE6QgIMziO//9zFzEh6n5JdpNz9zzn3kQiXACSBUC4jT0BojmepeD7 bwCxUnpHFmgY+331Cmkpd6QXMwL1ToaSGb3dqR/I7FsZoFP7Tf8OV3MCeiODXMa4mT+Orw63 mNcyQEmFuv/wNMdnShK9MgLZ9LF1ez+b+n+KKTpeESAxX73xh44/6v3Y5eMVIbN12HYH5oXt 4caXD3EZSirla/fqVKv1h7b+kVvLiPOvTRc3DtTjyyH+pW6ssZfOrwP8u6h+b/0NbG07wgbU xl7Dn47Msl7p/Jt6P/MR9tJ5b7KYOPZldzh7uLMibICEfM2bLyYjF7vB/WKGz0Ns4vybGYyD QdeyrB6+Ha+xUfJTue/jVrmkaVrpvO34IfbS+YXjNI+UbVmW01mt5eD6ChtyOycdr2PsCgxN 04yonHa9F2wkfq72B439VTzPNQb9Sl5ECdKOvZptnoShkpsN06oVJAoQ3pxeMdQwU8ikCkal lCNhAcTLWVXZ5F4aCBC3qahZmSdzAClelAQ2mggydYIkchRJH0BEUSg2mdHBfw7LRK4KZW5k c3RyZWFtCmVuZG9iagoxODkgMCBvYmoKNDUxCmVuZG9iagoxOTAgMCBvYmoKPDwgL0xlbmd0 aCAxOTEgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjYgL0hl aWdodCAyNyAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVy cG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAGN0ttT2kAUB2Czm3sgFyQkiFycYpDoCEi5FOuAmgIJsSARlsqgZGyHDtW2 //9Ttxi0On1w385+c87DOb8NAvx9xMb6EasPXBOAZDiWhiAQAlBBDShhU9cUnnwkAjKiqqsi CwnIqdlCYVcTyNVAwMip/aK5LVKADKdr3V7T1HiICdBSptLutUyVAaRkWFMftfaieACgwsn3 7s28X45zgJLz9t3PxdXxO4WBpBA/7N7eL8f1BBbFdL7+ephfVNMSy8fyp+j77x+ovr0S218u fNQpJSMx4+Ng9m25GAXSnflThIZWycg33BH6cjv31nI9cduud9lpnrnewLa96WUgncmwVTl2 xhOEJoOzWqOHBmtB/Xou3+jP7nxkFY1ie/wsnyuprVzTu7l2jtIJ0xr9I+UtWTObTruSiURz 5y9E50N6rnCQVnjllWgs3rkWkxhaNl72aHg1+C4UxHt8LeDxlv+R4N5vEnnv01WvFGOeenZP hxdVfAVSzJ445wdROhAY3vlgWwWdBVBIHNaOdiRqLXx8v1rORmiAI5HIJDc5GKQK0GI8k1Jx YHCMBDHEBqHC+YO0EA5xFA4ZASBJwueQPtV/AMpyWnMKZW5kc3RyZWFtCmVuZG9iagoxOTEg MCBvYmoKNDU1CmVuZG9iagoxOTIgMCBvYmoKPDwgL0xlbmd0aCAxOTMgMCBSIC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTU3IC9IZWlnaHQgMzQgL0NvbG9yU3Bh Y2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRz UGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvZhnk+LG FoYH5QAIiSCSQGQQOSMYMgOInMXM7M7OeLxe79q+vv//022Rht111a0tl00V0OF096PT3W+f 1s3N4aODzh/dsQD86v6q8M1ad2WpNb7KXxq/mVx6/fEEhGA4jmE4SWAwdGqug1Atj2o1l8JD HQRjBImj0HnoYx655IGRDvRI4Ch8NvlxpEsLCCEZltEbzXaepZAjnQ7GjVa7laENLMeQyNUo OphgQI0RPw0NIRTL8xyNnh8L9At6NFnMBuyq6DLajyV0CGURPA6LI5ROh3j6CALhJk88IwkW q9sncOSVDyDUKEiZuMeEH4bWITQPGgYtJPw2LISz3mjIrr9+qLfaH0gBT5h98ajXGSgPx02J pzQQCGPEYn/cirscwVRS5I4gh14hwhpvTfpFkdEco4Mpm9QcD0oe/RUcTDlTtXKIxa48/gNI b6YQZhLThbjHGes9vqitqIWAwXozCIXJ0/O84LEH8nLaY3ybNIh0FhbPT5OCYADrDiYs0Zb6 8tAJMchbn7BelIfdpBX/m3BgWpxJuRyx2+PK638+bWoBFocR2pEafvj9y67isQiZRi1hf5s0 iHLL6pffPwzTDhqBcTZQ23z646dh1HQNZ/DXZ8OM7e/CQbg5Um0WvKxFGv/85x/P05KXIShb rK3++t/fVFlgrNHbrhw0XVynwe1/+++v+45kowjGW5w+//HnqxJjEaA9MAwDVbmBjYHmYpQD j6TltN2ric05AdLADj4WnAXrYAnk61KjWSN6T6HbTvF6TlJevnx6UQdZgbOFbxfvP375tK24 9UZvedDLOC6u0+B2nz5/fFrWwzZOyA7Ul18/vwxjLIbglN6gpzAEQg5weaeBJDQ9AWKDa8Jy UBggMRhBGwy0VnUqASpGkaAdjBK0Xg9qDuBg5ZtjrVEzwpKsNHz/8qiqq142HKtOtur9h+d1 xU1T9kx/fBtgzjtPg1s/P93vd5OqFM52V6r6+PJuEONIvdkl+kWXmUZRDW5cFHmbBUjOSVi0 BMXarCzD8h6f38MzxKHKajVzVqfbwdE4ydgEUXTbjGDdA8/BlLs4mlRFPQ7gHvaT/mS9HDQ7 k/VCUdaPy4qbwrlYZ95PWc8bFsBVVo8rRVlupp3mYLme9Kf7+75kZZ3RfLVeK0QcBuIAV46E YhGBwRDC4pOibiOKkFa/FPV5gqnybb2SEjkCAYoVlcIhKVfMBHjO5ksWZbkY9x7FCzEGm4tJ wUlirDTYr1rF2mi3V9X9olOujtVFxU2iYHEvpmWBPkmFBrdUR3Kpu9yru/12VCu21/t+3OGM 1QbT+WLSTNgNJs1zciJTvU05aZzxlXutlIPCTYFSQ06nSp3RbDHvl/wmnLIn6p26XL8bdvIh n1TpDhVl0C4GNPHSYebEYDPKWHEUwKnzSiRWnb9/fVF7mXCmv9PgEEqQF+tWwHjajRrcYneX Dmfu1JfX97NqLCov1H7CJebaw9FktVvUQ2ZOg6vEcx2lETEb7JnRw7YVYg3O7N2oXSzU75Tx fLsdZp20XihN1tNeuzfolFOZujJVej0FqKjXgOogwp6fqsM4hx7gZkWPM9JcPz2Mcl6X1Ntq cDDhKM7VgcSiYBWAzwFu2405vbnRw9O6EXF6S3MA5/YmSuWifLdRlbTDAuZjVIokWrNhXrAF 6vtfXmdZty1Un03q6VShXCw1puq67meM3trm3apdzOVz6Wx9spo0isXWZNFLgGV0mKN9H+jA ES7vNPFScwT0n7NEukc43JabPUzSlpPcH+E6YTMHzpAROFJMLgAPppX3BHy+iDzbz4uCTYMr +ALl8awpBdLDp8+/qI1oIDdY3GX9Xr9fDKS6W7UX4Rixvn2cFgMupxDI9ne7YSmeqCibaclN wTDtvV2rvTBzhrNTensknfCyFHuGwyzp6eM8d1bUM5yJYr2JdNiupx0FACdZGc5md4cq0/tl xcuHNJ0TnPHuQqkWGot3L8/3SqXQmk1rQStnsTm8ye7ufiCZGfF2vevFLDRpdGXH7+5HciZT VdYz2auHwTnT2KqdkPEMxxMobeZtDI6ZwkfPQag5NXlcFOzE8Sw6wYUYDGdsvJnGSLsGFzPr Gd4bybSWj2tZPMI5zaI8XY76k81mudoulcFsNUg7DAazyx8vD/cPw7jFJN4ul7eiHoFJPjd7 epw0yuXbu9FdHmxAWO9rbHad4BscOLtAHIfCCPN/4IwIkEwSR2DiACdZTY5wpih3Fg+rE1zW buRTg939/f1WabSnKkgs60FWb/bG8+X6SL0/wNXmMyBYkA7nc/P3+6Gcy+SK5VzISh6ndaed 2qc1x+PQ8ay5wMHHac2DmqsNoTn7aAj2lOY5TUrkRrVUU7YL2XfwXJanmUB9+9PH52Utkenu Xz8+TfNOIyvm6vVyub3cDTTP1eaTkouEdJg1PX7YtNNBn88fEB0g5gFzJC93vcgV3HHybq7g bNnZwzTzzYYAcAfWmxNc0hOWhwM5le2sl7WAMwzWXJYnSUdu/vrlWUl5fOXVx8/vuhHOYE91 lFYuKU+3SpJnfbXZpOgEcCgb623X7aTX6XAJAm8EcEBKZrs+0ImL576D0zyz19TmBKPp3Fbz 3NdwvkR3Nakms93Npi15Yy0NjgArt/fu533Db7bFhx9eNxXBYBDK02U3l6zO9tOCYA3cHuFu EL23Ml2PqolQKCpFvRw4wTBLcrgZJi0YaorebcbZ854Engu1V1PgcHDAVRab9hsM5SpNV02w TM9wfG6y6SbERHez6JTk4f5+mAsnmtMBCJlgYDxTRxk7bfRWl7t+3ELQ7tJ0o9RKrdXj+jbk ClbHSt5BQmAGrLHWfDXu1m8bjXLUBiINwNBajnN2AjUG66Nu4jx5N7DBJyu9tJ1AtONrLnsu xxdpz9wpFfEc+UK4Ndkd3YbBMJP5sNkcrrdKKSbJd03JgkEYF6l1KwEGA/Fzo1PwGFCCT/Xm k26jO98tW5LgP8REBDistMCyPV0uZpNxvxq1Al6YFsrjccVDo7QrVc75GPQ0rTDliJfyQQ7D 2GhnPkjbLgc/zgXzJekSfupQkz9XTrrN9qjcasqlartXT/v98UJaBJ3BtCOSDAE3IAZ3LOE3 4zDKeLON9m250uh2SiGHK5LL+A/xPAi/XXG5Oxj0O3LCDdbcDXjuRHdUD5kw3OQSBfNb2IYZ HaLHSqOELXU3qQcv1OAJrR7RoTU+fHQwaRFEp4ky2HzRWNgfCMfCHpvF4XGB0AKEZAarw6JH IQioop2jEHCtM7lCsWjQH4xG/XaTiRfcFlAM+oJQvU2MpdLJmN/BaJc7HWL0VfrtpA1EL7RR T5xuhtrNBaMNehJF9ELxrptxXqhBH6TBQGGHiEvDgxBCb6RxBCWNnJllGJZjjRQJGmudgW7I Q/CoJahTCW0ycybGxHEMjYMAFYxyUimEMLAWq4Uzksc7L0TwicNiQGAYQY6x89EjkJaHMS5U 7VSC7CVMBzH3XxlqsTeCYiiCoCgK2sHgq8Wzh8D72wSwOxqC4Py6MxAYg1s86OQY1Guu8+Ya lYjlvKYOZOcfbc0ka9U4/+a4c9Vf/eu0lxKHn6vaS/6SOJm85b+2Pq16rRDccEKFcsJ5uk1f 2WmVqEnMllPC1dXwa4N/OAcu/Hw4Lf31+BDO+ZOJry7V/zDON92DTcL7fA5wRf6mAmTBewXw OgLs4StXf2/1T5ZAKM2aTV+9rTkPd6j6+kXOuepf+gd7BCfwr95hnUfWgbDo6r3Yufjf/Aex z+lq/t2ox7Dou+J/peB/JSfxSwplbmRzdHJlYW0KZW5kb2JqCjE5MyAwIG9iagoyODM1CmVu ZG9iagoxODYgMCBvYmoKPDwgL0xlbmd0aCAxODcgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggNTkgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQovRGV2aWNlR3Jh eSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQg OCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVVfmTolYQHrlExQtkxhtwUPEW L9QRFG9QDnXwmJ2ZZJNUpfL//wN5aO1uUtnUzvYP8IrX3+vu93V/3HkgCL4aBHk8dz9jHgjF AwSwgB9HYehnwBBK0GmW4zgmHScJL/wTWNj3IHRHijwaSqKQIX3Ix7FIiBsazvPOMg192uUp /ONx0Whp+enXi73d2s+HTT8XwaCPXhVKVvX3N0Pp9RTdOemthA/+OLS2eXUUIZ3O9zbnZyUX RK5kfblrwN2NPJe6G5GAxevpKFnbXKxOMuin8pPjeSGQOB4IBgOAKeDggRCvz3+lzotAEIL5 iCDhw24kAqh+MVtxnzfMyc7LuhqnHrJcLvsQxmHgi4diiQzDstl41I95CSrJcEyCDKDuhbhR X3YSQ0YSlfnpvKxzfE0ayf06S+IIGqDZSrv/NHrqVbMkEUkVxf5AEvOJoIt1oW/nebNQaCjW eafUKh1VN21r2ctF8cCD0J9pxt456MNigmaaylLT1otRNUkA/gF0+/k3ZzVRV5azn7VK9aeF trEcZy2mwrHCk2YalvP6upOFNCvOtpvlfLnRx2Uah1yo8cdfn4+2vdsbaiPHCK1et6cYp4PM 32daa0sbyyvnxerzTEW1d4t+e7C0twM2iFyhv//5vtfXS1UqpSgqxeXYx/rMOc3LqcehYSi1 Uk971ttcrmuc7XGjLKr2YVaKoh434V/eTbldr+QzMQL3h2P3CaY2O15W1TQ/NDbD4qO42K2a XEF2XveTdqMztQ6LagyD3GsCLVFMxshwwIsgGEGlchVpfQY8pdjO2lA7zSfdnlUZQb28P88H vcFkrclF6gZ1WyKAoQggEsZJptKWZP10ARQnyqplakvd2gz4VHF6ebMnnabYkbrVTOiasH4x mjR2bS4IC7MtWZYkdXdcVWiSG5in497URqU4zSvOZSMJOTb3mMtQfsSt9Qa9tiWEP9Sn2qRV GxiOVruPZrrb09GY9oR4MJTpmceNlE8lkpls0h3sf0PhQEYydrNWbWiejU6GZiXDsdRWPh7y +ujqfG9PWwJfKJXzcdATKFlZO3o9hl6jwv50z3jWnnqT/aeDXMwWlf3ZGjcfExGfN5Ttantr NR7J41GTcWuNFMbbaYm8Qd2E59Z2psys405tCOLy/H7U5HaZiRF+6rG/3u0sY6upYjaIeBAi 0xyITAi51YqGGVFRR1JfmU2HojgyXt5Ou81K7RXuiUDssT1erldzpZOngSJA3miay5D4TRs8 sDeSypcEPscL5XK9v7L35nqx2prakI/ivmgqX200qoVszB074EyECPyLEHpgLBChyEg4QtKp smJai36j3lHNw7oZ9yFYIEzRNBUhwNzfhAABzXDNFzw8EIxiKIogKE4WJ7YhV1imKOmO0U35 YQhGMGDA/SYxX0Bf357rD8SDhHIjwxg38nx1qB9cwXPPB5v/A/uKv7uD/cnmfLMErTVabLdj gfJ+Te0fXt9dQliEa4/nwJarhVy7CsN3Hf/70QNGIVu+KlNfLCSCH9d2UBbsDdJpjs/zbNIV wR/X+C2+q8KBUDgSDvqxKxvftn68AlQhwMAgfyfk3xd71dwKZW5kc3RyZWFtCmVuZG9iagox ODcgMCBvYmoKMTE5MAplbmRvYmoKMTk0IDAgb2JqCjw8IC9MZW5ndGggMTk1IDAgUiAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQgMjggL0NvbG9y U3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9C aXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVbZ kqJYEC323QVXwB1xX1FULDcUUcoNRcvauh9mOmJi/v8H5mJVdU/HxLxVvkDmzTwk3JPncncH DIIRYDAMec7XGIRgJMNxLE2gXwYLo6Q/mszKGSnM4cjXNAuhdCTbGIwnI62S8OPwV7w9hFCR gm7tnaPzMG0INPIVoDAWkIeb02m/2+9XvQyHfgkoFW+t3YOpa4PRqJ36GlCETQ8dd9nKSkm5 kI16r/9BMG/LIPh3g0AQugUh7/LJw/cQSP2gJcLlJq47K4RZ1s8HGRy+EYxlGRKDQS5GkARO kDRNEQRJeZyDYBQnSRxBUJxiOZbCEfg9BPIomsI9WiJsduQ+LmsxBgeGIe8Ey2QSUR+JIBgb iob5UDyRiIVC0SjPYjCM0cFo2EeRbEhMZ9MCz2AISgUikRAfERMCT6PwHUxL2u7JGZfiHOgD hlE6nK1ruq5V0zyF0dF8tawUG91uLS+XqkqcQVE6KlcUMchLxfZA77cVgcOJQKpUKSgVVWvJ YRK5g/FQyXCfnFkzHQIPQahosb9Y2/bK0GSeDmR7c+N+aKyssdocTPVimCSC+f6km09kWxPL ttfLUU3k2HhtPB/r4+XaaCdYFIJQRmyY7pO7HhTjLE7wytDe2aZpby0tHYyUF+7Jni+s5Vht jex1P+3jJNWy7yvFzmK7sUxr8zCtxPhUf+vuTMNcGWqSQ6E7GOOk+uxwvR5mddHnS3YfTtuJ ps22jlkThfrD6/PDsKOq9UJBs51FNR4pTPcbvdaeO8floKNbzlbPxXOj89vJ0NROS4nd5gfG uXhpYF+e3UVdipeMy+O6V60N7POul000t2/XeTUlivGIUJ45m34+11k7S7Wmg42YNittw3EX 1UR+fHndabIkChHuNumAN3Qo0164L+60mle91vRWa2i7ez2fam5enH7SR1EUySW1jWN21dl+ d1+pTi9vp1mn2Z0f3GUjrYzdR7McZkAa5mmSx2GU8IlV4/y805u68/11O+n3R8uHZSebbNqP diNCeLwmQuX58WAtd0erJVfmz9/Ppt7TZ2t7XE4po+NxlGE9+njqCbhOEBiKMUJz/eTOe+Pj t6e1rrZUra8qotRYn60Kj3nDhbCpwf7per06I0UqzZ+/ObNuq93ta7W0kB8d9oME/SlxMMYE eT9NkEFldr4s+/f7l7PRzGezOTkjhOKN9cksB28qAxOR2urlzx9vm7YUkSeX502/lMvk5Fwy EpHvD9ueRH2CIlQ4o2SFUDBeNs6uoXati2vU06IgJZMxPt5YnRald1AI5bKj619/v84LvC/Z 2z9u+ookiMmUGA7L9/utJv4CZaS6rqvVYn24uez0Unm4cx+GNUUpVUrpmPgv0DuYjLV2f/xw ewmGilTNkzNXS/lCGYxX7D+gCdXc2Mu5tT+f5lVJqswOp81iPJpM+iVJrC8PRjHwLrIQ5s9P z9dlJURgXEqzT4fVdDSejlpZQdY3dkf42SlMRSuTzfF0cs8Hs53w+8W6sTs6ezAuw5IQK40t Pef7UG6YijcNs5sEu0zw8mB9PB52W9top6NpdWE0YuTnN/UGqjqYr2x7eV9P+gkCuPpitbLm ei0RDCYb3arIfJwxoNVUrZ7jCaCPVEjuTK31ypx0lWggVlBbuSDuSbBnEIJz0XSx3mxUcjEf EEeMjWbKjWa9nBP8FBWUUoKf+OwAIQNxT9wgUEYGJaXWbNYKKcB5LppMhL34hwGFJdlAOBLm OeqmyyjJBT3XRwGhJBiOIX6e22ACaIYEgnlrhvGHgIoGWAJFgF6zoPoT01uHEcwT6I9fCfAU DCc8F0g6mDag7D+TgQ/+ZG4uqEI9XffWvfvf8t4LwJHzqxQcQ//2fkJ6N7+t/F/eP/t759kK ZW5kc3RyZWFtCmVuZG9iagoxOTUgMCBvYmoKMTQwOAplbmRvYmoKMTk2IDAgb2JqCjw8IC9M ZW5ndGggMTk3IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE2 MCAvSGVpZ2h0IDM0IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAv SW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4Ab1YZ5viOBJubIxtwBhjskk2Tc6YZHLGZJvQdPfMzszu7N3sc8/9 /89Xgqabntt092H0ASRVSXpVpXpV8t3duRgwKIab6m39onL9BVX8XK4DroI//b8scJn1TxV/ V2jACZIkcDQcqhRNGs9gz90mHLsZY8CMJtpihWIBrfOIG+kfVtFMlOky6x8q/aHAgJMMZ7cQ AASqNpeHP9fvMMJsd7C08WbbBpy2e0OiKEZCfhdLEy9G/8OpLwK0AO+0v5vpL4bcijET6wsH HBSYAyNswXQh7rUgUBhpD4hBB31jJsxkD+eVTqfdUiq5qIcx3Rr3ds53dYPR6oslQhz5t7Tf DYUGRjD+RCbqpPG7O9zsLYzmnQSPpsJIPprPRRw302KUJz/eHffaZrOatbMCg4z+lwUzOeL1 Vs5nhhX+52LAzZ6kXIoiGAbCft8/fdIbQQsypomTZKUQsr2BwM2Buv7pp+NmtdkdtWHOizb1 lwUj3fmxWg9Z/47y97NhpOO+0iwGGXApRnlLm1//9XmacoDnwC2BYreVvQGBW0Ktw6eHqVJV xtrjrntvJ25O5/dTX9swbXm+aYvM/4EPQARLvVbaTSFANrFz+u3fv+pVAfkCI53J9kgBEFcv 4pZw6/C0kCUhnBvsnxYFN4UD0RjuDC8MgojqUlDnhYswwCcvtx3JRuA4UoY4PEteKOqqdtmp 4cxfr4EHGFLdiSKxYAiMdOVmz798/fk0iCPDGIxMuD4bF32vXkT4dsdhgrcwgrx+1upBhj4T B/AOBRSFeIQ0kZTZTBE44iIrw1gok9knL7Ve3MlYLdAPezGSZitjNZ8pB8jnooYkiN+Av0Dt BSF4rKZOZcEM5sOtocbmdNydHpdlH40ihPIWp8t2lL1yzAXfIGYnaU9h+bxrim6XC4gDM9J2 F89QpJV3Ox28NyC4bRRpcfjCkhTy2Fm/vNyNC1IoFHCzlBE3WXkhIkUERGSYkbJ7w5IYcDEk bIli3cFIJADDz7RhILjkYDPJuUgUD47UaK+Ne+pB70aRQQ2EIzXcTvOuawgjfPvTJOO182J9 +7xtxMR4EogDJ7lwMuazMZ77TCqWyFfkdJDnhUS52WnXsyFPqLJ+WHerlVo1J/I0xfiTcrPT qiR8DGGknVKh0WpWUoKNJMxOMVdVlGomfOE1FBELfZiwg4Vws1BZ7adyVlkfVThZYECckTra ug7hfDnrgK99/LhtZeLp2uz4MCvFsg1EHEazP9+qx1y8VBsOWs3BbNrKiPel/ny9WavtTEis bj+elqPhVB3XojzrTbVm66226mW9Fsou1Wfr9WLcSLgtFneiPlLn89mgeiaUO3BvU9t1JQgt IJdYf693E5Hc5Ki3IueANgcVbd+P2oxv+E6/fNyM+qPl/rhsxKXymTgIa7ihjnI+DzhgNx+O ptNOOV+baPpKnY7buYhU0z9/WA86o5U+l8PucHmgLla7B60T4xhvUT0e1tOBkvaxzlhzvp6P x/PVtBpmwINGW2x43DVDYCBkytWT3o5HMsOHJzXrBKdilK+6Pc3SHPGKr/P07R8f9pq+09RG zBeunInDBHbezEuCL7f48LRoymW5VKxNdH2mlPL5jCREatpPx1EpXRrqu35SCGdr9aoyOZzm BS8XqG2fdqN6MRNxOYKVxW7VrVb7K22cRafKyKVmj3pdoDEIVql7+vlxXCnU5x9/PiDMBmDW 8uZ5VXCaLsGP/Pv4z6+Pm/ls1C6KTruAiENkAF93uygHfPnVx9MwE/ILkXRrs1dl0evyeHg+ WN08LuWwJyQv4egEfKGoKCaUzeO2GuCEyuZJ7xfuAy7WGR8cH9RaJtuYH9a1AHAc4cgtnrWq l8IQuSy/fPuyUyeL49ffPs0QRxtMzsL6w7bshvBBBeF7+HKaNoq5pORjaQsQx3t8S0Q6Ntrq jPf0bVuyUyRJUVY/HOxRkjfzqfF+URY4h9sbiDXWT3BT2V2Z8f6gNpICx7hzczC/Uiw25/uN Eob7huDzqw+a7CExOInK4ddvXx73+v7pl29f9Rri6Iu84qVe8Z35WfQ4OYYmjBfivbXf/GGO wp2wxwe7VQVYCrEvjfivG7WZbPc9fSn7WbsnnCj29Q97JWSzBeWZrqvNlNfhL28+fVh16/X2 ZDGRUVSe19/KbhLIJTl++vykLWaz2VJ//nzh6N/Bd+Zn2gT8iy6GMiwsgX+jXQ35N6cepmkH cWdkAd+yDPsGq4Paq5k72lIOOH3xYlUZas87JWSlObE82uxWnZQQqmx/elSVcrFcrZdjLrgW wL/L563sJXGzv7I+6cNKPpvN5muj3QlxNH7xL7Lv1b+t3eE1njHSU17o/RhLsbGBvjzj241T nBHiDiy1aQStcKfgRmS/yzEQO9tlVQyllW6z1pofNSXEUFZXpNDbHDetRFRePh8GhXtRlKIR Hws5gJFLzx61qo822WO93a6fFpw8z7sC2eFO7wBHk+7S5nldvIkPwNeL2i58aDC5CvP9JOtm vbnZcS2D/Wa7URLwodOy3Q+zPhbl2jahcoOvFk811ZmSLw33ekvkGM4tREuT42lWvM+Pj/tB Luz3CcGgx4bwscAvWiNgMXuK88O85LOYCIIwWQV5cQCOpmlvZfuoZsBjN/Z7w0c40pP9SolH Ei0d3PCGDxLFwuyw7RViEUi13eHqDb56qjjerZq50uhwGKT83nA8kS6Pjs/LshhT1vtFMxuL JdPJMGTMd7g10tL0dsRmCzfWWvce3WqQXgBV9+DeCDHWQEM7DGJv/Axm0TuIzs/FaJNaG11t VZvq6eO6JHizk+0ALiOYgZWU1V6bdpuNSiosVdQVMD7BRFortZosjA/asKaoj09qORrNNdrt /urhYZL1+9P97W456rS73XrSDecPO4dWP+ZwSIqKMpWXc2b2l8YzReTscL9tFUTf54KZ/eWp WnvNNHHak+2v1upoNNd344zXnehMFQl2Y8ApV6K10LTNUu2XpEi+P64ELIQlUBn3C1Kiudqq vZ66P85ryXipN1uu9d2iHuFYf26w1rXNajltJl0ABjKA9GgzzrgdoUK9FLmYDyLOZBdL9XyQ cyaH21kBwvsFH+mMV2op98s2YDgjZJuDQUdpttuy6LAH85WMH+3GYDS7Y3JvMp0OGumAL1qU Ey7aSLsSclHy+lNKv6fUmoNxpyCG4nJ3DGrVe54mGSGjjGaz6VDJBtD5M+BMpDGflgOcMxAR OPD4ucD2OSEScLK+wmTVefE6SDDC6g6FvW/PDszEeMRkOhEVJSnIW8ycEPKxF1Ix0pxwn8nn 01EfxzoDQQ9D4ATjCQacjM0tJlNxKRpPxYNOzh1K5Aq5BLzEjDjMH0nlC7kUsD+JMiw4yLnB rCFxVsZmOfe8ACQtNsbChqqTUdH/mp8aMIJmGLPp9UmHOmwO3sEyNpuVIoykhbnOYsBNZpZ3 uXjWQkKiCtkojrqsoGZCYziW5RzA8iRt5ZxuJ2eF9A8yV4rhnC6nw0a/PMgJm1gbdtIuuA1A fjEf/EKabSQoPt4cNu651/z+3P3feibCiApibPxNep7CZDKhfhxJUcZ/rqC50RigCiSEBon4 /hyaLy3j9fsERrlSzU4xYL3myG8QcYsv12pmPK/mexW9r0Ba/r7jrQWi35ed+69CpPWm9q5x fqXl6vIlHXybGGpwiUZQkNy8L9/Jf1ADfRPI5u9dKF9+V+DlKeWy797n7+Q/qAGx6ghKIQd1 c/rOS2MkB983+NvvGz8I0vtlACDLO6zANu8LRlg4/v33ofcKP6qF4SaKeuOM67LoLQrd38O+ in/gP8ohv/cuLA/d1yj/gWBul/oPfwLdxQplbmRzdHJlYW0KZW5kb2JqCjE5NyAwIG9iagoy ODczCmVuZG9iagoyMDEgMCBvYmoKPDwgL0xlbmd0aCAyMDIgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AY1Ty07jQBC8z1fUcUZanOmJn8dNtLuCAwhsicNmD8ZxIq+w A7EB8UH8Jz0eR7GBSNiHsnv6Ud1d84hrPELDaJA2PqIwxr7ELRrMli2haEFoi88eG2gv1P2D yvoawb66f7/2t4VIawRRiJhLUWJGpYwrRX05Mc7NUX3WMz7jcMuwqLHIEPvOzkh+4EUmDEEm QFZj9ps87gjZRsjl1U2KtCibfF/tFLL/+JVx1wc6xK1bOn6gT9E5tioq28SYThDpgU5EXmzc kfs0CY+VPDKRP+UE+abEgcfJfP6QjJETUMLdjBvDX8hzvORNh26H+7JDWnUllEgSyJ9YybzB 00Oxq6tmi1LxiCCfGfi0bLoWCv+QXbhZnOIgphyMrz9zaKt1uVLI1wqceo0ivy+bdb7/qiYT 7UkumF6txJwpvX6LCD4QiZMpESEPZVdqumLtzQeVpktezgedp5j9YZVv26PaBavXYA7ixVJg JbHptTK1jS+IthdkNEIDGiQqaNghYwAaNmgGadoNZgpnMeQTg12Mg9YBT9QacwtCvrq/Hwwc wFOzcOmMLGvryesdZand393EuFfCugzhc3c2zWmcUU8gGcvl+h2mCuveCmVuZHN0cmVhbQpl bmRvYmoKMjAyIDAgb2JqCjQ1NwplbmRvYmoKMjAwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgMTU5IDAgUiAvUmVzb3VyY2VzIDIwMyAwIFIgL0NvbnRlbnRzIDIwMSAwIFIgL01l ZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iagoyMDMgMCBvYmoKPDwgL1Byb2NTZXQg WyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+ IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0Yy LjAgMTEgMCBSID4+ID4+CmVuZG9iagoyMDYgMCBvYmoKPDwgL0xlbmd0aCAyMDcgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AW2QQU+DQBCF7/sr3hESCztDKfRqoyYe TLSbeDA9KILpgRrAmvjvnd0hhlXh8DKzO+/tNwPuMcCCLcjyGtWmxtjiESfku4nQTCBMzd8b HWy2seHD0d9lI3dt+P+/74PIWpTVBrVE0ZYXUaxRFOLM0lumgutKzmTcv7DpcelQr7UvSlWZ VSWIS7ge+TVlwgPX4ckkD+1wPo6p5CFp+/b0MaU4wN3iygl8wM+KmWS/E8tfu9gjv5FNvE0m 2gijkFiJKT1FF4zi3nKJ1i9xQcKg2igG8YzHEAJ5tQfgHwAkLsWqRnIW8QgqAuGrV5Xn1Pjq S6sLERmAyp0231U+VWaXXquXqDmq2Txe6Fnsydq0kWyjvX4DTWF++QplbmRzdHJlYW0KZW5k b2JqCjIwNyAwIG9iagoyODEKZW5kb2JqCjIwNSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFy ZW50IDE1OSAwIFIgL1Jlc291cmNlcyAyMDggMCBSIC9Db250ZW50cyAyMDYgMCBSIC9NZWRp YUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKMjA4IDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAv RXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4w IDExIDAgUiA+PiA+PgplbmRvYmoKMjExIDAgb2JqCjw8IC9MZW5ndGggMjEyIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdUkFOwzAQvPsVc0ykNrXduE6vVFCJAxI0 EgfEoYQUpVJSGrdIPIh/svamJSmcSA4Tb7yzszu7xz32kNASSuoUdpahLfGIBpOFUygcFFzx +8YGMpnJ8KDyd7WguzK8f9/3hZSUMHaGjEqpue6V0lxKhXKiz01ZgXVM/yjdKyxqXOXIUo4T KmsSa6C0QV5jcqMS6gf5Bk8ieij3x6qNqR6isi6bg4vxjPwW1zk1f1KlaAJeVWrkf1QZKztV ViWZZmH8qecwJlHapvosTgRx0VeMfMs6Lrr84aMsP9UxofXyzhzcYLRs180B72VbV85Vuwbb oztg1xRlLE7kweNk2tm1WhDfheErTJZk95sb2q4xpdnSLI2grdiEaf3EeoMKmyL9pvQa0VAn r1TXBSHZpERwSZ9dQpTHGGeIjgTeJwZyyp9eGdYMnwwjAkpALDzccXDH8MHQsdR8ehkEaSE8 NQgofcqnEZN1Qc1BOYD5YHm+AYvXs20KZW5kc3RyZWFtCmVuZG9iagoyMTIgMCBvYmoKMzc0 CmVuZG9iagoyMTAgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAxNTkgMCBSIC9SZXNv dXJjZXMgMjEzIDAgUiAvQ29udGVudHMgMjExIDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4 OF0gPj4KZW5kb2JqCjIxMyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3Mx IDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5k b2JqCjIxNSAwIG9iago8PCAvTGVuZ3RoIDIxNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBnVNNT9tAEL3vr3hHr0Sc3Y0361yLAIkDUoulHlAPxmwqI2wnWYeKH9T/ 2VmPCTYgVcI5PGc8H29m3uzxHXsoGAWtTAa3znHw+IkWy/OgUQVohOqjxxYqXavhQR19jSBf Nfw+94+FtFKwbo2cSumNmZQyXEoP5cQ0N0UNWRf0jcIjw6rBtwJ5xnZC7WzqLLSxKBosL3VK /aDY4k4kP/z+WB8k1UPiG9/2QeIXimtcFNT8KytNE4isMqu+wso6NbJyOs0NE+NXs4G1qTYu MydyYiCX/JUoHpnHuy7f8lFUnOqC0EV6pxzcYHJ1KNseO39o6hDqrsXjMfTo2spL8d/kn5HV Jh/YzguJL5DVOp8nwR2Smw5N2UpB2ziWTwi93wX0HapuJ7HKkLzgoexL3Pv+z7g032K6so+j EiyI+aj02r2rnoS697T917EM0k9Xo4pvz2nMkzsQdAe3WF7RFfwO82swWJHkSGI2amU7iGhu mx6QEnQQE9IGNBdmrMflEpJ6SRRRvOYkXiSFxCKnSRFE+UoRgVqI8MBQMrwwnBFQAA0swg0b O4ZnBs/QcLL7mZHuJKYew1f8b57TsFHNYCPF5Kb+ASwh8qYKZW5kc3RyZWFtCmVuZG9iagoy MTYgMCBvYmoKNDU3CmVuZG9iagoyMTQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAx NTkgMCBSIC9SZXNvdXJjZXMgMjE3IDAgUiAvQ29udGVudHMgMjE1IDAgUiAvTWVkaWFCb3gK WzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjIxNyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdT dGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAw IFIgPj4gPj4KZW5kb2JqCjIxOSAwIG9iago8PCAvTGVuZ3RoIDIyMCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnVTBbtswDL3rK97RAhpHUqzYObbFVqyHAl1dbEC7 g+sohYvYTiJnQz9oP7T90CjLS+3UaIE6B0Y0RT4+8nmLa2whoASkUBHieYKdwTdUmJ5bidxC wuavI1YQ4Vy0DwoXqxjFivY3Hu8KSSGg4zkSKiUXqldK+VKyLcf6uelWm3VC7+i6Q5iXOEuR RN5PVsY6jDWk0khLTD/LkPpBusIdC76a7b7YcaqHwJSmaizHD6SX+JRS8/9RSWLAoYq0+Agq HYsOVSzDRHlg/q9aQOtQqjhSB3CsBRf85kifPI6jLl/y0S3H6oRs7OAdcvgGg4tdVjXYmF1Z WFvUFZ72tkFd5Yazd5OPgZUqadEOC7EPgJUyGSbBHYKrGmVWcUbT2Gdr2MZsLJoaeb3hmEUI nrHMmgwPpvnVDc1U6I/sNVXML8SQKjmPj6oHtmgMTf9NWhht1hgtSosRWvA2LaPAVCSOgBEt f04vT7//xe0X3AeZJ+Knb78ulljt12tsskeDdZ0t7T3nbLjCIpx1Yrw5p205kvMNphck5kc7 FLXCjJRDStGMNL9qtfDi68mg/Q4I9x3oca9A4/XEy25HyZIIJWs1qA4aRJByTBIaOBmnQm9o Eu609Iaadqdnb07I0AVw5syVd9beEC+9LKU/PQycJHcXQmvjrs/86cQn65zKO8XALPp7dv0P 2EIgXAplbmRzdHJlYW0KZW5kb2JqCjIyMCAwIG9iago1MjIKZW5kb2JqCjIxOCAwIG9iago8 PCAvVHlwZSAvUGFnZSAvUGFyZW50IDE1OSAwIFIgL1Jlc291cmNlcyAyMjEgMCBSIC9Db250 ZW50cyAyMTkgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKMjIxIDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIgL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8 IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKMjIzIDAgb2JqCjw8IC9M ZW5ndGggMjI0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdVMFum0AQ ve9XvCNIAe8uYPAxjdqoOURKQ9RKSQ8EryMiA7YXt8oH9YfaH+osS23AyJViH8Y73p1582bm bXGHLTgkh+AyRDxPsFP4igqzKy2Qawjo/PTGCtyf8/aDwtyVjO7y9jt93yQSnCOK50golVjI XippU4k2HevHpldtVI/+o+cGYV7iQ4oktH6yIo78OIKQEdISs0/Cp3qQrvDInC9quy92LuWD o0pVNdrFd6Q3+JhS8f9QCWLAoAoj/h5UUcw7VLHwE2mB2Z9ygSjyhYxDeQDHWnDOLxfpq8Ux qvIYj14ZVj2ysYF3iGELdK53WdVgo3ZloXVRV3jd6wZ1lSuX/Tf4FFghkxbtMBF7B1ghkmEQ PMK5rVFmlcuoG/tsDd2ojUZTI683LoIQzhuWWZPhWTU/u6apCv2WnVLF7EAMqRLzeJTd0UWj qPtnaWE0WVO0yIhP0ILztEwCkyEfASNafl/eXH77g4fPeHIyS8QPW35dLLHar9fYZC8K6zpb 6ifXZccRPuXjzCgGMhiXwWhPzpfRxRvyG4hgXAYz3dWKls0LOJyuAHOOqd1eU3sTf1Lny9KF mYeqyLOGZpi6zfoLyv2gk5r7K9qFkVjdY3ZNUvWih5IlEZAukA5EjBRt1W760ddb8lbluFG5 HpMSNLx2rES3gWRJYgRrFUYeFAZOSvUmBJ+M0RhraM7MaWkNtdSc3qy5IEMP4DJjbq2ztoZI 60UhYszpeeA0/JKTlsI8D+zpwgbrnNI6+cAs+lt09xdrmVJXCmVuZHN0cmVhbQplbmRvYmoK MjI0IDAgb2JqCjU4NQplbmRvYmoKMjIyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQg MTU5IDAgUiAvUmVzb3VyY2VzIDIyNSAwIFIgL0NvbnRlbnRzIDIyMyAwIFIgL01lZGlhQm94 ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iagoyMjUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9FeHRH U3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEg MCBSID4+ID4+CmVuZG9iagoyMjcgMCBvYmoKPDwgL0xlbmd0aCAyMjggMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZ1Vy27bMBC88yvmKAGxQ1KWJR+ToA2SQ9CHixZI epBtOlVgSY4kt8gH9YfaH+pQVBJJMRw0NuA1KXJ3dnd2dI+PuIeEllBSTxBNY5QGX5Hj+KxS WFZQqJYvT6whx1PZfJDas1rwrGy++8/bQEpKhNEUMUOpme6E0i6UasKJrm/earyO+IzXLcJl htM54onbp1VROI5CKB1inuH4vRozH8zXuBbeJ3O/S0uf8eCZzOR15eM75pd4N2fyj6gUK2BR TUL5FlRhJFtUkRrH2gFzf/UMYThWOproJ3CiAef99jG/czgGWT774y1b1RFtZOE9+XAJeudl ktfYmjJLqyotctztqhpFvjS+eNX5PrBKxw3afiDxBrBKxX0nuIZ3VSBLcl+wG7tkg6o22wp1 gWWx9RFM4D1gldQJFqb+1TbN5Oi27GWphCNEv1RqGg2ie1VaG3b/YFkEmbWvLDqUe8qCw2XZ C0xP5AAYy/Ln5PLk2198ucCNl7hC/HTpF+kK691mg21ya7ApklV14/vimcIv63GAioEOhmkI zsnhNFp//foGKhimIWx3K8NhGwUSXpuAXUds96guRnsesvNZ5sPyIU+XSU0Os9vicUD/L7vZ dJgdVeAt3A3i6TC7hru5MWxHQ9+ixLZM+btIN0ltSrI5YapMhCN520jNK7x1dRX9uk6C4YyT HsNpmDHKCZJ8hdMjhuTKzf12t9ik1Q9iJER75sNFd3QasR8HrW5/PqOwDJT/M47Pqfu3VU// hUZAkaWohlYd141s9ve6rwxpXxmdxmlQCdyMqlbOaKnXSjRyrZ/kGt6c5InJBRriN85waO1q 5Qznw64enGH+9gITtubKbRbOkIEdL2SZXS16m5as3GSn7PXArY6cs3ZTu03ZM7NeXf8BfhKg dwplbmRzdHJlYW0KZW5kb2JqCjIyOCAwIG9iago2ODAKZW5kb2JqCjIyNiAwIG9iago8PCAv VHlwZSAvUGFnZSAvUGFyZW50IDE1OSAwIFIgL1Jlc291cmNlcyAyMjkgMCBSIC9Db250ZW50 cyAyMjcgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKMjI5IDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIg L0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9G MS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKMjMyIDAgb2JqCjw8IC9MZW5n dGggMjMzIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWMty20YQvOMr 5khWRdC+d+GbRNuppOxENlmVg50DTYMWEz5sgYrK/5n8T3p2AQogSEq246pIB5BL7GNmert7 9xO9ok8kSAmSQhnyLtBNSb/Rms5HlaRZRZKqWf+NOYncifhHC35XZXhXxP/D7/NEUghytqCg ND4XralUmkrG6bL22OgVRz3Db+jOK5yt6HJCwaR2PGVhciGNo6BpsqLz5zJHQDSZZ29oMPr1 9fjJkIqCBvRi82GxHtLvNPmZnk0Q/NHw20vohJdbIQsnAqdFCUXaYioVmnjmpOiODL2MSaHR GOvg//GI428iQRwhZIgjjqCK9gjjelnnFxdXL56Mt5+XJZ1fLSVdPh3F9bZ+GG3W23K9zS5f 1j9dlTez8uP2drqkmwXPKF2cUxtMFcgI1BQJ+mmlPT3d1DM9q3t3cJAdwkErBCU0GdsUQ6fS n+HpcksoxX0dssmcUIe3g4u3w6YCUqEa+4Vo1tEK8OsjB8x4TRw4YtXONYGH7xW4trl21isK gF6NwoxRSIOr6YdySJM/7kHXxNrJebMh9sHHm0NkCKcNPmcNWYUmWpEHAA2AuKQASKbWZWy1 hUTrNbbd/dvz7NEY5aRxV+X8biKtQz1RbM3SRLLwu4mat/9TKAcbC4pIXXBkpW4KWnxjQWNq kKZEKy0k68Qqnvw9raSCAs7j8mZIjPfBX0MQEA3idym/ANfZ8R1NR3e08ikNWJU0ZHxRp8GI 7PSGbsDVIfbWhu6kIWulwem8KCx2rASDNMAGlzGwLx6B6oZJDqK6hWnRUKpFOo9SanaKUjkX TKnSdUj5GA6/qgCcBWYWAFEBhDZyYAZKNfIBID5UAaZUpzzrAvStVQEpc+k1xM2ZvQIAiJfA IaR7sIHG0eCuYhzWApclgTvJNbaWq1516jyLKF2APccMEY7SxXl21uWaTYMyRa6D8eAhZ3Ue FNSd24QrFChBa4maeGAIErykMRbFgtoIfqy6Mz43HrtaFbmxoG4M5TCCgF5Z0PcSI4tcWCTI YmQMnNrSbJnVIS+0qAmoP9Y8SnDtZKIsNtEY6XJTcGaFAcHNVhkyr+pg8eRGhLOH+mgjiEmd Xpefbstqe78NdnnMOhPt0qaNyZUPMA4e+QvKIVZtXO6802iz/IEp28HoKChJypiM3gGWQ5uQ uwDMGaVz5MJwd62g7EzK2hrkD8sW2LOx825oI1WulS5A19cHRzmeJM2VVh4CIjhFDM5eirJT Kao+btZVSwB3OYJ3ZFjt61qmCgSHyFjXGE5J11JrkhuNrdDoWvN28l6cqqN+i0kOSdsNbp2t B0+taXADVDeDN28f4JDsAVt2nMS7WqaC4z3PFKK+kUI4PqSmTyGHtAxpStbslJZlXbPccMkX eLQmDUjXnjvtapmyIIWUBv1AGhpJOaVljJAE1haTHtSy2qQ9RssaCj/Gmo06JdaMm3afNQE+ 6JvxOodKKWY6q3IRICXGKxyqrAP2tNaZLoodacKpHyBNkwewJZQCnjuAKpk14XUh1eAPZmWP UbUCxXnpsfF3M2kJr1qYGuVgpP1xjpOBwWpxVoTHFxG1XTLQWIkrcLTrkSaUKtHmc9gllqub FY1v360WVbXYrIctmLU8SXuyw8wD2ekyz5sMJ40ZzkXTxbqiW8jheroC95zhjDv4oT4HfpxW VZLL5N020Exe1Pu3w5140qvOObTHU9FnYMP2nMpJAuJerGitXgeY5euPPXsHPlk0NhnFPu0P H9pT7E4Uzhj9PQU2/R8c+HD+4BpFW4b8pt3PnGq/V+DwDt4pSGH/wDe+nc1Kxtijz3w9RoF/ iFu+48MOMAorvNbgTtzHgAaYUdgkeIOKW6YQaSzvfZyA2cTDTxwiE1xjwEKBeyS6KM9mTuPs LHG7wraCrQrubDy8l/RMJbspZAhgL7BQ9BX9UU4wiVB54IUrUdSC1bMV+5ubBq/L5CbobrG9 xhUC3+v8PS63Z6PN5s9F+Q9dl9P38MCHCSXgwCwCkKwxVUJya07+URV83G1bPr6/wHEv8dSu oC2WOj0om40WS9Vi86zaTt8tF9V1+b4LEgFTne7VcGXUux0Y0/mPuJf7UDE2JN+5RVcLN4ni 4MxjWaDm8Zqo29a+0ouWu7V+cFi8jAKVAyC8ic7wtLg8SumHPO2swgRMGmhwiwefedMDOOdv iIQf02HGj8/pGyiXO6BS/PglNeKswq/g5MyPepRV+vau04hC8it1d51+646pUqPoPIoWj9Or fwH2ubr+CmVuZHN0cmVhbQplbmRvYmoKMjMzIDAgb2JqCjE2OTIKZW5kb2JqCjIzMCAwIG9i ago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDIzMSAwIFIgL1Jlc291cmNlcyAyMzQgMCBSIC9D b250ZW50cyAyMzIgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKMjM0 IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdl SSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIKL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRl IDw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUgo+ PiAvWE9iamVjdCA8PCAvSW0zOSAyMzkgMCBSIC9JbTQyIDI0NSAwIFIgL0ltNDEgMjQzIDAg UiAvSW00MyAyNDcgMCBSIC9JbTM4CjIzNyAwIFIgL0ltMzcgMjM1IDAgUiAvSW00NSAyNTEg MCBSIC9JbTQ0IDI0OSAwIFIgL0ltNDAgMjQxIDAgUiA+PiAvUHJvcGVydGllcwo8PCAvUGwx IDQwIDAgUiA+PiA+PgplbmRvYmoKMjM5IDAgb2JqCjw8IC9MZW5ndGggMjQwIDAgUiAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQgMjggL0NvbG9y U3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDI1NCAwIFIgL0JpdHNQZXJD b21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt0AENAAAAwqD3 T20ON4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMDA08AAG+QAAQplbmRzdHJlYW0K ZW5kb2JqCjI0MCAwIG9iago1NQplbmRvYmoKMjQ1IDAgb2JqCjw8IC9MZW5ndGggMjQ2IDAg UiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQgMjgg L0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDI1NiAwIFIgL0Jp dHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt0AEN AAAAwqD3T20ON4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMDA08AAG+QAAQplbmRz dHJlYW0KZW5kb2JqCjI0NiAwIG9iago1NQplbmRvYmoKMjQzIDAgb2JqCjw8IC9MZW5ndGgg MjQ0IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEwOCAvSGVp Z2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAyNTgg MCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFt CngB7dCBAAAAAMOg+VNf4QCFUGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAwDswI3AAAQplbmRzdHJlYW0KZW5kb2JqCjI0NCAwIG9iago2MwplbmRvYmoKMjQ3IDAg b2JqCjw8IC9MZW5ndGggMjQ4IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRy dWUgL1NNYXNrIDI2MCAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURl Y29kZQo+PgpzdHJlYW0KeAFjYBgFoyEwGgKjITAaAqMhMBoCoyEwYCEAAAiLAAEKZW5kc3Ry ZWFtCmVuZG9iagoyNDggMCBvYmoKMzIKZW5kb2JqCjIzNyAwIG9iago8PCAvTGVuZ3RoIDIz OCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0 IDM0IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAyNjIgMCBS IC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB 7dAxAQAAAMKg9U9tCU+IQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgz8BwYXggABCmVuZHN0 cmVhbQplbmRvYmoKMjM4IDAgb2JqCjUwCmVuZG9iagoyMzUgMCBvYmoKPDwgL0xlbmd0aCAy MzYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTE2IC9IZWln aHQgMzQgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDI2NCAw IFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eAHt0AENAAAAwqD3T20PBxEoDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYOB5YC44AAEKZW5kc3RyZWFtCmVuZG9iagoyMzYgMCBvYmoKNzQKZW5k b2JqCjI1MSAwIG9iago8PCAvTGVuZ3RoIDI1MiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA5NyAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRl cnBvbGF0ZSB0cnVlIC9TTWFzayAyNjYgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9tDQ+IQGHAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAgAEDBgw8Dgwf1AABCmVuZHN0cmVhbQplbmRvYmoKMjUyIDAg b2JqCjU5CmVuZG9iagoyNDkgMCBvYmoKPDwgL0xlbmd0aCAyNTAgMCBSIC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTE2IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UK OCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDI2OCAwIFIgL0JpdHNQZXJDb21wb25l bnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt0AENAAAAwqD3T20PBxEo DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYOB5YC44 AAEKZW5kc3RyZWFtCmVuZG9iagoyNTAgMCBvYmoKNzQKZW5kb2JqCjI0MSAwIG9iago8PCAv TGVuZ3RoIDI0MiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy NyAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFz ayAyNzAgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITAaAqMhMGAhAAAIiwABCmVuZHN0cmVhbQplbmRv YmoKMjQyIDAgb2JqCjMyCmVuZG9iagoyNTYgMCBvYmoKPDwgL0xlbmd0aCAyNTcgMCBSIC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29s b3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUg L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGt VtmSolgQLfbdBVfAHXFfUVQsNxRRyg1Fy9q6H2Y6YmL+/wfmYlV1T8fEvFW+QObNPCTck+dy dwcMghFgMAx5ztcYhGAkw3EsTaBfBgujpD+azMoZKczhyNc0C6F0JNsYjCcjrZLw4/BXvD2E UJGCbu2do/MwbQg08hWgMBaQh5vTab/b71e9DId+CSgVb63dg6lrg9GonfoaUIRNDx132cpK SbmQjXqv/0Ewb8sg+HeDQBC6BSHv8snD9xBI/aAlwuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQ BE6QNE0RBEl5nINgFCdJHEFQnGI5lsIR+D0E8iiawj1aImx25D4uazEGB4Yh7wTLZBJRH4kg GBuKhvlQPJGIhULRKM9iMIzRwWjYR5FsSExn0wLPYAhKBSKREB8REwJPo/AdTEva7skZl+Ic 6AOGUTqcrWu6rlXTPIXR0Xy1rBQb3W4tL5eqSpxBUToqVxQxyEvF9kDvtxWBw4lAqlQpKBVV a8lhErmD8VDJcJ+cWTMdAg9BqGixv1jb9srQZJ4OZHtz435orKyx2hxM9WKYJIL5/qSbT2Rb E8u218tRTeTYeG08H+vj5dpoJ1gUglBGbJjuk7seFOMsTvDK0N7ZpmlvLS0djJQX7smeL6zl WG2N7HU/7eMk1bLvK8XOYruxTGvzMK3E+FR/6+5Mw1wZapJDoTsY46T67HC9HmZ10edLdh9O 24mmzbaOWROF+sPr88Owo6r1QkGznUU1HilM9xu91p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3m B8a5eGlgX57dRV2Kl4zL47pXrQ3s866XTTS3b9d5NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23D cRfVRH58ed1psiQKEe426YA3dCjTXrgv7rSaV73W9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV 2X53X6lOL2+nWafZnR/cZSOtjN1HsxxmQBrmaZLHYZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts 2o92I0J4vCZC5fnxYC13R6slV+bP38+m3tNna3tcTimj43GUYT36eOoJuE4QGIoxQnP95M57 4+O3p7WutlStryqi1FifrQqPecOFsKnB/ul6vTojRSrNn785s26r3e1rtbSQHx32gwT9KXEw xgR5P02QQWV2viz79/uXs9HMZ7M5OSOE4o31ySwHbyoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+Tk XDISke8P255EfYIiVDijZIVQMF42zq6hdq2La9TToiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8 L9nbP276iiSIyZQYDsv3+60m/gJlpLquq9Vifbi57PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ/ /HB7CYaKVM2TM1dL+UIZjFfsP6AJ1dzYy7m1P5/mVUmqzA6nzWI8mkz6JUmsLw9GMfAushDm z0/P12UlRGBcSrNPh9V0NJ6OWllB1jd2R/jZKUxFK5PN8XRyzweznfD7xbqxOzp7MC7DkhAr jS095/tQbpiKNw2zmwS7TPDyYH08HnZb22ino2l1YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1 suZ6LREMJhvdqsh8nDGg1VStnuMJoI9USO5MrfXKnHSVaCBWUFu5IO5JsGcQgnPRdLHebFRy MR8QR4yNZsqNZr2cE/wUFZRSgp/47AAhA3FP3CBQRgYlpdZs1gopwHkumkyEvfiHAYUl2UA4 EuY56qbLKMkFPddHAaEkGI4hfp7bYAJohgSCeWuG8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J 8BQMJzwXSDqYNqDsP5OBD/5kbi6oQj1d99a9+9/y3gvAkfOrFBxD//Z+Qno3v638X94/+3vn 2QplbmRzdHJlYW0KZW5kb2JqCjI1NyAwIG9iagoxNDA4CmVuZG9iagoyNzAgMCBvYmoKPDwg L0xlbmd0aCAyNzEgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MjcgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0g L0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAFlkm1T2kAUhdndvJKYopGKDdBgLVYbiako0BakEE0AcdgkNMTp CAgzOI7//3MXMSHqfkl2k3P3POfeRCJcAJIFQLiNPQGiOZ6l4PtvALFSekcWaBj7ffUKaSl3 pBczAvVOhpIZvd2pH8jsWxmgU/tN/w5XcwJ6I4NcxriZP46vDreY1zJASYW6//A0x2dKEr0y Atn0sXV7P5v6f4opOl4RIDFfvfGHjj/q/djl4xUhs3XYdgfmhe3hxpcPcRlKKuVr9+pUq/WH tv6RW8uI869NFzcO1OPLIf6lbqyxl86vA/y7qH5v/Q1sbTvCBtTGXsOfjsyyXun8m3o/8xH2 0nlvspg49mV3OHu4syJsgIR8zZsvJiMXu8H9YobPQ2zi/JsZjINB17KsHr4dr7FR8lO57+NW uaRpWum87fgh9tL5heM0j5RtWZbTWa3l4PoKG3I7Jx2vY+wKDE3TjKicdr0XbCR+rvYHjf1V PM81Bv1KXkQJ0o69mm2ehKGSmw3TqhUkChDenF4x1DBTyKQKRqWUI2EBxMtZVdnkXhoIELep qFmZJ3MAKV6UBDaaCDJ1giRyFEkfQERRKDaZ0cF/DstErgplbmRzdHJlYW0KZW5kb2JqCjI3 MSAwIG9iago0NTEKZW5kb2JqCjI2MiAwIG9iago8PCAvTGVuZ3RoIDI2MyAwIFIgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0IDM0IC9Db2xvclNw YWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0 c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZVV+ZOi VhAeuUTFC2TGG3BQ8RYv1BEUb1AOdfCYnZlkk1Sl8v//A3lo7W5S2dTO9g/witff6+73dX/c eSAIvhoEeTx3P2MeCMUDBLCAH0dh6GfAEErQaZbjOCYdJwkv/BNY2PcgdEeKPBpKopAhfcjH sUiIGxrO884yDX3a5Sn843HRaGn56deLvd3az4dNPxfBoI9eFUpW9fc3Q+n1FN056a2ED/44 tLZ5dRQhnc73NudnJRdErmR9uWvA3Y08l7obkYDF6+koWdtcrE4y6Kfyk+N5IZA4HggGA4Ap 4OCBEK/Pf6XOi0AQgvmIIOHDbiQCqH4xW3GfN8zJzsu6Gqceslwu+xDGYeCLh2KJDMOy2XjU j3kJKslwTIIMoO6FuFFfdhJDRhKV+em8rHN8TRrJ/TpL4ggaoNlKu/80eupVsyQRSRXF/kAS 84mgi3Whb+d5s1BoKNZ5p9QqHVU3bWvZy0XxwIPQn2nG3jnow2KCZprKUtPWi1E1SQD+AXT7 +TdnNVFXlrOftUr1p4W2sRxnLabCscKTZhqW8/q6k4U0K862m+V8udHHZRqHXKjxx1+fj7a9 2xtqI8cIrV63pxing8zfZ1prSxvLK+fF6vNMRbV3i357sLS3AzaIXKG///m+19dLVSqlKCrF 5djH+sw5zcupx6FhKLVST3vW21yua5ztcaMsqvZhVoqiHjfhX95NuV2v5DMxAveHY/cJpjY7 XlbVND80NsPio7jYrZpcQXZe95N2ozO1DotqDIPcawItUUzGyHDAiyAYQaVyFWl9Bjyl2M7a UDvNJ92eVRlBvbw/zwe9wWStyUXqBnVbIoChCCASxkmm0pZk/XQBFCfKqmVqS93aDPhUcXp5 syedptiRutVM6JqwfjGaNHZtLggLsy1ZliR1d1xVaJIbmKfj3tRGpTjNK85lIwk5NveYy1B+ xK31Br22JYQ/1KfapFUbGI5Wu49mutvT0Zj2hHgwlOmZx42UTyWSmWzSHex/Q+FARjJ2s1Zt aJ6NToZmJcOx1FY+HvL66Op8b09bAl8olfNx0BMoWVk7ej2GXqPC/nTPeNaeepP9p4NczBaV /dkaNx8TEZ83lO1qe2s1HsnjUZNxa40UxttpibxB3YTn1namzKzjTm0I4vL8ftTkdpmJEX7q sb/e7Sxjq6liNoh4ECLTHIhMCLnVioYZUVFHUl+ZTYeiODJe3k67zUrtFe6JQOyxPV6uV3Ol k6eBIkDeaJrLkPhNGzywN5LKlwQ+xwvlcr2/svfmerHamtqQj+K+aCpfbTSqhWzMHTvgTIQI /IsQemAsEKHISDhC0qmyYlqLfqPeUc3Duhn3IVggTNE0FSHA3N+EAAHNcM0XPDwQjGIoiiAo ThYntiFXWKYo6Y7RTflhCEYwYMD9JjFfQF/fnusPxIOEciPDGDfyfHWoH1zBc88Hm/8D+4q/ u4P9yeZ8swStNVpst2OB8n5N7R9e311CWIRrj+fAlquFXLsKw3cd//vRA0YhW74qU18sJIIf 13ZQFuwN0mmOz/Ns0hXBH9f4Lb6rwoFQOBIO+rErG9+2frwCVCHAwCB/J+TfF3vV3AplbmRz dHJlYW0KZW5kb2JqCjI2MyAwIG9iagoxMTkwCmVuZG9iagoyNTggMCBvYmoKPDwgL0xlbmd0 aCAyNTkgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTA4IC9I ZWlnaHQgMjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRl cnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBtVZZe6rIFo3KKCCKaATEGXEeUJw14ggqKE6JMTknfU+f/m7f//8DbmFO 0t334b5lP+3atWsvitqrVt25XG6PY26323X3teZyQ6iXIEmCwFHY87VobpgI8rFEIi7yIRqH v3RvHpzNKL3BoNdpVjIRCvlKMA8ZU43D0d5aG31YjlKw++vODKIz2uP3571l7U/2rMJ5PV+I 5ZcX19ed1u1Nd0+HB8kPf11/QIHc4nKelBLJkna4rKohFDT/h7kcXNdtBLxP5937nAOsudHm 11G/c8gZOBM3A4RysgHW/NHuxP200DAvViOCeWAUQxEU83oxGCR5EAz3OnxwA3ZgIOS6AzHU IQjgC4JhCAQhOElRhDPncnlgzKEQBgMUZxqUAusRCKDdsHbtKEVy9dV5o9zjCBkMs0wwEhXC PgxGSeZeiPIhvxdBiECY9aEeN4T72SDlON5AiKW9hD8STyWjoVsIo8NiIhEFayGQFwoFmRAf 5Rgv5HawFk+HoRThpJ51mBWCmDecKeYludJsFKIBHyvmas1Wo5Lh/VQwnpdFGoEwNlnIRX0w hIdS+azA3qeqnX6vmRd8KOxlk2W121WLccaLB2K5QlYqKGotzWKeG9b1uu7WlOHmtO2nfJgv 2Zpo/Z62XPTyYlRWxwvD0OfDWjISLfYGFZ5A6WR7NgYti/rTraGajWXbS9NczTpymCDCcnuq G8ZSU9MszZWHk2F3ONe1epSEXGBfy2+/X7cr8/TybLZiFBbITw97YzJdLIbVXGWgm2tdX1nm XM2maxNjJAepSG31fBpLAYqvz41+Xmrop6O50LoFjmalnmEas5mxWajJSKK9OZgzbbbUFJG6 Yelv//7xfH56fXvZ9qUgyZZW18uq11AatXJ9tLaWg6bSmZi7hZqvapbeEMPp4dMfP6x6NCwN rVVbkrrby37arhUTIUZsrvabkaqON7tZNZEdHl/2mgoqSfeAuM6+vv98tdfr7eF8WKoJNlLZ vDxOijFeiMttY6e3JIGLl8fb7bha6q2th0K6qn/784/HUS6tLHezsphQrYs9rmaiIZrNaqez 3iqWOsbR7Mj5h9PVVNMCz4XA7XfDenkxB/Wq0ptv90slHq2un3dt0YeTrDTYbocS48Uovrbc 681cfbYzes3R7uW3t4vRaY4ts5cK3hdnh6PeyQkBKlw2wD/p1mo942ANCsWHw3mWZwkcv3HF 6cPL8UHmQveJ2vx01ArJunE2KoDTsF8a2+smj3tu7m7TluSeaa8Wm+PRBjeasbT2y2qE8ImN pW3rvXyE4RXr23UzarcH89VclQsj2x4kSMghNCAzwJo/An6RKOZP9g/PKyWr6MdFgYHvIDqr 2av6PQp2T6WGO7OdjFWX58vlcjJGmvkIHHuYoRE0kFSm1n4zzAux5vb1Se8qNUVtK3IiN9xa naj34zq/YW1bAgEjVLx3fDGbsqLvZ/kAdOfxpR9ssyWSMIQyOQ1sMRrODE//+vlm90u16dOP n9/MBu+FEDKUqD5YJ6svpxvr56NWzSSTqXRC4MAZbFoC/jcswOVBJuRn+ML08bqqSwBrmnOw iFjHtLUiR1NMQl3tF+UwzSnbH/95MyqxZHv/88+XqRwA9A2EhXR9fnpc1jKV2emgleM8J4gi F5EG1kbl/4F1fTZaBTlff9iBk8sna7+w3Fi4PLPNUUVK5dS5bQ3SNB7Izl5+fxqlguGi/v3H sSMSMMbEJLmgTE/PayUpdc3DqleSpFwhlxTl4T+x/PL8+va4nmlTfXc6zKuiUJ5vNdkP3bkg X7yl78z5aKAZ2+2kHMFhr9CyHlc10BDxnn1eFFkEIrhiZzAYb87neYnnC+Ptfj0dDkajdiEp 99dGg/trX77U6Ph6Pe13u912Pa6KDCsPF92UD7q7c2NMpr2wLMu0rLVWdUQbYeT+tJOmESxU HE2aMQryeLnyaLk27f2qnQjQfFkz7Z21WYMbLpZuTrXKPfZxXh6Cr4yN9UpfzrRBU+Z9uE+s NIs8AfTZ5cGDyVof3Fbzcbsg+MBjxENwclkK4x6IiuZLqSBQOzSYboxmi4WmZoI4SgnF7nS5 XEy6pViIk5VaKoA42uWYG6WFbKlSKZcK2STPEDCEBYQYR4NGd8Awmkvly5VSNhYinXePG6FC HEsCcULpcAQohcsFedmYXK6WZZHBIQ9MhhP5SrWcT3F+whcWoyzIuSE55VDSz7BsMMj4KRxx xBElKAJ9fyoC5cN9DBsK+knUUTuQjuCODgJNRHAvBkTpzg1hZIANswESKBqQT4wKsCGW8QF9 RLwkCd6Bv6DAarcHfjfoXapBAHi/vgWoOAQjCAJk+T1yU/gbqqP7tyCoDyPoR8rHCFwWTqW/ Sn0i/j8HCPvHX3DSPkefzi32t5z/WfBZ+793ykPgCmVuZHN0cmVhbQplbmRvYmoKMjU5IDAg b2JqCjE4MDIKZW5kb2JqCjI1NCAwIG9iago8PCAvTGVuZ3RoIDI1NSAwIFIgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNl Ci9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1Bl ckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1W2ZKiWBAt 9t0FV8AdcV9RVCw3FFHKDUXL2rofZjpiYv7/B+ZiVXVPx8S8Vb5A5s08JNyT53J3BwyCEWAw DHnO1xiEYCTDcSxNoF8GC6OkP5rMyhkpzOHI1zQLoXQk2xiMJyOtkvDj8Fe8PYRQkYJu7Z2j 8zBtCDTyFaAwFpCHm9Npv9vvV70Mh34JKBVvrd2DqWuD0aid+hpQhE0PHXfZykpJuZCNeq// QTBvyyD4d4NAELoFIe/yycP3EEj9oCXC5SauOyuEWdbPBxkcvhGMZRkSg0EuRpAETpA0TREE SXmcg2AUJ0kcQVCcYjmWwhH4PQTyKJrCPVoibHbkPi5rMQYHhiHvBMtkElEfiSAYG4qG+VA8 kYiFQtEoz2IwjNHBaNhHkWxITGfTAs9gCEoFIpEQHxETAk+j8B1MS9ruyRmX4hzoA4ZROpyt a7quVdM8hdHRfLWsFBvdbi0vl6pKnEFROipXFDHIS8X2QO+3FYHDiUCqVCkoFVVryWESuYPx UMlwn5xZMx0CD0GoaLG/WNv2ytBkng5ke3PjfmisrLHaHEz1Ypgkgvn+pJtPZFsTy7bXy1FN 5Nh4bTwf6+Pl2mgnWBSCUEZsmO6Tux4U4yxO8MrQ3tmmaW8tLR2MlBfuyZ4vrOVYbY3sdT/t 4yTVsu8rxc5iu7FMa/MwrcT4VH/r7kzDXBlqkkOhOxjjpPrscL0eZnXR50t2H07biabNto5Z E4X6w+vzw7CjqvVCQbOdRTUeKUz3G73WnjvH5aCjW85Wz8Vzo/PbydDUTkuJ3eYHxrl4aWBf nt1FXYqXjMvjuletDezzrpdNNLdv13k1JYrxiFCeOZt+PtdZO0u1poONmDYrbcNxF9VEfnx5 3WmyJAoR7jbpgDd0KNNeuC/utJpXvdb0Vmtou3s9n2puXpx+0kdRFMkltY1jdtXZfndfqU4v b6dZp9mdH9xlI62M3UezHGZAGuZpksdhlPCJVeP8vNObuvP9dTvp90fLh2Unm2zaj3YjQni8 JkLl+fFgLXdHqyVX5s/fz6be02dre1xOKaPjcZRhPfp46gm4ThAYijFCc/3kznvj47enta62 VK2vKqLUWJ+tCo95w4WwqcH+6Xq9OiNFKs2fvzmzbqvd7Wu1tJAfHfaDBP0pcTDGBHk/TZBB ZXa+LPv3+5ez0cxnszk5I4TijfXJLAdvKgMTkdrq5c8fb5u2FJEnl+dNv5TL5ORcMhKR7w/b nkR9giJUOKNkhVAwXjbOrqF2rYtr1NOiICWTMT7eWJ0WpXdQCOWyo+tff7/OC7wv2ds/bvqK JIjJlBgOy/f7rSb+AmWkuq6r1WJ9uLns9FJ5uHMfhjVFKVVK6Zj4L9A7mIy1dn/8cHsJhopU zZMzV0v5QhmMV+w/oAnV3NjLubU/n+ZVSarMDqfNYjyaTPolSawvD0Yx8C6yEObPT8/XZSVE YFxKs0+H1XQ0no5aWUHWN3ZH+NkpTEUrk83xdHLPB7Od8PvFurE7OnswLsOSECuNLT3n+1Bu mIo3DbObBLtM8PJgfTwedlvbaKejaXVhNGLk5zf1Bqo6mK9se3lfT/oJArj6YrWy5notEQwm G92qyHycMaDVVK2e4wmgj1RI7kyt9cqcdJVoIFZQW7kg7kmwZxCCc9F0sd5sVHIxHxBHjI1m yo1mvZwT/BQVlFKCn/jsACEDcU/cIFBGBiWl1mzWCinAeS6aTIS9+IcBhSXZQDgS5jnqpsso yQU910cBoSQYjiF+nttgAmiGBIJ5a4bxh4CKBlgCRYBes6D6E9NbhxHME+iPXwnwFAwnPBdI Opg2oOw/k4EP/mRuLqhCPV331r373/LeC8CR86sUHEP/9n5Ceje/rfxf3j/7e+fZCmVuZHN0 cmVhbQplbmRvYmoKMjU1IDAgb2JqCjE0MDgKZW5kb2JqCjI2NCAwIG9iago8PCAvTGVuZ3Ro IDI2NSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMTYgL0hl aWdodCAzNCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVy cG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAGdF2d34khylAVIiIwEGJGzyMFgTEYgskger8O+eRvmvb3///2qwWCDfXt7 V1/Uqq6u1JX627cDYDgAhpbY+/LbcXlAH8mu9s/I/2eBkzRDk0gohpMMy9IEjtggNHNAn5ke 9yniUpHz9j9f4KRBsJpZEhjhpNHmdgksYooRrNlm5eiD/DduOGWyuRxm5h8JxXCCII7uu1YG I42OG7+bp0AOYXBGshnZggRhpMklB0Se+iCUMDjC6bjnQHvN5/ofXGbiDPRX6oE59mA64TOD TIyyRBrjYcnHASVGct5kLi5xyAFvQHD+UqcRt10Yf9q8+hKsRfK6LlQ+UeC0JZArpz2INW6Q ivOXX9SUHTEljFK6Vok7WeJE+40UIu3FKOdmP9h+3rxcgMqeRCbs+IIUPOhR6rU42sMoIdx5 +uvntuYzgRycscdu25Wg8O5d0hIf7OYl8QtGlxLR1Zj92VLCbXjX+EQCjOONdlk2IzMZV276 419/PffjVuRpgrsp9bo5yXg+RloTw/2yLH2UeUgpHDtfAPxD7BAExXviabCTQImIcG/piC7N X+53s8hbGMkHGutff/vtdV7yGMB7OONMd8d3EQsKrwN8lokRFGMwGthjrkGyERRrNHEcZzLy Tn/AIzAUZB8LOJPhjQan7cnOpH2wC9bp4Xa/2T5u2hEBGUoK4eZMzb+78lomhlMGwSn5vKKd R6mMEbTJ6vbJgYDsczvcN7IoGAAhutwev99jNx1uiTD6KpNZI8CB+wiTrzrfTDq95U47yoHd 6nR+F+TJr+3ECMYshjPFSqWQlB3AkWAs3liu0mg268VEMJRMh5yCM6Tks0qhUivGpUMUk+ZI ezUrI1dilDXeXS+bSqG/0ZuhtwvOa+tB0nZy7pWdOGPxZ+8GY00b9WoJkaMYi5xvqdPVZrfq l9O5ejPvd8rFgTbsdofaqJWRTCSG0fbMaDvJO5lDopSmO60QjNSX+7HiZJAatrS6nRZEWH9x nxhl9hf709lkrM0Wk/uUm+O9hcF8MdcfXx/HVaUy1BoRT7S1+a4P253xct5CmY2zYmn+ME6D IRDb4fbu+ygfDFcXv2waMqoLpBDr7/TbG+OXMgmDmO0vZr1asdwcr2bNqNMZay3m/WZ38bgf 5JNVbdWO+5L9x6dZXVHq2nqCYhM3+m7172rSSh4SZfbr6/IuX2hvfryM06gugB6d3bYVRNeN 4NK3sNtcLDqKLHmj1bGulWSfMlyNKkmlvdI76Uh5oncTvuTgYddNSGK8tVrdQeAQJrm5eRjE BBKSRm4+/PnH42yoLp9//rm9RXWB4IKt3b4bMb8F0YVMjHZkhvq44OVZoy3SXC6b8UBuuBzk w4m7+eI+HixqB5n97aLq40ze8kxvh3mC4AKt3UMvaiZRooxef/7+vNPX+9c/fj4PUP7A/v32 oQ86fWEnzrgLYAnQ4eDl4mTdTwfSnbnWKJT7y1ktLBfeZG6mBRfDuPJADJKQHdt9D+xAibJ6 ednNxqPReL5/fUF1Aen0NzJZqTTVIZXJbxjjzGmbQdoXrk5WU3U0X/QVn+9NZm+NgpR2ZDW9 B9offLvvRQUSJcp2rzXySiajFJrTB6gLFuroW+SHdzsfVlWviSIBjGIBjEvZWZJEnlv3Em6P Mtg+bFezfkl2SPmjnWeZ44NMiKG6vh/EBRo6ymQ7qQTddgB3uDbborpA8Z9iSP2+uY+4LIIg mC2SMlxPq0G7WRCTndXyLmhzJrqb7+txMyfbeHfuWuYa2YlyZbFXU1bWHL7X9VbEylIURRts sY6+grrAQK7s9frHXFGfnia1dDwWi4ZkOdmcr9RqMhxR7mf6KC+ZHcn+Zqs10rLdaHB9LRNC TxlvoQBwjvRA1woSKu1oXPBAzPXTDpMtpe5m770Letnw6cfjfNjr9Tp3hXg0312stG6zNZit JrchKyfmtIfdqJbyOziTKztatGLeRGc5yjppyp5Rl210S6QQ7ejToiSISu+9g0AZjDbHPcVt Bv9shmn7ufaZQ63ty/PDZq3rK62ZkoO59nS5mEPtUW+jTpPgv129PK369VxEsoup9rAWEsN1 tZ200RAwLfU2yEMCmm5q0+mtbHPHy9XkucESRjFZLcdcVl9lumiGzjWeMHmynclsoo3H41G3 EnHZvYlqZ6iq/WYhhExLdbfPT9uFNmhmg75wvpz02LypSg7aM8nfZMsp1IuhRWb6k/uYwybK sps7TQQ4xbllWbTYwndT9eRxcDrOCN5YJnsAJRl08QbO4UeIZFiyGFhLqD5d61NV1aACFoLe G78omCyS7LWxBMFavX7JDMUNqmzwVu0qIs/xvIE6TYaoL/I8xzmT7dFd9L1nQ/PiLDbHAew2 s5EmSEDYnU6b2UCRrEsZLKetUrbQGK9XrZhT4I3Qso08x0JvhTGQhwPQ/nHWnWn1yrJAk+SH YRT6PUnSnDffaX+cTQ5zAET2EdABNBjQNE2RMH6wEkSeWor4Q9nuettP2BiggKmEPIy5h8XB KDBULrZu445Tu0JxewSctoYr9+WPM9hp6/KLAQAG1M+NlqNaMhIv9nW9DZXmku78B0NYtFzL eKCbnnHHBWF0JyvlGMya1ztXhG+/oGP0Tpv0GtV6R1uMyjdoePwSYIx3x3KpG/Mpfk5UhwE1 G0et/YT6+y8G0Z5q9IaDwXA06lXCts+uOzFAMRoMHkeVEw590dshEBQ/6fKR5nINnMRIrgrT UKOSCdgNf+MfePhY7RbDtTnojWS3Xb6RLmV8+sMpo1WSw9Fo6AYeWuTbcPGJDBCHB97Vow/R wVuQZf6ndx8EMW3gBIvFbGL/y0E0eZ+G7A9K/Qf0B4rPS3QGtbkPaXdN9G/cZ2jUCmVuZHN0 cmVhbQplbmRvYmoKMjY1IDAgb2JqCjIxNDUKZW5kb2JqCjI2NiAwIG9iago8PCAvTGVuZ3Ro IDI2NyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA5NyAvSGVp Z2h0IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJw b2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4Aa1WaZeiyBItdpRFBFncWURxw63c0LLdFXEDtcrqPu/9/58xydR0WTOnP1Z8 IS6ZGfckETeCpydgEAwjwGAICtG3GwSjeIRmGIrEAMe3h3+CEJziU6qu5xQugn4/AwTjsbTV GU1ehk1DjKLffgUYY7PNqXf2z4dVz4jj8Hd/IySi2Ivz5Xw4HL0fVZn8bgIIjRkv58tu0us5 474lRb6dABeq69tpVMqk1UIhwxEIDAwkApQueIYZgT5q+CP9fwJ/p+2z1P9zAiLEhve272TY KMPF2QiGESSBIRCEhA4oKuCQUYaho38EFE2D6gbcYNtnqcMoEZ6I4GHVQ3jC3t3PQ40jMRzH MJyKiwKNwzBOC2I8isIoyUoZzdDSAoUh/wExKauqGYklw22ckte1jMgQKE4nMqqeT4bHnyCM K81vb9t2no8CnSGkoJULchRBonLBUgUSjya0em/84rRNiSL+BSiw0h0Ou9U8H8EjCb0xGDnP 5XQsGkuVu86o39ATEQR6QqhM17vftv2SwhIISmVb454eQ9GY3hs3MwwllQarPaiwxbMaZ74C Vir1F1vX3cy6hkDzen9zOOyWA0uOp+pT77jf/GjlWAx6gol4Ybh/fT1OG/k4ibPGeDev8BjG V+buyBBEc+T5p91mDcJIcvELkEzHPbjLpbtfd1Ux3dzerof1bFhJy+aL/+a7y0lb5QABhESE Qn97vV+3PUOguOLsvKkncDxR35ymJSXf3V0O0+dGwy5lZfUBMiEI9pNud7o/L+2cPji9B4t+ s6rKSmV1v3vjjl1MMYAgZODV5ux0f9sPdCFRmgdbOySwXX9WzpWn/nlSSUuSLAqyNfsEvGTN bq/bXrU2cK+HgVnoHd/9aaOQEWMJa/H65vbLqsKRIAchA8EmLccDtJ2sYn0lqOqtbbBpKhRB kCQtNx6Akmz31/tu2Gw67uXomPn68nLdDqw0R8Xyg+PradrQRBoDsg0FhWBRQe/t329TK1uZ +583mNfMrufPiuBTAoFFlPYDkHLr+P9f+0m/P17tVs+qrHY2vr91ygpDidbkEBxnLTUObhAO AwLHUDJujIN3t6lX577bEHFcbLj+vFbsef7UZFFwUZhUOp8AIuT26X/37bDdbHf77aIcE7T2 4hjsX8oSzSjl0c4/rzugimAIIVk+TpM4lers7/uOUZn5u5ZMknLbC+a1wvMuWFYTJIogaERp PQApNb2f11mjoGm6oSY5ihHVxo/j7ejoPM2lSv3N5bKyQe8E3TpVMHNSXMj3Dq9uS7Mm/nGQ 5+Lq8HydV1R7BVKoCQxN04xcXz+AVF3eLrN6PpVMZ7MKz/FS2mitbm8bOyUklFzZAUl38hQC 43yhO+rbVrmzDK6LSlofHP2FrWmN1f1tYaXN8fmy7Zd1NZ+RlSLou7+BbAwPl51TM02rYmnJ pGqWKu3F7afX0XJGyao7h5+3iU6HBMWxu98slm5w3ffyQtJe+4dZvzc9/XqdmVLKXgYXbz4e 9hp6Ktd4gGS6Oj0F3uJlPJn0K6pWH4zHUyDYddMotUfjycoHHS5HIRDG5p/XpyAIrhdvVARK 03qbo7ear/aXg6NxXLa1OPqnvbsclBQx/wAyn67PDv75uPfWTiWn2ZONd/CD3cDMFXtA3qfg NK9JZJhkwWhPVtuwp5hSFIsIRmcy/zEaOC/DqkKRsWzNma/Xy5eWBrL3CVSeYtPV4WKzWc+H tZwoFzqT5Ro0FFMWMtXhfL1ZjutpBggBRiPxdKFiN+rFrAD+KtAInzUrZVPTQHGwOIozkmrV 7Vopl4jixBeA4bSklsG5sg6KiE7kSvVGvZQVqEgsaVRsu6IrLB5OKRjBoywvigmOAuMMCIqg OEHgWIZlomBkgE7PxBNiIs6Arv9HwLMRHMVIOp6QEnGaQFE8GhNEUQDT63MKomDY4OjHbxeg wIChCPrxIsRgFQPhQWv8AkKRYn+rNJyt//ggBtgDxEv8jgc0CgwC9uH9A7+Aj+XHi69bv54L /d9BHu5faZAXuQplbmRzdHJlYW0KZW5kb2JqCjI2NyAwIG9iagoxNTE0CmVuZG9iagoyNjgg MCBvYmoKPDwgL0xlbmd0aCAyNjkgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMTE2IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29k ZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRl cgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnRdnd+JIcpQFSIiMBBiRs8jBYExGILJIHq/D vnkb5r29///9qsFgg317e1df1KqurtSV+tu3A2A4AIaW2Pvy23F5QB/JrvbPyP9ngZM0Q5NI KIaTDMvSBI7YIDRzQJ+ZHvcp4lKR8/Y/X+CkQbCaWRIY4aTR5nYJLGKKEazZZuXog/w3bjhl srkcZuYfCcVwgiCO7rtWBiONjhu/m6dADmFwRrIZ2YIEYaTJJQdEnvoglDA4wum450B7zef6 H1xm4gz0V+qBOfZgOuEzg0yMskQa42HJxwElRnLeZC4uccgBb0Bw/lKnEbddGH/avPoSrEXy ui5UPlHgtCWQK6c9iDVukIrzl1/UlB0xJYxSulaJO1niRPuNFCLtxSjnZj/Yft68XIDKnkQm 7PiCFDzoUeq1ONrDKCHcefrr57bmM4EcnLHHbtuVoPDuXdISH+zmJfELRpcS0dWY/dlSwm14 1/hEAozjjXZZNiMzGVdu+uNffz3341bkaYK7KfW6Ocl4PkZaE8P9six9lHlIKRw7XwD8Q+wQ BMV74mmwk0CJiHBv6YguzV/ud7PIWxjJBxrrX3/77XVe8hjAezjjTHfHdxELCq8DfJaJERRj MBrYY65BshEUazRxHGcy8k5/wCMwFGQfCziT4Y0Gp+3JzqR9sAvW6eF2v9k+btoRARlKCuHm TM2/u/JaJoZTBsEp+byinUepjBG0yer2yYGA7HM73DeyKBgAIbrcHr/fYzcdbokw+iqTWSPA gfsIk68630w6veVOO8qB3ep0fhfkya/txAjGLIYzxUqlkJQdwJFgLN5YrtJoNuvFRDCUTIec gjOk5LNKoVIrxqVDFJPmSHs1KyNXYpQ13l0vm0qhv9GbobcLzmvrQdJ2cu6VnThj8WfvBmNN G/VqCZGjGIucb6nT1Wa36pfTuXoz73fKxYE27HaH2qiVkUwkhtH2zGg7yTuZQ6KUpjutEIzU l/ux4mSQGra0up0WRFh/cZ8YZfYX+9PZZKzNFpP7lJvjvYXBfDHXH18fx1WlMtQaEU+0tfmu D9ud8XLeQpmNs2Jp/jBOgyEQ2+H27vsoHwxXF79sGjKqC6QQ6+/02xvjlzIJg5jtL2a9WrHc HK9mzajTGWst5v1md/G4H+STVW3VjvuS/cenWV1R6tp6gmITN/pu9e9q0koeEmX26+vyLl9o b368jNOoLoAend22FUTXjeDSt7DbXCw6iix5o9WxrpVknzJcjSpJpb3SO+lIeaJ3E77k4GHX TUhivLVa3UHgECa5uXkYxAQSkkZuPvz5x+NsqC6ff/65vUV1geCCrd2+GzG/BdGFTIx2ZIb6 uODlWaMt0lwum/FAbrgc5MOJu/niPh4sageZ/e2i6uNM3vJMb4d5guACrd1DL2omUaKMXn/+ /rzT1/vXP34+D1D+wP799qEPOn1hJ864C2AJ0OHg5eJk3U8H0p251iiU+8tZLSwX3mRupgUX w7jyQAySkB3bfQ/sQImyennZzcaj0Xi+f31BdQHp9DcyWak01SGVyW8Y48xpm0HaF65OVlN1 NF/0FZ/vTWZvjYKUdmQ1vQfaH3y770UFEiXKdq818komoxSa0weoCxbq6Fvkh3c7H1ZVr4ki AYxiAYxL2VmSRJ5b9xJujzLYPmxXs35Jdkj5o51nmeODTIihur4fxAUaOspkO6kE3XYAd7g2 26K6QPGfYkj9vrmPuCyCIJgtkjJcT6tBu1kQk53V8i5ocya6m+/rcTMn23h37lrmGtmJcmWx V1NW1hy+1/VWxMpSFEUbbLGOvoK6wECu7PX6x1xRn54mtXQ8FouGZDnZnK/UajIcUe5n+igv mR3J/marNdKy3WhwfS0TQk8Zb6EAcI70QNcKEirtaFzwQMz10w6TLaXuZu+9C3rZ8OnH43zY 6/U6d4V4NN9drLRuszWYrSa3ISsn5rSH3aiW8js4kys7WrRi3kRnOco6acqeUZdtdEukEO3o 06IkiErvvYNAGYw2xz3FbQb/bIZp+7n2mUOt7cvzw2at6yutmZKDufZ0uZhD7VFvo06T4L9d vTyt+vVcRLKLqfawFhLDdbWdtNEQMC31NshDAppuatPprWxzx8vV5LnBEkYxWS3HXFZfZbpo hs41njB5sp3JbKKNx+NRtxJx2b2Jameoqv1mIYRMS3W3z0/bhTZoZoO+cL6c9Ni8qUoO2jPJ 32TLKdSLoUVm+pP7mMMmyrKbO00EOMW5ZVm02MJ3U/XkcXA6zgjeWCZ7ACUZdPEGzuFHiGRY shhYS6g+XetTVdWgAhaC3hu/KJgskuy1sQTBWr1+yQzFDaps8FbtKiLP8byBOk2GqC/yPMc5 k+3RXfS9Z0Pz4iw2xwHsNrORJkhA2J1Om9lAkaxLGSynrVK20BivV62YU+CN0LKNPMdCb4Ux kIcD0P5x1p1p9cqyQJPkh2EU+j1J0pw332l/nE0OcwBE9hHQATQY0DRNkTB+sBJEnlqK+EPZ 7nrbT9gYoICphDyMuYfFwSgwVC62buOOU7tCcXsEnLaGK/fljzPYaevyiwEABtTPjZajWjIS L/Z1vQ2V5pLu/AdDWLRcy3igm55xxwVhdCcr5RjMmtc7V4Rvv6Bj9E6b9BrVekdbjMo3aHj8 EmCMd8dyqRvzKX5OVIcBNRtHrf2E+vsvBtGeavSGg8FwNOpVwrbPrjsxQDEaDB5HlRMOfdHb IRAUP+nykeZyDZzESK4K01CjkgnYDX/jH3j4WO0Ww7U56I1kt12+kS5lfPrDKaNVksPRaOgG Hlrk23DxiQwQhwfe1aMP0cFbkGX+p3cfBDFt4ASLxWxi/8tBNHmfhuwPSv0H9AeKz0t0BrW5 D2l3TfRv3Gdo1AplbmRzdHJlYW0KZW5kb2JqCjI2OSAwIG9iagoyMTQ1CmVuZG9iagoyNjAg MCBvYmoKPDwgL0xlbmd0aCAyNjEgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggMjcgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2Rl IFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVy Ci9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFlkm1T2kAUhdndvJKYopGKDdBgLVYbiako0Bak EE0AcdgkNMTpCAgzOI7//3MXMSHqfkl2k3P3POfeRCJcAJIFQLiNPQGiOZ6l4PtvALFSekcW aBj7ffUKaSl3pBczAvVOhpIZvd2pH8jsWxmgU/tN/w5XcwJ6I4NcxriZP46vDreY1zJASYW6 //A0x2dKEr0yAtn0sXV7P5v6f4opOl4RIDFfvfGHjj/q/djl4xUhs3XYdgfmhe3hxpcPcRlK KuVr9+pUq/WHtv6RW8uI869NFzcO1OPLIf6lbqyxl86vA/y7qH5v/Q1sbTvCBtTGXsOfjsyy Xun8m3o/8xH20nlvspg49mV3OHu4syJsgIR8zZsvJiMXu8H9YobPQ2zi/JsZjINB17KsHr4d r7FR8lO57+NWuaRpWum87fgh9tL5heM0j5RtWZbTWa3l4PoKG3I7Jx2vY+wKDE3TjKicdr0X bCR+rvYHjf1VPM81Bv1KXkQJ0o69mm2ehKGSmw3TqhUkChDenF4x1DBTyKQKRqWUI2EBxMtZ VdnkXhoIELepqFmZJ3MAKV6UBDaaCDJ1giRyFEkfQERRKDaZ0cF/DstErgplbmRzdHJlYW0K ZW5kb2JqCjI2MSAwIG9iago0NTEKZW5kb2JqCjI3MyAwIG9iago8PCAvTGVuZ3RoIDI3NCAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBtVjLchs3ELzvV8yRqoohvB++ SbLjSspJZJNVOcQ5yDRlM6ZISyvF5b9PD7Agl+RSUvyQDkuC2AEw09M9g2t6RdckSUtSUlsK PtLNjP6kJR2ftYqmLSlqp/szLkkKL/MfzXmubjBX5v/h+byQkpK8SxS1wefUW0qXpVRerunb xlvZ6hP8htd5h9MrOp1QtGUcTy+FC9IoioYmV3T8sxI4EE0um79odPbH6/HTI0qJRlQeJ9Pp rG3pxc3F8vaI/qbJr/R8Ak8c9MV6P005K282n1U4qZKXkX2koiLjsK5N9XCXpOkzWfote4jO xtgU/4/P6LpZHwuHivlQ2YLG2xsL425bxycn5y+fjm+/LGZ0fL5QdPrsLO+398PZank7W942 p791P53PbqazT7d3Fwu6mbP7EWHetrGkkiUrEWB465cr6+nZqlvpeff2FiiaIVDAYIkAjhQ1 WVcjYwoOnuCpjPBJWkNYokYGJ59c0ujN6OTNUQkC4jL5ZxODuoXe2b7+0IBbd2atPRnv65nD jzqzdSJ6FzQBEDtnPr94Pxs+65a7a2KscdflWMZdg+P0ceedJacxRFcUdEQcJC0oSt2NLvKo SwqjH5B+m9mXzWF4bmK7hie/qn1YL2RM7BbKo01ZSKWwXqjO/q4oji4HFCf10ZNTpgY0fmNA s2vgpkIvPRAbK6SyPlDY0EsBMehlPLs5Iob66N8jpBWN8nelMttsc8shXDeHk5kOJrMOxQ3Y lUIuh1TdkJr7c7mCa4vge7m85Yam5wZvREpOabBbXAMbOOFkPnkEqiuJDKK6h2nJbKoZv3Cn Qpw7qdhm02aLTQfgyhaUBwVtLBzC4VcFgL3AzALzGiB0mf4asCny79sioKUhr0OzB0SlhAoG IuftTgAAxFPgEAQ/WkHkaPS5ZRx2+GuKtlX8DXKN65RqLzqdn+Uh1fJOCaMluMFpoS1y8gr7 iyJakzCmRJLegRIM9FnLAAxBihc0xqa4bqjCn6PurRYmeaYuL3xEvsFWxh3ecdCtBUw7oWJw 5KwXMYGTFs16OWe8kCnPA9UNGLsEUPg/1yhZE3MMUVxYZYVRVpNXXrjO97pTODwteA9lSyV0 2GDc5xqCmNbp9ez6btaioKhS1suph4xjbelVCMjj3RXejObL6eLu3ayls9Xq43z25mizxDpY KEx6y60p21grtE+GTPDCOHDGFdQfroU+YcwJb4E1OBUR0pCrEhZ2UA6HQRi9DdAUbYRLqBfw uoHUA/oIqLPCcvFjJbZvgH+MVeNWIZIuBajCB4zu2zkcCeOwVx2gU9J1ZLwXh2YnDi9X7+fL Gof202rZ9nR27SXIaC5NduSz0QnHw9lYPjWCXOSzjBZVM8i4Kp91duEjdlap6LLXJAFL2f8M IeZSmxg6xbjLmcDaXEaLcYu0rcbr7AGqah4o/A5rxbZk6uh5b8xU6huZis8H1+wz1ZBkwj9I mQcks3mcZN5T/1Y3wF079e+2ZIKuOsnEh/sJuyrXfZLJCNkj7EHJ7Orfx0hm1epD5FxFsJDz DgB5O0zODikMYvEigUoBRG+TUMjNPGagJ5y3RjcmJYGOTuMro2+AnJUIHtON1CJpx6D2OLXJ bOCR+S5F0IrWIlhrkPnrlQyUy2vweoa53bdzmA2slUIraJ6VGbbo/PbYYIczAbHCyx0l/9R1 f3fQRPo0n36EUKZmNHtH4/ntjE7XOpk7qnVT0195n4cChC15SI0Nu2T0OMoeIiPuAFmDug6Q cfcAy/DG+C1nQn2LQfNd6WOnb1TJVP4wDyROxe+hxOG+UTu5zx9DfWPhj/v7RhQV1/Q/+sZK Fugvd8gCbUyt7iRcW0iOOdP+qDPrAK3WAHevb+zOPL7LVxYb4edjDpZzlaoOMUa9hDjIGKzg RkqPSxUprEOsuWSIAvcr5MAQwaMe4IqBuwGuymTkDzw2yBq4EhEhaofeKAlrHZvjCwhc23AJ 4YVlJlEhoWDkAqSupWIUGlyCIRQQO0bAPGAMEOlgJYe6JqJ4RLWZm6JHMMaoczCKuK54aAaq uIguW0b4wSBIhet7VMQ/aq5Hd6vEBj1i285Xy034rjdUfb9RLh16NWEnHc/b24u3i3n7YfZu YzPfXnHo+I+L9b0yf0zHL3Cp975lbld8YZfdpwm3cQGNkuN0vcwkuD3Wvw/MhWFv/yCr2OUv WkNOmSd4IqLd5YfuruJY+CfolCON7vDgRrk82vLASXjw4qjhx5fyDczNL+B+iB+/l0E0ODwF 7XbPylX59nZr8KYY61435bdtm7oMyq1H6ivCq/8AI8PIxwplbmRzdHJlYW0KZW5kb2JqCjI3 NCAwIG9iagoxNzI4CmVuZG9iagoyNzIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAy MzEgMCBSIC9SZXNvdXJjZXMgMjc1IDAgUiAvQ29udGVudHMgMjczIDAgUiAvTWVkaWFCb3gK WzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjI3NSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYg L1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSCi9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8 PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIKPj4gL1hPYmplY3QgPDwgL0ltNDkgMjgyIDAg UiAvSW01MCAyODQgMCBSIC9JbTQ3IDI3OCAwIFIgL0ltNTIgMjg4IDAgUiAvSW00NgoyNzYg MCBSIC9JbTUzIDI5MCAwIFIgL0ltNDggMjgwIDAgUiAvSW01MSAyODYgMCBSIC9JbTU0IDI5 MiAwIFIgPj4gL1Byb3BlcnRpZXMKPDwgL1BsMSA0MCAwIFIgPj4gPj4KZW5kb2JqCjI4MiAw IG9iago8PCAvTGVuZ3RoIDI4MyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAyNyAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0 cnVlIC9TTWFzayAyOTUgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVE ZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITAaAqMhMGAhAAAIiwABCmVuZHN0 cmVhbQplbmRvYmoKMjgzIDAgb2JqCjMyCmVuZG9iagoyODQgMCBvYmoKPDwgL0xlbmd0aCAy ODUgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMTA4IC9IZWln aHQgMjggL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDI5NyAw IFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0K eAHt0IEAAAAAw6D5U1/hAIVQYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMDAOzAjcAABCmVuZHN0cmVhbQplbmRvYmoKMjg1IDAgb2JqCjYzCmVuZG9iagoyNzggMCBv YmoKPDwgL0xlbmd0aCAyNzkgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggNTkgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1 ZSAvU01hc2sgMjk5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp4Ae3QMQEAAADCoPVPbQlPiEBhwIABAwYMGDBgwIABAwYMGDBgwIAB AwYM/AcGF4IAAQplbmRzdHJlYW0KZW5kb2JqCjI3OSAwIG9iago1MAplbmRvYmoKMjg4IDAg b2JqCjw8IC9MZW5ndGggMjg5IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRy dWUgL1NNYXNrIDMwMSAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURl Y29kZQo+PgpzdHJlYW0KeAFjYBgFoyEwGgKjITAaAqMhMBoCoyEwYCEAAAiLAAEKZW5kc3Ry ZWFtCmVuZG9iagoyODkgMCBvYmoKMzIKZW5kb2JqCjI3NiAwIG9iago8PCAvTGVuZ3RoIDI3 NyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMjQgL0hlaWdo dCAzNCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgMzAzIDAg UiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4 Ae3QAQ0AAADCoPdP7ewBESgMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwIABAwY+MDFoAAEKZW5kc3RyZWFtCmVuZG9iagoyNzcgMCBvYmoKNzgK ZW5kb2JqCjI5MCAwIG9iago8PCAvTGVuZ3RoIDI5MSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCAxMjQgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4IDAgUiAv SW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgMzA1IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QAQ0AAADCoPdP7ewBESgMGDBgwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwY+MDFoAAEK ZW5kc3RyZWFtCmVuZG9iagoyOTEgMCBvYmoKNzgKZW5kb2JqCjI4MCAwIG9iago8PCAvTGVu Z3RoIDI4MSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAv SGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAz MDcgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAwNPA ABvkAAEKZW5kc3RyZWFtCmVuZG9iagoyODEgMCBvYmoKNTUKZW5kb2JqCjI4NiAwIG9iago8 PCAvTGVuZ3RoIDI4NyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9T TWFzayAzMDkgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUK Pj4Kc3RyZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAwNPAABvkAAEKZW5kc3RyZWFtCmVuZG9iagoyODcgMCBvYmoKNTUKZW5kb2JqCjI5MiAw IG9iago8PCAvTGVuZ3RoIDI5MyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA5NyAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0 cnVlIC9TTWFzayAzMTEgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVE ZWNvZGUKPj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9tDQ+IQGHAgAEDBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgw8Dgwf1AABCmVuZHN0cmVhbQplbmRvYmoKMjkzIDAgb2JqCjU5CmVu ZG9iagozMDkgMCBvYmoKPDwgL0xlbmd0aCAzMTAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNlR3Jh eSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQg OCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVtmSolgQLfbdBVfAHXFfUVQs NxRRyg1Fy9q6H2Y6YmL+/wfmYlV1T8fEvFW+QObNPCTck+dydwcMghFgMAx5ztcYhGAkw3Es TaBfBgujpD+azMoZKczhyNc0C6F0JNsYjCcjrZLw4/BXvD2EUJGCbu2do/MwbQg08hWgMBaQ h5vTab/b71e9DId+CSgVb63dg6lrg9GonfoaUIRNDx132cpKSbmQjXqv/0Ewb8sg+HeDQBC6 BSHv8snD9xBI/aAlwuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQBE6QNE0RBEl5nINgFCdJHEFQ nGI5lsIR+D0E8iiawj1aImx25D4uazEGB4Yh7wTLZBJRH4kgGBuKhvlQPJGIhULRKM9iMIzR wWjYR5FsSExn0wLPYAhKBSKREB8REwJPo/AdTEva7skZl+Ic6AOGUTqcrWu6rlXTPIXR0Xy1 rBQb3W4tL5eqSpxBUToqVxQxyEvF9kDvtxWBw4lAqlQpKBVVa8lhErmD8VDJcJ+cWTMdAg9B qGixv1jb9srQZJ4OZHtz435orKyx2hxM9WKYJIL5/qSbT2RbE8u218tRTeTYeG08H+vj5dpo J1gUglBGbJjuk7seFOMsTvDK0N7ZpmlvLS0djJQX7smeL6zlWG2N7HU/7eMk1bLvK8XOYrux TGvzMK3E+FR/6+5Mw1wZapJDoTsY46T67HC9HmZ10edLdh9O24mmzbaOWROF+sPr88Owo6r1 QkGznUU1HilM9xu91p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3mB8a5eGlgX57dRV2Kl4zL47pX rQ3s866XTTS3b9d5NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23DcRfVRH58ed1psiQKEe426YA3 dCjTXrgv7rSaV73W9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV2X53X6lOL2+nWafZnR/cZSOt jN1HsxxmQBrmaZLHYZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts2o92I0J4vCZC5fnxYC13R6sl V+bP38+m3tNna3tcTimj43GUYT36eOoJuE4QGIoxQnP95M574+O3p7WutlStryqi1FifrQqP ecOFsKnB/ul6vTojRSrNn785s26r3e1rtbSQHx32gwT9KXEwxgR5P02QQWV2viz79/uXs9HM Z7M5OSOE4o31ySwHbyoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+TkXDISke8P255EfYIiVDijZIVQ MF42zq6hdq2La9TToiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8L9nbP276iiSIyZQYDsv3+60m /gJlpLquq9Vifbi57PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ//HB7CYaKVM2TM1dL+UIZjFfs P6AJ1dzYy7m1P5/mVUmqzA6nzWI8mkz6JUmsLw9GMfAushDmz0/P12UlRGBcSrNPh9V0NJ6O WllB1jd2R/jZKUxFK5PN8XRyzweznfD7xbqxOzp7MC7DkhArjS095/tQbpiKNw2zmwS7TPDy YH08HnZb22ino2l1YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1suZ6LREMJhvdqsh8nDGg1VSt nuMJoI9USO5MrfXKnHSVaCBWUFu5IO5JsGcQgnPRdLHebFRyMR8QR4yNZsqNZr2cE/wUFZRS gp/47AAhA3FP3CBQRgYlpdZs1gopwHkumkyEvfiHAYUl2UA4EuY56qbLKMkFPddHAaEkGI4h fp7bYAJohgSCeWuG8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J8BQMJzwXSDqYNqDsP5OBD/5k bi6oQj1d99a9+9/y3gvAkfOrFBxD//Z+Qno3v638X94/+3vn2QplbmRzdHJlYW0KZW5kb2Jq CjMxMCAwIG9iagoxNDA4CmVuZG9iagozMDcgMCBvYmoKPDwgL0xlbmd0aCAzMDggMCBSIC9U eXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29s b3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUg L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGt VtmSolgQLfbdBVfAHXFfUVQsNxRRyg1Fy9q6H2Y6YmL+/wfmYlV1T8fEvFW+QObNPCTck+dy dwcMghFgMAx5ztcYhGAkw3EsTaBfBgujpD+azMoZKczhyNc0C6F0JNsYjCcjrZLw4/BXvD2E UJGCbu2do/MwbQg08hWgMBaQh5vTab/b71e9DId+CSgVb63dg6lrg9GonfoaUIRNDx132cpK SbmQjXqv/0Ewb8sg+HeDQBC6BSHv8snD9xBI/aAlwuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQ BE6QNE0RBEl5nINgFCdJHEFQnGI5lsIR+D0E8iiawj1aImx25D4uazEGB4Yh7wTLZBJRH4kg GBuKhvlQPJGIhULRKM9iMIzRwWjYR5FsSExn0wLPYAhKBSKREB8REwJPo/AdTEva7skZl+Ic 6AOGUTqcrWu6rlXTPIXR0Xy1rBQb3W4tL5eqSpxBUToqVxQxyEvF9kDvtxWBw4lAqlQpKBVV a8lhErmD8VDJcJ+cWTMdAg9BqGixv1jb9srQZJ4OZHtz435orKyx2hxM9WKYJIL5/qSbT2Rb E8u218tRTeTYeG08H+vj5dpoJ1gUglBGbJjuk7seFOMsTvDK0N7ZpmlvLS0djJQX7smeL6zl WG2N7HU/7eMk1bLvK8XOYruxTGvzMK3E+FR/6+5Mw1wZapJDoTsY46T67HC9HmZ10edLdh9O 24mmzbaOWROF+sPr88Owo6r1QkGznUU1HilM9xu91p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3m B8a5eGlgX57dRV2Kl4zL47pXrQ3s866XTTS3b9d5NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23D cRfVRH58ed1psiQKEe426YA3dCjTXrgv7rSaV73W9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV 2X53X6lOL2+nWafZnR/cZSOtjN1HsxxmQBrmaZLHYZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts 2o92I0J4vCZC5fnxYC13R6slV+bP38+m3tNna3tcTimj43GUYT36eOoJuE4QGIoxQnP95M57 4+O3p7WutlStryqi1FifrQqPecOFsKnB/ul6vTojRSrNn785s26r3e1rtbSQHx32gwT9KXEw xgR5P02QQWV2viz79/uXs9HMZ7M5OSOE4o31ySwHbyoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+Tk XDISke8P255EfYIiVDijZIVQMF42zq6hdq2La9TToiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8 L9nbP276iiSIyZQYDsv3+60m/gJlpLquq9Vifbi57PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ/ /HB7CYaKVM2TM1dL+UIZjFfsP6AJ1dzYy7m1P5/mVUmqzA6nzWI8mkz6JUmsLw9GMfAushDm z0/P12UlRGBcSrNPh9V0NJ6OWllB1jd2R/jZKUxFK5PN8XRyzweznfD7xbqxOzp7MC7DkhAr jS095/tQbpiKNw2zmwS7TPDyYH08HnZb22ino2l1YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1 suZ6LREMJhvdqsh8nDGg1VStnuMJoI9USO5MrfXKnHSVaCBWUFu5IO5JsGcQgnPRdLHebFRy MR8QR4yNZsqNZr2cE/wUFZRSgp/47AAhA3FP3CBQRgYlpdZs1gopwHkumkyEvfiHAYUl2UA4 EuY56qbLKMkFPddHAaEkGI4hfp7bYAJohgSCeWuG8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J 8BQMJzwXSDqYNqDsP5OBD/5kbi6oQj1d99a9+9/y3gvAkfOrFBxD//Z+Qno3v638X94/+3vn 2QplbmRzdHJlYW0KZW5kb2JqCjMwOCAwIG9iagoxNDA4CmVuZG9iagozMDMgMCBvYmoKPDwg L0xlbmd0aCAzMDQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MTI0IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBd IC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBtVfnk9pKEjdKSCARJITIIHKOIuySESxRgIi73uB6ZT+76t3/ //16gI32q3t3rpsPMJrp6V93T6f59Ok0DBgMA5oaXqefztPT8pnszS/s4TAup95s/LdTjKCM FIHADRhhpGkKxxALtGw8LX9gCFQUbWY5jjXR53MfCP75J0YwVruFJgAbI0y85LTSOJIDpy28 naVOcrzhBsg0J7j8ciQi+108SxMfKd4Q/4epgTA5/AGJIwEPZ8RoPhu0IUADYXYGQy6OfM/a gFOsM5QuN1qdTqteSgUEE5L6fxqgniBnkj4LYBtIW/R6Mqr4WFDcQLDeVCHhZt+xBnKbP3s9 nGnL1WqlTftKRDC+l+6fi4FRtlBByXgQBMa4y9rj55u0gBTHTe5MvZoQafyVmwE38rIyXG7W 2mw6my/X2qDgMb8heCX95Qz574uVwLKe3FU94aAxUNsa6d3/9WNX9yF2mFGIN7pV2frG6iCp XJ9ut/N+o1wsKdf9Ybfg/efYGEFSJHKm0wCAxHVXCVqQ2kZnYf7Hv/56UBN2dAM4668M+gW3 6UUvuAdfZbrf3tSSAZdT8gTj2WxEZPBTOIJKKOggTE/hhxAu6ygaDfCNkSarnQPnPOkOzAKK 2s9LSG2CC11vvnz9+qRVPAwYHTOKmf6kGbUhN7xIKmaG+92oFODNtNHIsDbRKbAUDjFHGykj Y2IogiBpM8eZadAPw0maoWnGzKJPDCM5SY76HRxzimKMElK9WfekJ8wzo91hu7vbdqNWpDhh jbQWN0UXCHYeOBu8Wh/nFb8FTiMFSSNtJHGCsYmiwIsen5vnWJsUkMMByUoTuNHicEmS2xfw QeCSFOfNXrerqaBkNYLhcZOvOltch1gwK2721bTtrDdY7adnPNitzbWmzBFnaANpTwwPu07k FISQBC82pWyBZDoeS5erxZjXE87XW+1GPsQzFOdJFgr5QqVWzYUEM+vKqtu91q+lPChyCUu0 u14oyMSIcX+zauVK6lZvhS8OUJxuhin+YnQDJRbmd0vFjW7EgIPjGCnwHZxxZduD9lV7NBlU M5nqYLZcr25qYbtZSLQmE7WvjqdqNSI6ws3t128Pa1WRQXgDJWTHu1lRNJ4CrDLfT0ty9Gp1 mOREiFoDyWdudvOS6xLBGO1WVrfTrEAhTzRydodTFKwmI+uvLbbasD8cq41SpT2azlf7/aTk sbkKs9vDvN8dLtZjJeSJd47fv93NO4UAXClGuyracZIBxQyEJdLd346LcqS2/Ly9DqL8Qljj 6l5v+E3nC8cYT12/HafsJDgiZfXGc8ViJiyyllBz97DpV8uVUjaVU+rVWkc7btsRh6eyejgM y5nyYK33Ul65rn+5n9bPuRAz+Rr67U3KTpwCbPHladUslrrbPx4nGZRfQJ7efteRkTvAwBgv YE/SCBtnnMmr0VwbNyKCLdTe32vViNcDIxAOhyJ5dX8cJiWfsrrTqiEpUJlux3mvNz+5XV9F RI6B68bNwdb2OIxbCQi2YOv4/c+7xehm9fDj+66B8gvOyp39oR+1nJ0NzATM5gV0RbjJle1q t0+fp3kXL7e2h2HKYWZMZs7mcLqDOfVwN067fIq2G6UFM58cbGYlj5RSt7OSiyEgSIB3qLM/ DmIWAgXY+OnHt4e9vjk8/fnjYYjiDvbbu6MKsp30NlCO/OxOR2kPrksIl/vrxy/rigewdb0V YgkMJ4ys4A1n6pPbz5OM26csNr2ohYLrXM/KHhGceZJ3UCdmSK/dYQB6oQBbPz7uF5PxeKId nh5RfsE/YsP9Dw4HNeWgcYw0C4FMd/eoV72C3FwtGz7wCig1fDBTqbdnx7tJFrDnejdiobhw ez2veJ2APX3BRjY/DGJWAgXY7jC9Luay2VypNT9CfrGRZ5sju5xERemgtrxdX0cFE0UaTTZ/ Rfu8PmMval6IPPDAULndrtf7+mGcdfufseX2CmHH+2B6iUYp9hP42pV+GCasFFSw2W5WlSUB hhSpL3Yov5DcO18D1nyitz0urpIe3sJZhGB1eb9WkN7LRRUlCYyW8oNpr5y70vbTvC+gLM56 n7HFWG+zbATtZkiqpxhbHm7SdtoSaet6J2qnSZKkGD7e09eQX4wQYwf96jnGwKQmd34EualX SUdlOV5SDw/Lspt/wcbN/rqmq+Xc9fJWq4bDtXfYQri12Q1LEb/TgnKLIzfZQSJhHZmhPi2d EhaKH095qqsZh5lP3+wXldeEDuXAV1RX2/VM7bRa3cnm/m6cddqDV/NpBR1Gl6Ltps1ab3O/ bacTtdmyHeZILtRcTEpuO/j9QR81y3EJaiNhjfX0edltdeUGrxUL0musNRnkJItUmG5HGeGl kIHVLd5McwxJc6lpq81uM63LdouvfKmFyObD1ULtqKuD3ssny4NRLcCSZp8y7GWdnCPZXW31 2bnmIxvN540gLyWUWkpiLpUagjdVU+JOu686X7bCz7UEHM6AkawzXLjuDceTyXg0aBbDDpNJ jJeLYTtkWoy0Bkudfqve6KiDWlJOlJWkxBCMmKgUZRvNujPN0Vi9SiG9oURn1Vk77uBdwaDE PncoACAFgy4bH2nOb55v4uzqqE21SsFYOl8s5jNxIGJI6B79PgfqGSHL27yxVDIajiaTYY8o nbpQHAq33ycwBLANp/PZmAfuG0q0RW7c9HMuDtptyHSXJgG0Y6D9ZsVUd9yMvfYOJ3gDdASs lRedTpG3sqgpwEmGZVGeRNWNMtsE3ma18bDJmFjOBD6NUyYWNdPA1iKIDrsZ1iBF01K2M1CC Vmg4UNRdBrQFBEGx3mKv+7ZnerML9dNIkeczJ+rLadRQUCQJ7Qv84MAFrT8TGKDwUlB2zy8O UDxY7jQSjp8bXYyyR6pt5V2v+Cwb/EPn8CLqm+Xzzsvv+x309eYcNIsxpZ71mN+14YgIN0mp qhKHHvlvMBDRbw14lkjxQtpvefazZ25Q2TzJfML9s1DPFL//j3xalt0f3z7ghmZnSHb9JNPv I77hABXJLtiYjzZHb0GB//kt+Obk709PD99fPHbRSxca4P/XZZ8Fh073V6/4v1n+fWXPHP4N C4hpJAplbmRzdHJlYW0KZW5kb2JqCjMwNCAwIG9iagoyMzEwCmVuZG9iagoyOTcgMCBvYmoK PDwgL0xlbmd0aCAyOTggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMTA4IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAg MSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBtVZZe6rIFo3KKCCKaATEGXEeUJw14ggqKE6JMTknfU+f /m7f//8DbmFO0t334b5lP+3atWsvitqrVt25XG6PY26323X3teZyQ6iXIEmCwFHY87VobpgI 8rFEIi7yIRqHv3RvHpzNKL3BoNdpVjIRCvlKMA8ZU43D0d5aG31YjlKw++vODKIz2uP3571l 7U/2rMJ5PV+I5ZcX19ed1u1Nd0+HB8kPf11/QIHc4nKelBLJkna4rKohFDT/h7kcXNdtBLxP 5937nAOsudHm11G/c8gZOBM3A4RysgHW/NHuxP200DAvViOCeWAUQxEU83oxGCR5EAz3Onxw A3ZgIOS6AzHUIQjgC4JhCAQhOElRhDPncnlgzKEQBgMUZxqUAusRCKDdsHbtKEVy9dV5o9zj CBkMs0wwEhXCPgxGSeZeiPIhvxdBiECY9aEeN4T72SDlON5AiKW9hD8STyWjoVsIo8NiIhEF ayGQFwoFmRAf5Rgv5HawFk+HoRThpJ51mBWCmDecKeYludJsFKIBHyvmas1Wo5Lh/VQwnpdF GoEwNlnIRX0whIdS+azA3qeqnX6vmRd8KOxlk2W121WLccaLB2K5QlYqKGotzWKeG9b1uu7W lOHmtO2nfJgv2Zpo/Z62XPTyYlRWxwvD0OfDWjISLfYGFZ5A6WR7NgYti/rTraGajWXbS9Nc zTpymCDCcnuqG8ZSU9MszZWHk2F3ONe1epSEXGBfy2+/X7cr8/TybLZiFBbITw97YzJdLIbV XGWgm2tdX1nmXM2maxNjJAepSG31fBpLAYqvz41+Xmrop6O50LoFjmalnmEas5mxWajJSKK9 OZgzbbbUFJG6Yelv//7xfH56fXvZ9qUgyZZW18uq11AatXJ9tLaWg6bSmZi7hZqvapbeEMPp 4dMfP6x6NCwNrVVbkrrby37arhUTIUZsrvabkaqON7tZNZEdHl/2mgoqSfeAuM6+vv98tdfr 7eF8WKoJNlLZvDxOijFeiMttY6e3JIGLl8fb7bha6q2th0K6qn/784/HUS6tLHezsphQrYs9 rmaiIZrNaqez3iqWOsbR7Mj5h9PVVNMCz4XA7XfDenkxB/Wq0ptv90slHq2un3dt0YeTrDTY bocS48Uovrbc681cfbYzes3R7uW3t4vRaY4ts5cK3hdnh6PeyQkBKlw2wD/p1mo942ANCsWH w3mWZwkcv3HF6cPL8UHmQveJ2vx01ArJunE2KoDTsF8a2+smj3tu7m7TluSeaa8Wm+PRBjea sbT2y2qE8ImNpW3rvXyE4RXr23UzarcH89VclQsj2x4kSMghNCAzwJo/An6RKOZP9g/PKyWr 6MdFgYHvIDqr2av6PQp2T6WGO7OdjFWX58vlcjJGmvkIHHuYoRE0kFSm1n4zzAux5vb1Se8q NUVtK3IiN9xanaj34zq/YW1bAgEjVLx3fDGbsqLvZ/kAdOfxpR9ssyWSMIQyOQ1sMRrODE// +vlm90u16dOPn9/MBu+FEDKUqD5YJ6svpxvr56NWzSSTqXRC4MAZbFoC/jcswOVBJuRn+ML0 8bqqSwBrmnOwiFjHtLUiR1NMQl3tF+UwzSnbH/95MyqxZHv/88+XqRwA9A2EhXR9fnpc1jKV 2emgleM8J4giF5EG1kbl/4F1fTZaBTlff9iBk8sna7+w3Fi4PLPNUUVK5dS5bQ3SNB7Izl5+ fxqlguGi/v3HsSMSMMbEJLmgTE/PayUpdc3DqleSpFwhlxTl4T+x/PL8+va4nmlTfXc6zKui UJ5vNdkP3bkgX7yl78z5aKAZ2+2kHMFhr9CyHlc10BDxnn1eFFkEIrhiZzAYb87neYnnC+Pt fj0dDkajdiEp99dGg/trX77U6Ph6Pe13u912Pa6KDCsPF92UD7q7c2NMpr2wLMu0rLVWdUQb YeT+tJOmESxUHE2aMQryeLnyaLk27f2qnQjQfFkz7Z21WYMbLpZuTrXKPfZxXh6Cr4yN9Upf zrRBU+Z9uE+sNIs8AfTZ5cGDyVof3Fbzcbsg+MBjxENwclkK4x6IiuZLqSBQOzSYboxmi4Wm ZoI4SgnF7nS5XEy6pViIk5VaKoA42uWYG6WFbKlSKZcK2STPEDCEBYQYR4NGd8Awmkvly5VS NhYinXePG6FCHEsCcULpcAQohcsFedmYXK6WZZHBIQ9MhhP5SrWcT3F+whcWoyzIuSE55VDS z7BsMMj4KRxxxBElKAJ9fyoC5cN9DBsK+knUUTuQjuCODgJNRHAvBkTpzg1hZIANswESKBqQ T4wKsCGW8QF9RLwkCd6Bv6DAarcHfjfoXapBAHi/vgWoOAQjCAJk+T1yU/gbqqP7tyCoDyPo R8rHCFwWTqW/Sn0i/j8HCPvHX3DSPkefzi32t5z/WfBZ+793ykPgCmVuZHN0cmVhbQplbmRv YmoKMjk4IDAgb2JqCjE4MDIKZW5kb2JqCjI5OSAwIG9iago8PCAvTGVuZ3RoIDMwMCAwIFIg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0IDM0IC9D b2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1 ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 AZVVaXOqSBR9siiouK9xATQuuEcF07gLCqggAiaa5KWmZmpm/v8/mMa8vJlK1atJ7qfeTt/b 9557+ts3D4KgV0MQz7evmAfBvGQgCC1A+jD0K2APSkYyRZZlmeJNMkziX/CMeCN0B0ynkzEY tstpyot8OmaESHdk62SbhrFXJq0chX8ai/rzo+Pr95OxN6yTuWpnSPSzbtFAcey8PmwAD2Tz bM1uI/hnU4UG6LFz2Q5KObq9tC/bbopA3WL9rNR77dwFj+daxx+pdKHWaVWLB6jcQH8yR/kg 4Q9SQb8Xc88iKE743doFCBxeiRNwDIdX8Bt0WYn4yHR392SJbCKZY0pMLh7AIVe8gWg6TzMM nUtSPpwMpwoMk0+FCJcALtR+XDczkTg7OjyZoMpyA3E6HtayFI75IrlqlxcnE9CvpCkqybZ5 APgmHSMhFkInp5fDuFltCMrpQR02uhNFP5j7eSsTICN0b7bZmfbJlHrFZLY2klRNU5Z8OeZD rtDH318MaSHt7NMONDl+pW731oM5rcTC+TtZN/Tj5fWi9pl8TdR0TZa1/YanKdwDvU4vf//5 bJtHy1Tva8VSRxjxYO08at2bdHVm6NJkaVwe5HaxLGyt/YznF3tTbiV9iBvw+a8/zoamSJMe m4ym6DLL1oBxPgh0vr02FZ5rz83jnKMbS/ggodm61xxdyPtRF/rw2+Pmvteul7JhkgjGUpl8 5V6/HEGp0Fkf5F65PtaNSY3pac+XLej1RM02AB10oVdKsOlElCJxFCPCabrWWxyfbVDKcQtd E++G0mE/KjMD4/V5PxuNJuvtelAIXKFXSpBeWHMEwalstceDlflkASbFCFtzt1F0Q+oUioPD 97MK+r0+P+pXkuQb1FmUQ9iV9SiZ5sBMFMbayQR0LNOWnUfH3EsDOpHt7Z6cZfeWZUtlJhv2 umkaW868HHprGCxUAqoCOncr+zhmY8n60j5b6qRLR4NxTj7ZyzZ9k80VCunQR6gHj3GStRfb d5LjLGvpbFOyHU1s0nHSR9H3ur0VW5VKvVGnYwQMuAgOx2mJunr14FFOcsyVANTzRb1j2b72 eFJGjWIi6COT3OJg7aTpZDYb1VMkivhv+htVKAbfA2bF/UGdz1X7tL1vNMfm92dTAt3bbNhP 3bSX+tE09ruNWE+SCOJLVIcClyLfdAUlU3WwmANBXMpzvsuvnZdnx9DkSacY8YdyTSApymYF Wnn4VgQPpop05l2SEDyQYutctVSuNhrN/kK3jrvNRoN07GYDRDDFcJ1um4Pc8aGw73GSovze dwWG01AsHg2Ho/F0aaiYu9mgcyeqljkth3CMoKKJZCIWgtyBDQuFAMPQH5rxNsW9OIbhPio/ 3B43g1vYEUvLkWoR2PsY7vXB3Z/y81ECPZ7rlUS6qxyUEXdb60vH47wSdlkD9/5f9hBvtDLW titRAAvNUIaQtR99/GruQf2Zhrhay/JaUVZvwvCrsx/XYfIzt10BKpPIt5i4K0efNgT3R7N0 uVIpFVJhAvv0jwIdwOR7yWA4Egm5KvwFn25wrvRj0P4t3n9C/geMOdXcCmVuZHN0cmVhbQpl bmRvYmoKMzAwIDAgb2JqCjExNzcKZW5kb2JqCjI5NSAwIG9iago8PCAvTGVuZ3RoIDI5NiAw IFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNyAvSGVpZ2h0IDI3 IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUg dHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4AWWSbVPaQBSF2d28kpiikYoN0GAtVhuJqSjQFqQQTQBx2CQ0xOkICDM4jv//cxcxIep+ SXaTc/c8595EIlwAkgVAuI09AaI5nqXg+28AsVJ6RxZoGPt99QppKXekFzMC9U6Gkhm93akf yOxbGaBT+03/DldzAnojg1zGuJk/jq8Ot5jXMkBJhbr/8DTHZ0oSvTIC2fSxdXs/m/p/iik6 XhEgMV+98YeOP+r92OXjFSGzddh2B+aF7eHGlw9xGUoq5Wv36lSr9Ye2/pFby4jzr00XNw7U 48sh/qVurLGXzq8D/Luofm/9DWxtO8IG1MZew5+OzLJe6fybej/zEfbSeW+ymDj2ZXc4e7iz ImyAhHzNmy8mIxe7wf1ihs9DbOL8mxmMg0HXsqwevh2vsVHyU7nv41a5pGla6bzt+CH20vmF 4zSPlG1ZltNZreXg+gobcjsnHa9j7AoMTdOMqJx2vRdsJH6u9geN/VU8zzUG/UpeRAnSjr2a bZ6EoZKbDdOqFSQKEN6cXjHUMFPIpApGpZQjYQHEy1lV2eReGggQt6moWZkncwApXpQENpoI MnWCJHIUSR9ARFEoNpnRwX8Oy0SuCmVuZHN0cmVhbQplbmRvYmoKMjk2IDAgb2JqCjQ1MQpl bmRvYmoKMzA1IDAgb2JqCjw8IC9MZW5ndGggMzA2IDAgUiAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDEyNCAvSGVpZ2h0IDM0IC9Db2xvclNwYWNlCi9EZXZpY2VH cmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVu dCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbVX55PaShI3SkggESSEyCBy jiLskhEsUYCIu97gemU/u+rd///9eoCN9qt7d66bDzCa6elfd0+n+fTpNAwYDAOaGl6nn87T 0/KZ7M0v7OEwLqfebPy3U4ygjBSBwA0YYaRpCscQC7RsPC1/YAhUFG1mOY410edzHwj++SdG MFa7hSYAGyNMvOS00jiSA6ctvJ2lTnK84QbINCe4/HIkIvtdPEsTHyneEP+HqYEwOfwBiSMB D2fEaD4btCFAA2F2BkMujnzP2oBTrDOULjdanU6rXkoFBBOS+n8aoJ4gZ5I+C2AbSFv0ejKq +FhQ3ECw3lQh4WbfsQZymz97PZxpy9VqpU37SkQwvpfun4uBUbZQQcl4EATGuMva4+ebtIAU x03uTL2aEGn8lZsBN/KyMlxu1tpsOpsv19qg4DG/IXgl/eUM+e+LlcCyntxVPeGgMVDbGund //VjV/chdphRiDe6Vdn6xuogqVyfbrfzfqNcLCnX/WG34P3n2BhBUiRyptMAgMR1VwlakNpG Z2H+x7/+elATdnQDOOuvDPoFt+lFL7gHX2W6397UkgGXU/IE49lsRGTwUziCSijoIExP4YcQ LusoGg3wjZEmq50D5zzpDswCitrPS0htggtdb758/fqkVTwMGB0zipn+pBm1ITe8SCpmhvvd qBTgzbTRyLA20SmwFA4xRxspI2NiKIIgaTPHmWnQD8NJmqFpxsyiTwwjOUmO+h0cc4pijBJS vVn3pCfMM6PdYbu723ajVqQ4YY20FjdFFwh2HjgbvFof5xW/BU4jBUkjbSRxgrGJosCLHp+b 51ibFJDDAclKE7jR4nBJktsX8EHgkhTnzV63q6mgZDWC4XGTrzpbXIdYMCtu9tW07aw3WO2n ZzzYrc21pswRZ2gDaU8MD7tO5BSEkAQvNqVsgWQ6HkuXq8WY1xPO11vtRj7EMxTnSRYK+UKl Vs2FBDPryqrbvdavpTwocglLtLteKMjEiHF/s2rlSupWb4UvDlCcboYp/mJ0AyUW5ndLxY1u xICD4xgp8B2ccWXbg/ZVezQZVDOZ6mC2XK9uamG7WUi0JhO1r46najUiOsLN7ddvD2tVkUF4 AyVkx7tZUTSeAqwy309LcvRqdZjkRIhaA8lnbnbzkusSwRjtVla306xAIU80cnaHUxSsJiPr ry222rA/HKuNUqU9ms5X+/2k5LG5CrPbw7zfHS7WYyXkiXeO37/dzTuFAFwpRrsq2nGSAcUM hCXS3d+Oi3Kktvy8vQ6i/EJY4+peb/hN5wvHGE9dvx2n7CQ4ImX1xnPFYiYsspZQc/ew6VfL lVI2lVPq1VpHO27bEYensno4DMuZ8mCt91Jeua5/uZ/Wz7kQM/ka+u1Nyk6cAmzx5WnVLJa6 2z8eJxmUX0Ce3n7XkZE7wMAYL2BP0ggbZ5zJq9FcGzcigi3U3t9r1YjXAyMQDocieXV/HCYl n7K606ohKVCZbsd5rzc/uV1fRUSOgevGzcHW9jiMWwkItmDr+P3Pu8XoZvXw4/uugfILzsqd /aEftZydDcwEzOYFdEW4yZXtardPn6d5Fy+3todhymFmTGbO5nC6gzn1cDdOu3yKthulBTOf HGxmJY+UUrezkoshIEiAd6izPw5iFgIF2Pjpx7eHvb45PP3542GI4g7227ujCrKd9DZQjvzs TkdpD65LCJf768cv64oHsHW9FWIJDCeMrOANZ+qT28+TjNunLDa9qIWC61zPyh4RnHmSd1An Zkiv3WEAeqEAWz8+7heT8XiiHZ4eUX7BP2LD/Q8OBzXloHGMNAuBTHf3qFe9gtxcLRs+8Aoo NXwwU6m3Z8e7SRaw53o3YqG4cHs9r3idgD19wUY2PwxiVgIF2O4wvS7mstlcqTU/Qn6xkWeb I7ucREXpoLa8XV9HBRNFGk02f0X7vD5jL2peiDzwwFC53a7X+/phnHX7n7Hl9gphx/tgeolG KfYT+NqVfhgmrBRUsNluVpUlAYYUqS92KL+Q3DtfA9Z8orc9Lq6SHt7CWYRgdXm/VpDey0UV JQmMlvKDaa+cu9L207wvoCzOep+xxVhvs2wE7WZIqqcYWx5u0nbaEmnreidqp0mSpBg+3tPX kF+MEGMH/eo5xsCkJnd+BLmpV0lHZTleUg8Py7Kbf8HGzf66pqvl3PXyVquGw7V32EK4tdkN SxG/04JyiyM32UEiYR2ZoT4tnRIWih9PeaqrGYeZT9/sF5XXhA7lwFdUV9v1TO20Wt3J5v5u nHXag1fzaQUdRpei7abNWm9zv22nE7XZsh3mSC7UXExKbjv4/UEfNctxCWojYY319HnZbXXl Bq8VC9JrrDUZ5CSLVJhuRxnhpZCB1S3eTHMMSXOpaavNbjOty3aLr3yphcjmw9VC7airg97L J8uDUS3AkmafMuxlnZwj2V1t9dm55iMbzeeNIC8llFpKYi6VGoI3VVPiTruvOl+2ws+1BBzO gJGsM1y47g3Hk8l4NGgWww6TSYyXi2E7ZFqMtAZLnX6r3uiog1pSTpSVpMQQjJioFGUbzboz zdFYvUohvaFEZ9VZO+7gXcGgxD53KAAgBYMuGx9pzm+eb+Ls6qhNtUrBWDpfLOYzcSBiSOge /T4H6hkhy9u8sVQyGo4mk2GPKJ26UBwKt98nMASwDafz2ZgH7htKtEVu3PRzLg7abch0lyYB tGOg/WbFVHfcjL32Did4A3QErJUXnU6Rt7KoKcBJhmVRnkTVjTLbBN5mtfGwyZhYzgQ+jVMm FjXTwNYiiA67GdYgRdNStjNQglZoOFDUXQa0BQRBsd5ir/u2Z3qzC/XTSJHnMyfqy2nUUFAk Ce0L/ODABa0/Exig8FJQds8vDlA8WO40Eo6fG12MskeqbeVdr/gsG/xD5/Ai6pvl887L7/sd 9PXmHDSLMaWe9ZjfteGICDdJqaoShx75bzAQ0W8NeJZI8ULab3n2s2duUNk8yXzC/bNQzxS/ /498WpbdH98+4IZmZ0h2/STT7yO+4QAVyS7YmI82R29Bgf/5Lfjm5O9PTw/fXzx20UsXGuD/ 12WfBYdO91ev+L9Z/n1lzxz+DQuIaSQKZW5kc3RyZWFtCmVuZG9iagozMDYgMCBvYmoKMjMx MAplbmRvYmoKMzAxIDAgb2JqCjw8IC9MZW5ndGggMzAyIDAgUiAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3BhY2UKL0Rldmlj ZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9u ZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBZZJtU9pAFIXZ3bySmKKR ig3QYC1WG4mpKNAWpBBNAHHYJDTE6QgIMziO//9zFzEh6n5JdpNz9zzn3kQiXACSBUC4jT0B ojmepeD7bwCxUnpHFmgY+331Cmkpd6QXMwL1ToaSGb3dqR/I7FsZoFP7Tf8OV3MCeiODXMa4 mT+Orw63mNcyQEmFuv/wNMdnShK9MgLZ9LF1ez+b+n+KKTpeESAxX73xh44/6v3Y5eMVIbN1 2HYH5oXt4caXD3EZSirla/fqVKv1h7b+kVvLiPOvTRc3DtTjyyH+pW6ssZfOrwP8u6h+b/0N bG07wgbUxl7Dn47Msl7p/Jt6P/MR9tJ5b7KYOPZldzh7uLMibICEfM2bLyYjF7vB/WKGz0Ns 4vybGYyDQdeyrB6+Ha+xUfJTue/jVrmkaVrpvO34IfbS+YXjNI+UbVmW01mt5eD6ChtyOycd r2PsCgxN04yonHa9F2wkfq72B439VTzPNQb9Sl5ECdKOvZptnoShkpsN06oVJAoQ3pxeMdQw U8ikCkallCNhAcTLWVXZ5F4aCBC3qahZmSdzAClelAQ2mggydYIkchRJH0BEUSg2mdHBfw7L RK4KZW5kc3RyZWFtCmVuZG9iagozMDIgMCBvYmoKNDUxCmVuZG9iagozMTEgMCBvYmoKPDwg L0xlbmd0aCAzMTIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg OTcgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0g L0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAG1lmebokoWgFuiSDKAgigSzDmOCRUVFUURRDvMc3f//8/Yonee Hmf37rfe86leqk6dok6qlxcgEQgGAkGREL5fIjAaJWmaiuHI/8UEhETZdF7VFYmjMfj7fyKC xHi1PVksjVE9x2LQd99QBCb48nTver53WrXFGPzdBiA0rs+c2829uO7hh0Ij326AELp2cLWm o4lh9OTvNwBThZkX7LqqlNfLajqGQEAikZdI5HMA/gcMPoMYfPxb+BXdT6H+pRHeBkxryyAw yxxFsckEiSFoNIqBcIUQLIqjMLADYwRF02T0vwEJZygCg8GJIASPgVAPAYLRLw1ggFKN4HXX zJAYEBTBGY6PEwiEEHE+ReMwjJFJsaBpcoaN/gEIjFGpbEEtiEkSBaeguJyiFcREDEWJuFDQ 1BwP1CMvUEwaXd69RVWgQZ5BKJ0tVeUEDuOJQrUkUhjOZCv92cIYN+V49A+IslKlN5mOeyWR DpfVRrP5uKNxJMlpncl8NqxJDIh6CEtV18G7Z3YKqRg4VbI8mbfEGBLLtufjUirGyl3zeHEv tlEXmPgzJOTucn882jujmWVosWU67vmw6hVSnD4+XC4na1LhCfglgpDZthW8B/akIlAYkW5b 9limUKowsbctISF1Lc8/23vLaOb4/BNwue727OytvXNa1QW+uPDf/KO17KuZXNd+3C/79bQu hGkFbkVqmde3t6vZytKU2D+6hkpjtLZwj/2cWDU9/zDttdsNTczWn6EGYDcZTPfeeVrMN3bv 744xaJeltDK+fty2425DSUXDvIUwWqhOjo+PYNsSE9LAuS4+DSyvp6GiDp3AHqgCn8lwXGH0 BPIQuG7VqffWXrBtqo3t69txXFOERDw3cj98s1PMcRQaVp4IhMZSSm8b/AxWFSE/fDagVwzv amjAvXg0Ftd+AwHg8dfNHHSGm2uwaxeKU/f1anZUnibTDSu425OqFI+GtTPMChCc2cb6/nEe KsqzgVGpsb6dhyIB8gJC2dITMMX1xz/v1vTH1LSPi1o2W1tebu66pyRJRh4cfN+e1QQSgV5A M8BxFEFJsWO/B0ZFHzneUgM+0JfeaVRubm5OP4OHf4qw5fVvYIqbj3945rDbG45HTTkZF2vz k+/tB4U4mVT7W/d2XtR44AMIJRNJNoZHEyXzfjdr+vDkmyU2Co7rO6Ni3fTdSZ5CQbHA2OLq C1BGXz4+nHFVUzRdy3M0Fc9WxocA3JZI07zSWbkPd6YxCKjWnFJSxVRCqK3vwbKi9o7Brplm hdbhcRlppdk12DRFlgKSUJ8gXhi7r864JInZvCxx8TgnyLUZ8O5c51NpSe/tHm+HBodFYFJq Taf9RqU1cx6XH4rU3AXnaVmpzP2f16Esdw/366pTUhQ5m8n3fgMvtaybt+lXi+VavZQTcnql 2ppdfj7MmqyWKvX+9vHT6aRxCCZzfcs57jZ7937b1DOcNnd9ez6a2W9/XfpSWpueA2+/nE2G tbxY/A25jDo63q6HlbFYGb1iodyfG8ud/+7Nq3oLVH7z/Pq6a6QwCCLS9aXj327B/Wr1cgyV aZrni73dHv2b1UwzfGV+8jzXsc2unMo8QZLXJ7bvXy/n47qv58s/rOP5ertu2orSXh6ci387 jRXggzCRG5PN4XjczVt5FsdoqTlbrxfTmWEM1Hg0li4NVrv9fj2pCTT1BBSZ0gervX2wlsOS wOUa083+YBmtPJcuDpYW0BgVw0yOwBidLlRanXZdyzAYCBY6o1brFV3VtHyKQBAiIRUb7XZd Fxkc/QOiCanU7HSaZZmjYqyo18EqTWAIipPBfq1KPkkgn4mGRKk4x3NJmkDDzoESTDKVZGmG oaKggMNYjE3xfIolQS/5DyA/Z+IUjiC/VjEECoP9ElyaS1A4/O83Cmha6Gez+Xx2AUJQ0HlC Aa0qfPUBxrC/h7BLhTPhKgzHf42BAo6hofaXRIB8AWjITwA+/zH7P+FpIhz+2uJfp/AX1wpl bmRzdHJlYW0KZW5kb2JqCjMxMiAwIG9iagoxNDk1CmVuZG9iagozMTQgMCBvYmoKPDwgL0xl bmd0aCAzMTUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AaVYyXIbNxC9 4yv6SFZFI+yLbxLtbBXHiqSqpCrOgaEomQkXi6Ti8t/nNTBDgiIpybZ4gIjBoNHdD+91855+ o3uSpCUpqS0FH2k5pt9pTqeDlaLRihStRvsrbkk2XuY/mvBaLbBW5s/h9WxISUneJYra4P9U mdLFlMrmRL033sq7nuAZXucTjmZ0fk3RlnmMysZGuaQpGrqe0en3qoFDdH0r/qTe4N3l1as+ pUQ9uhzfP4xX6z79Rdc/05truH80APUhNg42TqrkZYT72skUJR8CDmup+RSkdCSjFHt2S5o+ kaW3OTw0uMKJ+HM1EJVP8Chmj3gHo1O9w1V7vNOzs4tfXl2tP0/HdHoxVXT+epDPXT0YLObr 8Xwtzt+2jy7Gy9H44/phOKXlhGOvQo6XsThsJI14II6nP82co9eL1tKb9u0dRIhDiKhc0NKQ dV1aTAHBCcaQQ7KXkPe98/d9evNfnxRygkP36UR5ZOdxWrrTVG5W/iOK1YPWfzrqP2DHJ2P3 TSDtbee+h/ui4KAzuON+hdLthXiJ+8Y1xrsAYEQjdqJAvYvh3bhP1/9sMfik7QqLgrHIt0Ue w2KASadD42iGS+KRm0BTSrjjZXaaZ12KYkofqF59HLIMoBw/XMMNZPlV7XEOmgk2ZIxqDZXZ YkglidliqF1NTyEbufiyzEaXT4abx9fRwc8W2EE8DeznMptDk1pgiwrYxjZSWR8oPOIbAt9c jZcANFb3OoTzd3BCB3Cx4Z0u5xWOK4C/OAwiX3BdEqQDWBBJj74LQ3zmftdhYBbPjF/leycM VIXBu8Y5p8B6IJRHAD/vi69Bd+HKIiVbfIuWYR0Igxm21Y4vhGvmaA9hKDswrT2FwyMMe4hh SgI4Ckwx2F4rQ65QIjNs+sYMMMN6JLYIX5UBpRoVDFQPdLabAADxfNkX0PTeAuJHvU8rxuWu 7nX4O8h3rlWvDfeIIvSdkkko2WFa8LHRNiAK1jUxQRVnkG3XBBdUnvMhgXqYLbQMTUrJgyA4 FR21qUw2SHpwqQkJCuWMblxKTGkhKnKWmSZ4BQD6JJzTTdLG5LnWkLO6MbgTmXoObHMLG/zJ 1UoWyJw88JtVvpEuWPLSNk6UoLe36wQjJqEh+/GuFI2Y3/eqDTDbJpiomqortqFUg1Nbi3Sb kJoUA/w11jYxSJWnTALbwfMohQ5gIYn5ErtNzIwNjdXgfKsQPOUs7wHMWMlvGoRKayTHpNTE CAtTsbFgZURVp3jdB9jd3+d40IxDrqNHpuS3hWz1cTFfQRtbpD6KWS4uNsSA3Hn4p5PJYhf4 5iEz0B0UU2UWscKswf2Yig87qwt7FBAcQTJvbhPnG7DDNg7+5c1FmS2bW1wyDli9+iuI5Xjp thU4D1bXG2YHlz0tcM9VbnxiDs0erxwSOMEF9YsEbr+oeSxw4ngFe4hfSwULAsz0CtlVSLpD FZQLWK++Ued3wlDrvDdgJ6dQwe0L3NkLyrcu/ntU2vZMz1Kpd2A4ECRZ0EHUzokZqD6B9GOe 0hLcyFSqCxWAHmpO2ONTb1UTZAhQcYlNwMPYDwAwmRu89U1AVWNAHMlKZuXOmAEzhGQLM+zt gutxC3jw5wCdgkccLiMIKJckaN0qMkWdGm3kfG4ZdYO0P368pPWChjdZwW5oNJyO5zfDJU3W 49mGIrJQb6pTu2tO7Jrju2zDPne/742GkEfo5HIyXtFgsfh3ghYuzyyW6ExSEr2z73hEHfdu ObmbzLumEt1MfZbnKd43aD+sQP/cGJRqTPHgXRTkhFw3XqOKReQ9qngJJTpE8Q5GtPdooLBe 6YA0GnQ2aDRYThNDwvnGeo+URNlI75kVN2ZUjA0EhhMMnj+w2XGetzKx5oKG0L8/J40lkT1O 4+W4EDtN5jeT0XA9md/R6mE0Gq9W24t0DwDxFYcIg8EhwkAmsJLNiAo0xxR40OGjkuI6NYf3 P6DwConJbe0BqJy1aBxj3C2nkM7yk4iAnuzVVFd0+gN+UrlbcZmz7STR9ZMKqEpd+dGAu5/t XMcg3Sv5x4bKDW4u2zSApkrsgBt0+wXjCCJiyrwtetdoQyL1HjBw310GRJ+/wRcehmX4XAbA nV8A+nn4tUwu+oJXorepdsFl5G9/70xy24PJ9nVTvu3uqctmsjxrh7QT1/8BkcUsaAplbmRz dHJlYW0KZW5kb2JqCjMxNSAwIG9iagoxNjI1CmVuZG9iagozMTMgMCBvYmoKPDwgL1R5cGUg L1BhZ2UgL1BhcmVudCAyMzEgMCBSIC9SZXNvdXJjZXMgMzE2IDAgUiAvQ29udGVudHMgMzE0 IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjMxNiAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JT cGFjZSA8PCAvQ3MxIDcgMCBSCi9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZSA8PCAvR3MxIDEy IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIKPj4gL1hPYmplY3Qg PDwgL0ltNTkgMzI1IDAgUiAvSW01NiAzMTkgMCBSIC9JbTU4IDMyMyAwIFIgL0ltNjEgMzI5 IDAgUiAvSW01NQozMTcgMCBSIC9JbTU3IDMyMSAwIFIgL0ltNjAgMzI3IDAgUiA+PiAvUHJv cGVydGllcyA8PCAvUGwxIDQwIDAgUiA+PiA+PgplbmRvYmoKMzI1IDAgb2JqCjw8IC9MZW5n dGggMzI2IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEwOCAv SGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayAz MzIgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3Ry ZWFtCngB7dCBAAAAAMOg+VNf4QCFUGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAwDswI3AAAQplbmRzdHJlYW0KZW5kb2JqCjMyNiAwIG9iago2MwplbmRvYmoKMzE5 IDAgb2JqCjw8IC9MZW5ndGggMzIwIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDU5IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRl IHRydWUgL1NNYXNrIDMzNCAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0 ZURlY29kZQo+PgpzdHJlYW0KeAHt0DEBAAAAwqD1T20JT4hAYcCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDPwHBheCAAEKZW5kc3RyZWFtCmVuZG9iagozMjAgMCBvYmoKNTAKZW5kb2JqCjMy MyAwIG9iago8PCAvTGVuZ3RoIDMyNCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCAyMSAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0 ZSB0cnVlIC9TTWFzayAzMzYgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxh dGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITBIQwAABqUAAQplbmRzdHJl YW0KZW5kb2JqCjMyNCAwIG9iagoyNwplbmRvYmoKMzI5IDAgb2JqCjw8IC9MZW5ndGggMzMw IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQg MjcgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDMzOCAwIFIg L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAFj YBgFoyEwGgKjITAaAqMhMBoCoyEwYCEAAAiLAAEKZW5kc3RyZWFtCmVuZG9iagozMzAgMCBv YmoKMzIKZW5kb2JqCjMxNyAwIG9iago8PCAvTGVuZ3RoIDMxOCAwIFIgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMTcgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4 IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgMzQwIDAgUiAvQml0c1BlckNvbXBvbmVu dCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QMQEAAADCoPVPbQhfiEBh wIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwbegQEu ngABCmVuZHN0cmVhbQplbmRvYmoKMzE4IDAgb2JqCjc2CmVuZG9iagozMjEgMCBvYmoKPDwg L0xlbmd0aCAzMjIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg ODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01h c2sgMzQyIDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+ CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ43iEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wMDTwAAb5AABCmVuZHN0cmVhbQplbmRvYmoKMzIyIDAgb2JqCjU1CmVuZG9iagozMjcgMCBv YmoKPDwgL0xlbmd0aCAzMjggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1 ZSAvU01hc2sgMzQ0IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlCj4+CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ43iEBhwIABAwYMGDBgwIABAwYMGDBgwIAB AwYMGDBgwMDTwAAb5AABCmVuZHN0cmVhbQplbmRvYmoKMzI4IDAgb2JqCjU1CmVuZG9iagoz NDIgMCBvYmoKPDwgL0xlbmd0aCAzNDMgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVj b2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmls dGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVtmSolgQLfbdBVfAHXFfUVQsNxRRyg1F y9q6H2Y6YmL+/wfmYlV1T8fEvFW+QObNPCTck+dydwcMghFgMAx5ztcYhGAkw3EsTaBfBguj pD+azMoZKczhyNc0C6F0JNsYjCcjrZLw4/BXvD2EUJGCbu2do/MwbQg08hWgMBaQh5vTab/b 71e9DId+CSgVb63dg6lrg9GonfoaUIRNDx132cpKSbmQjXqv/0Ewb8sg+HeDQBC6BSHv8snD 9xBI/aAlwuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQBE6QNE0RBEl5nINgFCdJHEFQnGI5lsIR +D0E8iiawj1aImx25D4uazEGB4Yh7wTLZBJRH4kgGBuKhvlQPJGIhULRKM9iMIzRwWjYR5Fs SExn0wLPYAhKBSKREB8REwJPo/AdTEva7skZl+Ic6AOGUTqcrWu6rlXTPIXR0Xy1rBQb3W4t L5eqSpxBUToqVxQxyEvF9kDvtxWBw4lAqlQpKBVVa8lhErmD8VDJcJ+cWTMdAg9BqGixv1jb 9srQZJ4OZHtz435orKyx2hxM9WKYJIL5/qSbT2RbE8u218tRTeTYeG08H+vj5dpoJ1gUglBG bJjuk7seFOMsTvDK0N7ZpmlvLS0djJQX7smeL6zlWG2N7HU/7eMk1bLvK8XOYruxTGvzMK3E +FR/6+5Mw1wZapJDoTsY46T67HC9HmZ10edLdh9O24mmzbaOWROF+sPr88Owo6r1QkGznUU1 HilM9xu91p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3mB8a5eGlgX57dRV2Kl4zL47pXrQ3s866X TTS3b9d5NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23DcRfVRH58ed1psiQKEe426YA3dCjTXrgv 7rSaV73W9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV2X53X6lOL2+nWafZnR/cZSOtjN1Hsxxm QBrmaZLHYZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts2o92I0J4vCZC5fnxYC13R6slV+bP38+m 3tNna3tcTimj43GUYT36eOoJuE4QGIoxQnP95M574+O3p7WutlStryqi1FifrQqPecOFsKnB /ul6vTojRSrNn785s26r3e1rtbSQHx32gwT9KXEwxgR5P02QQWV2viz79/uXs9HMZ7M5OSOE 4o31ySwHbyoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+TkXDISke8P255EfYIiVDijZIVQMF42zq6h dq2La9TToiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8L9nbP276iiSIyZQYDsv3+60m/gJlpLqu q9Vifbi57PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ//HB7CYaKVM2TM1dL+UIZjFfsP6AJ1dzY y7m1P5/mVUmqzA6nzWI8mkz6JUmsLw9GMfAushDmz0/P12UlRGBcSrNPh9V0NJ6OWllB1jd2 R/jZKUxFK5PN8XRyzweznfD7xbqxOzp7MC7DkhArjS095/tQbpiKNw2zmwS7TPDyYH08HnZb 22ino2l1YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1suZ6LREMJhvdqsh8nDGg1VStnuMJoI9U SO5MrfXKnHSVaCBWUFu5IO5JsGcQgnPRdLHebFRyMR8QR4yNZsqNZr2cE/wUFZRSgp/47AAh A3FP3CBQRgYlpdZs1gopwHkumkyEvfiHAYUl2UA4EuY56qbLKMkFPddHAaEkGI4hfp7bYAJo hgSCeWuG8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J8BQMJzwXSDqYNqDsP5OBD/5kbi6oQj1d 99a9+9/y3gvAkfOrFBxD//Z+Qno3v638X94/+3vn2QplbmRzdHJlYW0KZW5kb2JqCjM0MyAw IG9iagoxNDA4CmVuZG9iagozMzQgMCBvYmoKPDwgL0xlbmd0aCAzMzUgMCBSIC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTkgL0hlaWdodCAzNCAvQ29sb3JTcGFj ZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQ ZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVVfmTolYQ HrlExQtkxhtwUPEWL9QRFG9QDnXwmJ2ZZJNUpfL//wN5aO1uUtnUzvYP8IrX3+vu93V/3Hkg CL4aBHk8dz9jHgjFAwSwgB9HYehnwBBK0GmW4zgmHScJL/wTWNj3IHRHijwaSqKQIX3Ix7FI iBsazvPOMg192uUp/ONx0Whp+enXi73d2s+HTT8XwaCPXhVKVvX3N0Pp9RTdOemthA/+OLS2 eXUUIZ3O9zbnZyUXRK5kfblrwN2NPJe6G5GAxevpKFnbXKxOMuin8pPjeSGQOB4IBgOAKeDg gRCvz3+lzotAEIL5iCDhw24kAqh+MVtxnzfMyc7LuhqnHrJcLvsQxmHgi4diiQzDstl41I95 CSrJcEyCDKDuhbhRX3YSQ0YSlfnpvKxzfE0ayf06S+IIGqDZSrv/NHrqVbMkEUkVxf5AEvOJ oIt1oW/nebNQaCjWeafUKh1VN21r2ctF8cCD0J9pxt456MNigmaaylLT1otRNUkA/gF0+/k3 ZzVRV5azn7VK9aeFtrEcZy2mwrHCk2YalvP6upOFNCvOtpvlfLnRx2Uah1yo8cdfn4+2vdsb aiPHCK1et6cYp4PM32daa0sbyyvnxerzTEW1d4t+e7C0twM2iFyhv//5vtfXS1UqpSgqxeXY x/rMOc3LqcehYSi1Uk971ttcrmuc7XGjLKr2YVaKoh434V/eTbldr+QzMQL3h2P3CaY2O15W 1TQ/NDbD4qO42K2aXEF2XveTdqMztQ6LagyD3GsCLVFMxshwwIsgGEGlchVpfQY8pdjO2lA7 zSfdnlUZQb28P88HvcFkrclF6gZ1WyKAoQggEsZJptKWZP10ARQnyqplakvd2gz4VHF6ebMn nabYkbrVTOiasH4xmjR2bS4IC7MtWZYkdXdcVWiSG5in497URqU4zSvOZSMJOTb3mMtQfsSt 9Qa9tiWEP9Sn2qRVGxiOVruPZrrb09GY9oR4MJTpmceNlE8lkpls0h3sf0PhQEYydrNWbWie jU6GZiXDsdRWPh7y+ujqfG9PWwJfKJXzcdATKFlZO3o9hl6jwv50z3jWnnqT/aeDXMwWlf3Z GjcfExGfN5TtantrNR7J41GTcWuNFMbbaYm8Qd2E59Z2psys405tCOLy/H7U5HaZiRF+6rG/ 3u0sY6upYjaIeBAi0xyITAi51YqGGVFRR1JfmU2HojgyXt5Ou81K7RXuiUDssT1erldzpZOn gSJA3miay5D4TRs8sDeSypcEPscL5XK9v7L35nqx2prakI/ivmgqX200qoVszB074EyECPyL EHpgLBChyEg4QtKpsmJai36j3lHNw7oZ9yFYIEzRNBUhwNzfhAABzXDNFzw8EIxiKIogKE4W J7YhV1imKOmO0U35YQhGMGDA/SYxX0Bf357rD8SDhHIjwxg38nx1qB9cwXPPB5v/A/uKv7uD /cnmfLMErTVabLdjgfJ+Te0fXt9dQliEa4/nwJarhVy7CsN3Hf/70QNGIVu+KlNfLCSCH9d2 UBbsDdJpjs/zbNIVwR/X+C2+q8KBUDgSDvqxKxvftn68AlQhwMAgfyfk3xd71dwKZW5kc3Ry ZWFtCmVuZG9iagozMzUgMCBvYmoKMTE5MAplbmRvYmoKMzMyIDAgb2JqCjw8IC9MZW5ndGgg MzMzIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEwOCAvSGVp Z2h0IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJw b2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4AbVWWXuqyBaNyiggimgExBlxHlCcNeIIKihOiTE5J31Pn/5u3///A25hTtLd 9+G+ZT/t2rVrL4raq1bduVxuj2Nut9t197XmckOolyBJgsBR2PO1aG6YCPKxRCIu8iEah790 bx6czSi9waDXaVYyEQr5SjAPGVONw9HeWht9WI5SsPvrzgyiM9rj9+e9Ze1P9qzCeT1fiOWX F9fXndbtTXdPhwfJD39df0CB3OJynpQSyZJ2uKyqIRQ0/4e5HFzXbQS8T+fd+5wDrLnR5tdR v3PIGTgTNwOEcrIB1vzR7sT9tNAwL1YjgnlgFEMRFPN6MRgkeRAM9zp8cAN2YCDkugMx1CEI 4AuCYQgEIThJUYQz53J5YMyhEAYDFGcalALrEQig3bB27ShFcvXVeaPc4wgZDLNMMBIVwj4M RknmXojyIb8XQYhAmPWhHjeE+9kg5TjeQIilvYQ/Ek8lo6FbCKPDYiIRBWshkBcKBZkQH+UY L+R2sBZPh6EU4aSedZgVgpg3nCnmJbnSbBSiAR8r5mrNVqOS4f1UMJ6XRRqBMDZZyEV9MISH UvmswN6nqp1+r5kXfCjsZZNltdtVi3HGiwdiuUJWKihqLc1inhvW9bru1pTh5rTtp3yYL9ma aP2etlz08mJUVscLw9Dnw1oyEi32BhWeQOlkezYGLYv6062hmo1l20vTXM06cpggwnJ7qhvG UlPTLM2Vh5NhdzjXtXqUhFxgX8tvv1+3K/P08my2YhQWyE8Pe2MyXSyG1VxloJtrXV9Z5lzN pmsTYyQHqUht9XwaSwGKr8+Nfl5q6KejudC6BY5mpZ5hGrOZsVmoyUiivTmYM2221BSRumHp b//+8Xx+en172falIMmWVtfLqtdQGrVyfbS2loOm0pmYu4War2qW3hDD6eHTHz+sejQsDa1V W5K628t+2q4VEyFGbK72m5Gqjje7WTWRHR5f9poKKkn3gLjOvr7/fLXX6+3hfFiqCTZS2bw8 TooxXojLbWOntySBi5fH2+24WuqtrYdCuqp/+/OPx1EurSx3s7KYUK2LPa5moiGazWqns94q ljrG0ezI+YfT1VTTAs+FwO13w3p5MQf1qtKbb/dLJR6trp93bdGHk6w02G6HEuPFKL623OvN XH22M3rN0e7lt7eL0WmOLbOXCt4XZ4ej3skJASpcNsA/6dZqPeNgDQrFh8N5lmcJHL9xxenD y/FB5kL3idr8dNQKybpxNiqA07BfGtvrJo97bu5u05bknmmvFpvj0QY3mrG09stqhPCJjaVt 6718hOEV69t1M2q3B/PVXJULI9seJEjIITQgM8CaPwJ+kSjmT/YPzyslq+jHRYGB7yA6q9mr +j0Kdk+lhjuznYxVl+fL5XIyRpr5CBx7mKERNJBUptZ+M8wLseb29UnvKjVFbStyIjfcWp2o 9+M6v2FtWwIBI1S8d3wxm7Ki72f5AHTn8aUfbLMlkjCEMjkNbDEazgxP//r5ZvdLtenTj5/f zAbvhRAylKg+WCerL6cb6+ejVs0kk6l0QuDAGWxaAv43LMDlQSbkZ/jC9PG6qksAa5pzsIhY x7S1IkdTTEJd7RflMM0p2x//eTMqsWR7//PPl6kcAPQNhIV0fX56XNYyldnpoJXjPCeIIheR BtZG5f+BdX02WgU5X3/YgZPLJ2u/sNxYuDyzzVFFSuXUuW0N0jQeyM5efn8apYLhov79x7Ej EjDGxCS5oExPz2slKXXNw6pXkqRcIZcU5eE/sfzy/Pr2uJ5pU313OsyrolCebzXZD925IF+8 pe/M+WigGdvtpBzBYa/Qsh5XNdAQ8Z59XhRZBCK4YmcwGG/O53mJ5wvj7X49HQ5Go3YhKffX RoP7a1++1Oj4ej3td7vddj2uigwrDxfdlA+6u3NjTKa9sCzLtKy1VnVEG2Hk/rSTphEsVBxN mjEK8ni58mi5Nu39qp0I0HxZM+2dtVmDGy6Wbk61yj32cV4egq+MjfVKX860QVPmfbhPrDSL PAH02eXBg8laH9xW83G7IPjAY8RDcHJZCuMeiIrmS6kgUDs0mG6MZouFpmaCOEoJxe50uVxM uqVYiJOVWiqAONrlmBulhWypUimXCtkkzxAwhAWEGEeDRnfAMJpL5cuVUjYWIp13jxuhQhxL AnFC6XAEKIXLBXnZmFyulmWRwSEPTIYT+Uq1nE9xfsIXFqMsyLkhOeVQ0s+wbDDI+CkcccQR JSgCfX8qAuXDfQwbCvpJ1FE7kI7gjg4CTURwLwZE6c4NYWSADbMBEigakE+MCrAhlvEBfUS8 JAnegb+gwGq3B3436F2qQQB4v74FqDgEIwgCZPk9clP4G6qj+7cgqA8j6EfKxwhcFk6lv0p9 Iv4/Bwj7x19w0j5Hn84t9rec/1nwWfu/d8pD4AplbmRzdHJlYW0KZW5kb2JqCjMzMyAwIG9i agoxODAyCmVuZG9iagozMzYgMCBvYmoKPDwgL0xlbmd0aCAzMzcgMCBSIC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjEgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQov RGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJD b21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAE1kntzmlAQxeUC AopUEB/RxEeDSUwUTZwCjVYdMj4CgV6QC2iDtpNO+/2/QUHs+fM3Z/fu2b2ZDAYAnggADMuc heFZJs+ybD5HZwmQYgynuOpVu91uXdYElsJB4sXIwmVfnU4nz+pjrykwROIFlNhbQLSFtmW+ KJLI4DEFdO3Jig7+dwt6nvn1upiNGwCmrriH8HWizQwUGE91Bj9B1dnbarfVVczQ+9YpnCEM 1v0KJ94skK93PxGpE/qr+1Kel2ZbbyFx/+HOfLyqNodL19Ka+XO5GyF9PFKXjreSq3T6uup9 /EKmAXfvSO+JZ6ihP3+PQbA/HoPlsMESIJlT9X5/hLZpOQjZs/tqnCmB7iFYKqORMjdda9rl syCBzu5t3KqUG7cT2zfHdeYET3MyFFuTN6E3bbN44oT+sidQJFPub/b+/HMhhaExagjFckex f3iTVup0I28xvLsdqBs/znaR9Lz44vyM3LWur962yHq+LpIA0NWRsY92WwdCaK+1m2T3WJaX tJVpvq5XL3NN7oi5+EoYkSt3egNZHjzcSc0KR8cp44WSDMeXRLEk8FyeJtPLYwAnyJMIAj9/ hn+6N1KkCmVuZHN0cmVhbQplbmRvYmoKMzM3IDAgb2JqCjQ1MAplbmRvYmoKMzQ0IDAgb2Jq Cjw8IC9MZW5ndGggMzQ1IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dp ZHRoIDg1IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAg MSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBrVbZkqJYEC323QVXwB1xX1FULDcUUcoNRcvauh9mOmJi /v8H5mJVdU/HxLxVvkDmzTwk3JPncncHDIIRYDAMec7XGIRgJMNxLE2gXwYLo6Q/mszKGSnM 4cjXNAuhdCTbGIwnI62S8OPwV7w9hFCRgm7tnaPzMG0INPIVoDAWkIeb02m/2+9XvQyHfgko FW+t3YOpa4PRqJ36GlCETQ8dd9nKSkm5kI16r/9BMG/LIPh3g0AQugUh7/LJw/cQSP2gJcLl Jq47K4RZ1s8HGRy+EYxlGRKDQS5GkAROkDRNEQRJeZyDYBQnSRxBUJxiOZbCEfg9BPIomsI9 WiJsduQ+LmsxBgeGIe8Ey2QSUR+JIBgbiob5UDyRiIVC0SjPYjCM0cFo2EeRbEhMZ9MCz2AI SgUikRAfERMCT6PwHUxL2u7JGZfiHOgDhlE6nK1ruq5V0zyF0dF8tawUG91uLS+XqkqcQVE6 KlcUMchLxfZA77cVgcOJQKpUKSgVVWvJYRK5g/FQyXCfnFkzHQIPQahosb9Y2/bK0GSeDmR7 c+N+aKyssdocTPVimCSC+f6km09kWxPLttfLUU3k2HhtPB/r4+XaaCdYFIJQRmyY7pO7HhTj LE7wytDe2aZpby0tHYyUF+7Jni+s5Vhtjex1P+3jJNWy7yvFzmK7sUxr8zCtxPhUf+vuTMNc GWqSQ6E7GOOk+uxwvR5mddHnS3YfTtuJps22jlkThfrD6/PDsKOq9UJBs51FNR4pTPcbvdae O8floKNbzlbPxXOj89vJ0NROS4nd5gfGuXhpYF+e3UVdipeMy+O6V60N7POul000t2/XeTUl ivGIUJ45m34+11k7S7Wmg42YNittw3EX1UR+fHndabIkChHuNumAN3Qo0164L+60mle91vRW a2i7ez2fam5enH7SR1EUySW1jWN21dl+d1+pTi9vp1mn2Z0f3GUjrYzdR7McZkAa5mmSx2GU 8IlV4/y805u68/11O+n3R8uHZSebbNqPdiNCeLwmQuX58WAtd0erJVfmz9/Ppt7TZ2t7XE4p o+NxlGE9+njqCbhOEBiKMUJz/eTOe+Pjt6e1rrZUra8qotRYn60Kj3nDhbCpwf7per06I0Uq zZ+/ObNuq93ta7W0kB8d9oME/SlxMMYEeT9NkEFldr4s+/f7l7PRzGezOTkjhOKN9cksB28q AxOR2urlzx9vm7YUkSeX502/lMvk5FwyEpHvD9ueRH2CIlQ4o2SFUDBeNs6uoXati2vU06Ig JZMxPt5YnRald1AI5bKj619/v84LvC/Z2z9u+ookiMmUGA7L9/utJv4CZaS6rqvVYn24uez0 Unm4cx+GNUUpVUrpmPgv0DuYjLV2f/xwewmGilTNkzNXS/lCGYxX7D+gCdXc2Mu5tT+f5lVJ qswOp81iPJpM+iVJrC8PRjHwLrIQ5s9Pz9dlJURgXEqzT4fVdDSejlpZQdY3dkf42SlMRSuT zfF0cs8Hs53w+8W6sTs6ezAuw5IQK40tPef7UG6YijcNs5sEu0zw8mB9PB52W9top6NpdWE0 YuTnN/UGqjqYr2x7eV9P+gkCuPpitbLmei0RDCYb3arIfJwxoNVUrZ7jCaCPVEjuTK31ypx0 lWggVlBbuSDuSbBnEIJz0XSx3mxUcjEfEEeMjWbKjWa9nBP8FBWUUoKf+OwAIQNxT9wgUEYG JaXWbNYKKcB5LppMhL34hwGFJdlAOBLmOeqmyyjJBT3XRwGhJBiOIX6e22ACaIYEgnlrhvGH gIoGWAJFgF6zoPoT01uHEcwT6I9fCfAUDCc8F0g6mDag7D+TgQ/+ZG4uqEI9XffWvfvf8t4L wJHzqxQcQ//2fkJ6N7+t/F/eP/t759kKZW5kc3RyZWFtCmVuZG9iagozNDUgMCBvYmoKMTQw OAplbmRvYmoKMzM4IDAgb2JqCjw8IC9MZW5ndGggMzM5IDAgUiAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3BhY2UKL0Rldmlj ZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9u ZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBZZJtU9pAFIXZ3bySmKKR ig3QYC1WG4mpKNAWpBBNAHHYJDTE6QgIMziO//9zFzEh6n5JdpNz9zzn3kQiXACSBUC4jT0B ojmepeD7bwCxUnpHFmgY+331Cmkpd6QXMwL1ToaSGb3dqR/I7FsZoFP7Tf8OV3MCeiODXMa4 mT+Orw63mNcyQEmFuv/wNMdnShK9MgLZ9LF1ez+b+n+KKTpeESAxX73xh44/6v3Y5eMVIbN1 2HYH5oXt4caXD3EZSirla/fqVKv1h7b+kVvLiPOvTRc3DtTjyyH+pW6ssZfOrwP8u6h+b/0N bG07wgbUxl7Dn47Msl7p/Jt6P/MR9tJ5b7KYOPZldzh7uLMibICEfM2bLyYjF7vB/WKGz0Ns 4vybGYyDQdeyrB6+Ha+xUfJTue/jVrmkaVrpvO34IfbS+YXjNI+UbVmW01mt5eD6ChtyOycd r2PsCgxN04yonHa9F2wkfq72B439VTzPNQb9Sl5ECdKOvZptnoShkpsN06oVJAoQ3pxeMdQw U8ikCkallCNhAcTLWVXZ5F4aCBC3qahZmSdzAClelAQ2mggydYIkchRJH0BEUSg2mdHBfw7L RK4KZW5kc3RyZWFtCmVuZG9iagozMzkgMCBvYmoKNDUxCmVuZG9iagozNDAgMCBvYmoKPDwg L0xlbmd0aCAzNDEgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MTE3IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBd IC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBrVdZe9rIEjXahYRAEmLfQWYTIFaBwYBlIxYZEJvBTmzPTDI3 3/3/f+B2CzvgzMPkfkk/mO6u4zp0dZ3q4uLCHg7kOFA4EMThALv2HpycDbBnQ95gZ5b/f+pA cZIkcIJmWJZlnBSBAV57D0XOvTnQIwSgWIYmPhrPgT8xd6Cki/e4WI8/mkgk4pGAwJIoijs9 gpvGzs4KcJwNAahE1O+h0DPjT/B8gCCEOxiP+KSoovV63Sutmo8JNE55IsmoQJ85duCuCIBc 97rd7lWzEOHwD3H44PPfFgjuCmWLmVCkOLR2G2sxN29bGa/TKabLpYRAnhwjpDd/hCwW96O2 fG77N5If7A7U6c/Vq5lQrD5/fnlYzq3t1uykeUZI1TuV2NlxECpQg5CFOZ1O9GaKP/tCPzj9 x9IB8/J0GwgpZBpXakyKtdYvh2m33Z/t9rNaiHVF1H5XCdDouweEDkHI5KpRq1WVjJ/9+fA6 EIyA6fnmyoGx0eqgW/B7ItrqaaHJcbllHrbXSY725nq3nYznu2tAakPSoUDAL/EsiaG2uuxT gNlRUPaBjltQYMclSrIeN0MeVxcX8KL6o07Kw4Y1az9WfJz3crh70GU36Ypr4zs1+P2okBRA ihJDgkEQJEWRUFzgFBRFoChG0KyLhVICW8BIUU4GKAsD3BQfSSeDPAPx4LQoE2tNjHqYcQKP D0ZBZPhMf7MdZjicCqiG2Uu732Vjkz4YeZHCwMApzusTQIgR3Mn7vBxNsWIonowHBQYHeuP9 AZ8/FIuFRIbAaDFd712pckRkYNwcOJ+7WYxKEgVJH81q1B+rjNbzdoxBcSGvL42y9J4vNulh poZ5juNcrDuYKcgBBsOcvnRBDvFCOFttd7SqHHSRtJgqqeVStanVskHOySfb5m496akpkQKk ICOrs5We9RAgduvnnV5XtdFqa5T9FIK6UtfWXIsyb6kESdfP22ElK8vpRDiUrvc7WS9F8hmt 38hEkmrfAGk96ikhzh2t3U1HNzej6bivhMVgafz57z/3s+tiwAmcgeheWet+yoUBj9svf+7M mfX4eafnvRSCOKMdazNMc9gx6SDp9ssfm7E+HPY1JZ1rTyZanHOFa8a0W8jWb+9N484wZ4NC QAJXdFiNBsPJct7Ph2Oq+frtdT3Ssj6YIRgn67v1VYwBpO3df7697vdPr6/7USXMYigVbC73 4wKPfyeFkJfdyrLmo1ZWbkys22JAuhwszI5S1a3VqF3vGNZ9Jx3O3T5+uu+USp3petZMRop3 j6+bGzUT5AgQXozPjw8rLUyj8BhfvxwW5ny12y36BT+Nkb7a4um+4iWO+oIn3f399XExnUxG fTURKQwtU8uk6hNrVFM684M1qBSqN9bmVkkU7va7m1wwkO1bVi8dSF2tHoxKhGcIWFZxoTR7 spoBCpKuX/ajlqq2BuZ63pN5gvRW5p+WNR95It28HgxNLZeVbMwrxJqmddeoDRfzbqE42H1e D+uVhr7cjCop5Xa7aEVYJty4Xw1kX7QJP3ggVOgKF8v3n6y6n4Skq8f7etwnhbPdxYNZD9Gk bWwEqBMpgDQSfq9X5F007c3rq6Uxmq8MNV3QH1+2d51WZziZXheSyu3GrPpI0qfOVjeXUrg2 W16nXG8ZaZMu6z6b1NYpTbKB8uSw7SVY6p+kRwgOBoZibKy9OOz3e6snh3P647M1bKjVhtZU QORv1zNVIglvebrSL32A1DojFUrm07IeeCMd5QUSpyVl8vQwSLkoO7wgDMeXxtbpA4TA4oAi KCkp46cvXz+b1bCU7u8eTS2XSqTSqagvkP9OOgGCBKQmCK8bP9ZBjC+MD1YzaN+pBZUveKRk a/Fp242ztK+6eJqr54l0hLjdnIuhcNyV7O2//feTfilw0Ra4Ek0OB0PRWEjyn5Gu9awUqpqb kRLgnBQObhVzA8lY7YjTTiSo/Fy2pE0eQG0KOulAY3mYFIWTZOzioOZkWU5FvQxB+9X5X183 rQhDS8W7taXXcpnLfEEOh/L6e3gngNTrL08fFt08qJFOUFRRNtG1VuD+MDrYXP3xvB7runG/ 2c2v0h6SibSt7Y18Kg4Q8gIgw+GgW0uLFOHODLb7UUEkcVesOV0vx4Pe9QBUu0h+uByXJQIX FWM5kAUxq28fzEFLiXvAXSF0sG5aQxBuyq/Onp4fN0D51mLcvvTSOCyDyw6owm/FgfJVpo/P BwhZzvqgpGF0oHJz14iyGHiV0+3JarWc309vqolgpmMM8gKB89m+0U66uWhjutnM7zRZBKQO XCjcLu6KIknwmbZhmtOxcTtol5NeJ0bwOX05rvjeC76D4NPaaDabjMdjQ9eyEoXi7phSSoG+ xYHCl2RgTMZ3/YbsF8LFZiXOYZgrWm4UggzFpxo3Y6NfTXhASXKgrkR7alSDNO6UkvlSuVwq 5jIxH0dhKOkrj+6vM278KNMLB+b0JvJKCQ6lkA64CPBQegLHe3KANzMsK5WKchnzsk7Q6oUF CoWbMVD7MPCgZkulfBycBXhDKH/pZtxOcjhOc7wIZC/wHMhM8PIy0eboVg19f8QvEAxCjkNw w5IGZONkKAxKCjTFjFuUJNEDWgqMdLpYsO/ASMblBM86aB14ryRytP2KO3Au2dKv817Q6mJQ 9ED2sA25QAhBvtLbGf57uwKa/ncIRNklzW75jzKGVgIMu4kBc9CqAC9wAj6BEX+zwQRBKCl/ da1G2PcG4Zg1DpQJlrpXRf/poEfDj39Bb3TaAouz1Wkfzs5toDOLlLR6+ocuFsE9iapWjp61 oB99/NoKITxxpZyRYCNxGkADqZLyodk+GX99BvJOiKZiAgVCfxoIyYOfFeL5z4qT8TfMAKtb FFj4pp8GgjO8+PEH1Mn4O2YIajeu5wcFCsBhM/vhi/wOrpMP2Jt/CC4wwR8fP+6d/uNXZv8D XyN1CAplbmRzdHJlYW0KZW5kb2JqCjM0MSAwIG9iagoyMjAyCmVuZG9iagozNDcgMCBvYmoK PDwgL0xlbmd0aCAzNDggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AW1Q y06EQBC88xV1hMSFmWZ5XcVH4mETs5N4MB6UBaMJi7sjJv69PdNzABUOlelHVVedcI8TFEhB K9qiKmucezzgiKy1Gp2Fhu3+TgxQaan8hzc3SxHPKv//P++EtFIoqhI1S+mGFlIkUtrLRUtu 3vKsG+7xuruwG3FpUG+lzrjN06KpyhKaCpgR2Y1O2RHMEMW7Ce10HGbbH3DVf8yf3wnMO64N W/fm0zz42LdM+CuJPbJbzuHV+jycR58HIYeuWKJwHgZPtK4tI1QuwoUPgq4jMaEpmCMU0Hyx O57C8XhEbBJsasQzQ4O4F7ACB4HnJHI99uXggoEXILCT4iTwJRBYRnm9rIpnIQvrufTWnCRF tYImwRPMXcj1B0Uof0AKZW5kc3RyZWFtCmVuZG9iagozNDggMCBvYmoKMjg4CmVuZG9iagoz NDYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyMzEgMCBSIC9SZXNvdXJjZXMgMzQ5 IDAgUiAvQ29udGVudHMgMzQ3IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5k b2JqCjM0OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+ PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjM1MiAw IG9iago8PCAvTGVuZ3RoIDM1MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBdVLbTsJAEH3frziPbYJld3vlVbwkJmIMTXwwPkBpsSaAtKDxg/wk/8ez3aItCqU53dmZ M3NmZot7bCGhJZTUAeIoQZXjAWsMx7VCVkOhzv56FJBeJJsfSuOrBX1l8/zvbxIpKRHGERKm UiPdSaVtKtWkE11uRjWsZ7xjuKkwW+E8RRJYOzHwvXAURxGUDpGuMLxSHhUhLYQz2WC8WRf7 Ol/gIn/d7z5cpC+4TCn9UJOiflNTEMpTNf3qFaVR0q0pjGVbU6y8RNsr+6lHrCn2+Ab9wuB8 uuJQx0m+oCUjkkCp+IjkEc40r1yc+VI4by6bCievcItstv5y4fO4Q+GCuKmWOe6qclmuwf/u OceckVTtbBqH99owPSG9ET/NkZ7fDnk6pqyjNZlieM0lWdb9ZdHwodgSFbKZomi63LP19kua /eo0QEMdJqxa9cSQ4kUzWd1OFtSeUnkCZ08wwi3UFhYWZhY4dOMyIDAArjAwsUbKN3dsX4dl ZU/zntF0mp4gMNy3p4Ela43aGmUPRrav7dJ9AyOiv+4KZW5kc3RyZWFtCmVuZG9iagozNTMg MCBvYmoKNDA5CmVuZG9iagozNTEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyMzEg MCBSIC9SZXNvdXJjZXMgMzU0IDAgUiAvQ29udGVudHMgMzUyIDAgUiAvTWVkaWFCb3gKWzAg MCAxMDI0IDc4OF0gPj4KZW5kb2JqCjM1NCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1Rl eHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0 ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIg Pj4gPj4KZW5kb2JqCjM1NiAwIG9iago8PCAvTGVuZ3RoIDM1NyAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBrVPLjtNAELzPV9TRllhnZvw+QnhISCxaxdIeEIddZxwM is16EhAfxCfxP9R4HNZekgsijlX2THdPV7vqATd4gISWUFInyLMCg8EtOqzWVqG2ULD13xEN ZJTJ8YfWxWrBWDle5+PdQUpKpHmGgkepUs+O0v4oNR4n5rWZNVa94h7TXYf1Hi8qFIlfJyZx lJZ5lkHpFNUeq9cqIiNUjQiue6z7rjlas8VL8/V4+BGi+oxXFamfelLk73pKUnmpp0e+onVM 5j2luZx6ylVUaL/lH3XJnvKId7JsDMHPUJz6uFgvmYoRWUCp/EmRDwg2ZghxFUsRfAs5VARm wDvUd92vEDFfD2hCEPthZ/B+aHdtB/4PnwzumUnWQT8GfLeu0kdUb8U4nItNnSOppfxfJEv5 LySt6bawxtq271D3/ZfW/CEO8uMEnhMdvfHbi4v0ljPXnOFCUeDM++PBtltzGqI4N8RHhcko npyyWVMbT7y2weoNnbazo+Oci0bHacRQ1JVKnSKbUarLtblJpTPpjJGGKoS3iZokREypIE9G T/ZwZCrKp0BwJDj1eLAeth7uQuH26BwHzwhM4DQdXPtFasjtUYOzKnv/dr9YHHyxKT32e8ua 2i/KBZSzr4eb3yVJCswKZW5kc3RyZWFtCmVuZG9iagozNTcgMCBvYmoKNDgxCmVuZG9iagoz NTUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyMzEgMCBSIC9SZXNvdXJjZXMgMzU4 IDAgUiAvQ29udGVudHMgMzU2IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5k b2JqCjM1OCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+ PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjM2MCAw IG9iago8PCAvTGVuZ3RoIDM2MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBrVTLrtMwEN37K84ykW5b20madgnlISFx0VUj3QVi0YdbAjThximID+KT2PItHNt9JKXd INpG09jjmTPHc+YJD3iChJZQUqfIxxM0Bo+oMJpZhZWFgl397bGBHI6l/6B0vlrQV/rvdX+X SEmJLB9jwlRqqjupdEilfDrRjc1TPuqAezzuEK52eF5gkoZ12jQZZtN8PIbSGYodRq/UkBWh 2IjovsasrjZ7a9Z4Yb7u2x8xik94WbD0IybF+h2mNJO3MJ3rFaWrpIspy+UBU66GEx22wl89 JaZ8yCftA0P0MxZHHDfjpYdgtAygVH4R5D2iuWliDBIpom8xSUVkGrzFalH9ipHwtcUmBm3d bA3eNeW2rMBf+9FgyZOsOqq9w3frIn1A8UZ4cm6CulaklvJ/FTmV/1KkNdUa1lhb1hVWdf25 NKfCwfrIwDNaV56/e3GzvD7nmhz2OgrkvN63tlybI4niGomhw25muUZiorUnUfQTslNOHXsz Xh91ovQJtXA6cKhn9W5ZVovWMVRvjr2wIG+zwJet99X6i28GiiRB1CXsStOLIMSL1GPm60oQ Eamq2vK3sbyYHgSKsoEDYMvWnOXgZ9IwOYyX+YyCuhhQc4xeczxtbX9MaYJWFKPKBKfYxuv7 vNaRtp9s0k22DqEa6jhbSJ+bZQPajLILF6IPM8VxWVBzE0R7Gie5YGww62AWwZBJ53JHwwOI hTP3YZHCc3sUbifKLrwte4tO4/TkhbjjSXi7C8EOizosyp6ZdloeD38A4KpXIwplbmRzdHJl YW0KZW5kb2JqCjM2MSAwIG9iago1ODUKZW5kb2JqCjM1OSAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDIzMSAwIFIgL1Jlc291cmNlcyAzNjIgMCBSIC9Db250ZW50cyAzNjAgMCBS IC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKMzYyIDAgb2JqCjw8IC9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAg UiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBS IC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKMzY0IDAgb2JqCjw8IC9MZW5ndGggMzY1IDAg UiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGNkU9PhDAQxe98ineExIVOgW25 iq7Gg4nZJh6MB0Qwa7JsFqKJ395pZ01g9SAcXjqdf+/XIx5whIJWIKULmLXF2OERA7J6IrQT CFP7O6OHStcqfNj5XB1xrgr/3/l+ECmF0qxheRRVejZKyygK46J5b64KXVd8x+V+w3aPSwdb SJyVqEyLysIS3B7ZhlL2A9cj3jRDu+tGbNtuaMbdYUoi945rF3z/o7EpUqVNDjLmrPUT4roZ cNskUV4g/kzYEeIO9VWCZ7g7GRLwpvmJ1Lbmlc9Yb5HdMOm3KRD3FANxDT+UbZSeUh/2Xcbm j6T8I81IaZCNBBPpEz6NkkGJC/0DiF24BCuL+IPFGxCZRF5F2KO/+5LTBQsXQOReggcRxjDr spfTyyI4SrNTeS53y55agmoh1YLrNxHCk9YKZW5kc3RyZWFtCmVuZG9iagozNjUgMCBvYmoK MzE3CmVuZG9iagozNjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAyMzEgMCBSIC9S ZXNvdXJjZXMgMzY2IDAgUiAvQ29udGVudHMgMzY0IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0 IDc4OF0gPj4KZW5kb2JqCjM2NiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAv Q29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAv R3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4K ZW5kb2JqCjM3MCAwIG9iago8PCAvTGVuZ3RoIDM3MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4Kc3RyZWFtCngBjVLLbtswELzzK+YoAonMpSRTOiZqHughQGABORQ9KIqcqoUlxHIC 9IP6n11yZURyGqD2YcTlcpYznBfc4wUG1oCMTeHWOfYtHtBjVY6EZgRhbD52bGHitQk/dL7X Ku414f/vfj+IjEHm1sh5FBV2NsrKKArj1JybTwXWc97j4/6GzQ6XFfJU6oxEWZwWOXJCtcPq mmLWg2qL6Lrum67dY9O0fb3vhlGr6ieuqqD7P4hdGhvrEpBzJ9TfEJV1j9taqyRF9KZZEaIW 5ReN76i+ypCjamKHveo0M5+pfndUdd6ruerMmUm1ozi3siWftgAlRUzWpSc3jP58KvadL53I GJmAmG3pIMvcdIcWWhUs7wL1+KvrnxFqlzgMeBowDrv28MOXhz7saDhEmPvwUY+SVzyZ7/KT +VGpcXyxkNU4mWK3KdmGWXAVB3eD1Q3H9nlcxtfCvyBnIvPmb8PjL2vzxBvFCZ5d2IKOmaPJ LcaMUyd3tce0sVeVxnmO6JXBp0ErD6OsngRqgd8CZwx8gM3ycCfFQYAzJSwBdkL2uCjuZTUd T2S15LRSNAsotJqF9C9kxN5oCmVuZHN0cmVhbQplbmRvYmoKMzcxIDAgb2JqCjQzNwplbmRv YmoKMzY4IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMzY5IDAgUiAvUmVzb3VyY2Vz IDM3MiAwIFIgL0NvbnRlbnRzIDM3MCAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+ CmVuZG9iagozNzIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3Bh Y2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAw IFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iagoz NzQgMCBvYmoKPDwgL0xlbmd0aCAzNzUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AY1UwXKbMBC96yveEc3UWJLBwLEhTTs9tJOamR46PVAsxzQGHMBt/UH9z64QiQHb meLDWivp7b63q33CPZ4goASkUB6CZYha4ytKzONGImsg0WTnJzYQ7lJ0H3JzVjE6K7rf5fMm kBQCfrBESKFkpAahlA0lu3BsiE23OtQZ7dF1k2FW4CZB6Fk/WSl914tChBJJgfmddIkPkg2c u7TMcl1jlekyrfOq4Sz5iXdJx/s/gAPPFSpYQAbBBPobnDgt8SHlbOHB+cWJERyN+JbjO5KP Nsgza0kKG9aeL66xPinKcqPVkLUfiJ51IN1Q2S37V0WQi8iVKvAmGTp/r5I94Xk9GFkCkIQ2 VpBorvJWg7OI6L1F2jzm5QM63w3aCusKTVXodmvcVdntcARwMNThnA+zVZzED8JJfCfmuFKx FxLskihqKa+I8grexaSUP22rvvbprqmwTTnGDVCVm0Oj17jV+0N7xO+83VaHlhQ8tcW5HH15 x3IsqOHPyhF//rLCDBuqCJyqhv6TFvudxr6q6h0HOY/IjafQZUtpvF4GG5dN4noX2qDRWd03 eUuFf+SgZnF02QwD3DMaJy7lbT6sYurUyWxZYf6eJstDM54wCuaR0bP1zfvYmPfJxr7hUBJm KA1EVJDPY0H2DU3Wp8Fg9VOuYN1AoMolHLMQzoGMyd8aImFWa2uopGZ1tOYNGbpAQhrziTOz V9k9evYDlMKufoycJJo50l9f2NULJjOYyjrFyEQjXf8BDqdA/QplbmRzdHJlYW0KZW5kb2Jq CjM3NSAwIG9iago1NzIKZW5kb2JqCjM3MyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDM2OSAwIFIgL1Jlc291cmNlcyAzNzYgMCBSIC9Db250ZW50cyAzNzQgMCBSIC9NZWRpYUJv eApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKMzc2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0 R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDEx IDAgUiA+PiA+PgplbmRvYmoKMzc4IDAgb2JqCjw8IC9MZW5ndGggMzc5IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFtkU9vwjAMxe/5FO+YSqONU6DhuLF/2mESIhIH tMMG7cQk6KCwad9+TlxpLaM9vMSx/Zxf9phhDwNrQMYOUYwdDiUW2CGbNoRVA0Kz+p9RwaRj Ez9sQq5VnGvifzk/GJExGBVjOLaiie1YWbGiaKe6vbkqdh3wGZeHCVdb3Hi4ocRZqchTZ8jB EfwW2T2lfCH4Si2hH+sEE+hvHGvwipfXCXgA/ZXwEND1Zs3xF/gn3PnI47Kh6hoSpTYPtyiK viP0tN5Vp6Zc47b8PB1/EvgPaRxRp7lQU/Mpj3/GfY7sgam/N336Fjkb8Y1GgVgVZ/yLqbMH M+HBOtQsGIwgI9uitBiBWla2ZYWl0j7BwEGfWJhMKdKIrEVeRfheIeWKhQsYYJBnCdaJCmfM t9NlK7u3XvAgu7Y8l12/p5VmRs5amXQfbPYLtpiWDAplbmRzdHJlYW0KZW5kb2JqCjM3OSAw IG9iagozMzEKZW5kb2JqCjM3NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDM2OSAw IFIgL1Jlc291cmNlcyAzODAgMCBSIC9Db250ZW50cyAzNzggMCBSIC9NZWRpYUJveApbMCAw IDEwMjQgNzg4XSA+PgplbmRvYmoKMzgwIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRl Cjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+ PiA+PgplbmRvYmoKMzgzIDAgb2JqCjw8IC9MZW5ndGggMzg0IDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAF1UstOwzAQvPsrhlsi0dTrJHVyhJaHOCBVjcQBcWibBBWp DW1aEB/EJ/E/rO2gxlCSw9jrfc7OFlNsIaEkSKoEepRhV+EBGwzHLWHZgtAu/3rUkNFI2g8r 46sE+0r7n/Y3hUhKpHqEjEtRrnqllCtFtpzo5+Yom3XAbxxuOlyucVkgS5ydkXQcZZIyZIRi jeE1RTwQilo8IrhtQuQI3rFvwCc+XoTgBoK3kJtA0KxKtj+huMNVYfk4XVD0CxJFKjZTaO1X RDBuNvWhrUpMqtfD/iNE8eIS/zBAzLZhIEmlOJLtMeCx+4uBVMuOAU1RphwJ7qhy5BSR0kks PB4QfB77+Ddf0iVj1EmfS2G4BHM5aTZfIWJmbY9FhTlKO+NZnz+rqCjuxDEbc4M9eZmJZxje sLieW19kCjHzyYtLjTBquwrf1telFKyz3igKvH+nDOrmYExBnSRUJwkzRhFikCE4MPAoVSgM tO5WOpg74PWZt3MGDmCdGLh3RtaVeWMZuSwW1i7ZwjPu3K0Lj93Nz6mcUXqQh+Koy+k3al3I 9AplbmRzdHJlYW0KZW5kb2JqCjM4NCAwIG9iago0MTUKZW5kb2JqCjM4MiAwIG9iago8PCAv VHlwZSAvUGFnZSAvUGFyZW50IDM2OSAwIFIgL1Jlc291cmNlcyAzODUgMCBSIC9Db250ZW50 cyAzODMgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKMzg1IDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIg L0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8IC9G MS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKMzg3IDAgb2JqCjw8IC9MZW5n dGggMzg4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGlk89y0zAQxu96 io+bPdM6WtmO7SOk/BkOnWHqmR4YDk4sNwFi0diB4YF4JN6HlWQSq7S9kBxWXq12Vz/td48P uIeEkiCpMhTLEgeNW/RYrAbCZgBh2Pwb0UEmS+l+2NlYJThWuv/j8bYQSYm8WKLkUlSpWSnl S5ErJ+a5+ZTLesl7fNx2uNnjVY0y8362VKRJKalESaj3WLyhhC+EuhMfEb0zMSpEPzAa8IqX L2NwA9H3mJtAZHYt+z+hfo/XtePxeEExL0iUqNTeoijCiohWpu+Og25xpb8dx58x6s8+8V8C xLQtgSyX4gw7IBDQfUAgL+REoKCkVB6CX6oKFSWkiiwVAQdEv859PJkvm5KxLbI5S2FZglle mf53jJSpjVhrNGjdHV88w+/5dmmZuX7/v13Ks9NLnPq91vzG56fWBzTDF5heY9CHGJepPI0B 7/GAtAaD2etxu+vvOA6xeHIwzhcLuSmZnhpxQ2jBrfW2+drBdGh6M265uLCTmMzBOSkm6aSq mxW/7ANd3mDxllV5NwTqFAopDyJPfG4V1bkZDn1zQUsr6NkMKLBwvKRoGgC2OYj8o6hJS/Ya NTMrER3ZcPcM15rBm9abxhuee7t3wYYPMEdrrr2TBWn3WH+zLHv/tQ6c9o04kvVpj6f+68In m5zKO2VgqoDrH1wKEO8KZW5kc3RyZWFtCmVuZG9iagozODggMCBvYmoKNTEyCmVuZG9iagoz ODYgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzNjkgMCBSIC9SZXNvdXJjZXMgMzg5 IDAgUiAvQ29udGVudHMgMzg3IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5k b2JqCjM4OSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8 PCAvQ3MxIDcgMCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+ PiAvRm9udCA8PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjM5MSAw IG9iago8PCAvTGVuZ3RoIDM5MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFt CngBpVTLbtswELzzK6Y3CWhkkpIs+dg6fR4CBBHQQ9GDH1TstpYaS27RD+on9X86JBVbbB6H xD4stVzuLoezc4NL3EBCSyipMxTTEnuDT2gwmXcKqw4K3epuRA2ZTKX7YWtjtWCsdP/7420h JSXyYoqSpdRMj0ppX0q5cmKcm6dc1jPu8bjtcLXD6wpl5v20qkiTUqoSpUK1w+StSnghVLX4 jOh9G2OG6Bf6Flxx+SoGG4h+xmwCUbtd0/8F1Ue8qRwe9xcU44JKJTq1tyiKsCKiedvUh86s cW5+HPrfMaqvPvEtAopoWwSyXIoT2AECAbr/IZAXckCgUEmpPQh+qWeYqUTpIktFgAOiP6c+ HsyXDcloi2yMpbBYgliet83fGClR67E0WGDt7vjiEfweb1dNM9fv89tVeXZ8iWO/F4ZvfHpq s8ei+4a2MejMPsZZKo804B4Jsm7RtTvTb7bNNeMQiweJcbpYiJuW6bERR0IL3NJsFt9rtDUW TdtvWFxYJiZPBk6XUwccS4kT35/yzpoDeUuWI3AfapC5bjwO2LkBOnR9kgQNO+1I0kEGruak 4khILLevMHlHGbnuQjnRSDk5HNHcSkDthi70jRVICirKiLQanHSvAWpgLG0ONQy/Hobf4l7x kUtEBxrCbWJhTee/1t4svOF17d5LGh6gIlhz4Z1UELtHwfBZnNn5ZMvAaUnFyOF46r/CnNo7 ZWBmY6Jd/gNkDzZ9CmVuZHN0cmVhbQplbmRvYmoKMzkyIDAgb2JqCjU1MQplbmRvYmoKMzkw IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMzY5IDAgUiAvUmVzb3VyY2VzIDM5MyAw IFIgL0NvbnRlbnRzIDM5MSAwIFIgL01lZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9i agozOTMgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg L0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4g L0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSID4+ID4+CmVuZG9iagozOTUgMCBv YmoKPDwgL0xlbmd0aCAzOTYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 Aa1Uy3KbMBTd6ytOdzDTEEmAgWXrtGm7yEwnzGTR6QIbEbuJUWIgnXxQP6n/0ysJ82gSL9La iysJ6d6jc4/OPb7iHhySQ3AZIVmk2CtcocbpshFYNxBo1k93VODBgtsftmavZLSX2//z+00h wTniZIGUSolMTkpJV0rYcmyam07ZrCf0jY4bhOsd3udII7dOUSRhkHKRIhXIdzj9KAK6EPKK fYP3SfvI4P1Eq0EjGr7zQQC8B59AwNPbkta/I/+CD7nl4/mCbFpQiECG5hZJMq8Ib6nrqmtU iTN117WPPvIfLvGBAUFsGwaimLOR7BkDM3b/YiBOeM9AIoJUOhLcUGbIRCBkEoVsxgO8XyOO F/NFfTKKSTTlkhkuQVye6fq3j5BYa7FSKFDaO745wt9xuGIRWbz/DlfE0dCJAe+Foh6PrVZ7 FM0NdK3QqL2Pk5APMqBvJJBSo9E71W629TXtg89eFMZ4sTlvkocDECtCQ9xKbYrbCrpCUet2 Q8WZUWLwauJkurDEUSk26v01fZb0IA9iGYj7XIGUa59Hh519QF3TBsErAS8ihHH2PzoteIYw yp4iPu+KfVG3SqHdFC2ouwa9uu9U0zamlZMWHHvv1FbmDGbSVls1S4eqQ19JKKYSSazEXWEk RY/bax9xq/UNym1VUaMJxgFO3aKisbEfvRsp3qM3qXoqCOvNQdjb7OWSPTHqS5yek01fN3O7 lgjJmcgCY2OxlTW12RqbOjw3Dj8xBQlyUkeB6B2BYgzRm6vszdXoOvfZSQqvo4uba7rQuFC6 ULhAcjJb3lKgA9QBEy7cIl3efHugZGMWUp2ZrVzoUxuGabE/HrrZPKd0i9wl426WzXj9AxYu iaoKZW5kc3RyZWFtCmVuZG9iagozOTYgMCBvYmoKNjUxCmVuZG9iagozOTQgMCBvYmoKPDwg L1R5cGUgL1BhZ2UgL1BhcmVudCAzNjkgMCBSIC9SZXNvdXJjZXMgMzk3IDAgUiAvQ29udGVu dHMgMzk1IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjM5NyAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBS IC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAv RjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjM5OSAwIG9iago8PCAvTGVu Z3RoIDQwMCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVlLcxs3Er7j V3RuZNV6NHgDuUmKN49KNorJVLZqtQcuRdnc0sMSpbjy7/drADMEOUPRjvYQ+zAiiEGjX19/ 3XygX+iBWlItyVYZ8i7Q44p+ozs6Od9IWm5I0mY53HFNbePa9I/WvFcJ7G3T//H9LEi2LTkb KSiNv2MlSmVRMokT9dl4K536Bt/hdb7h8pbO5hRMXsdThtC0zhsKmua3dPJ32UAhml+Lf9Fk /mFFZ4srmpKEhpPfpoQbTBZT0nj8MaV/0/wHejuHJQ7aor+PyLryZdvGtjK6NuAvZdsYWr4P dFetImkCpAXSUrKS16ToExn6KVmKzmckBas6O2ejdOpBuZCU4xO0ivUJs3K9k9PTix+/nj39 cbOik4sbSWffnAu+d/XF+f3d0+ruic5+Ok8qnVysHperj0/Pixt6XLNE6ZNMbXDZQCpGNunJ 97dOiW/ui6S35e3jwVGpoFpNxhYPCZ3j4Q2ePplkxzcE31xOzi6n9PZ3+AbOwKWn9EY6msBZ O24R3W0qNXv9s5Jbw7ysv3hg//PNWH3tSTnTqa/pi9SHD+HvQ+pTpb62jXbWIzD2I5QmF4v3 q6mY/3cbg52yo6bvY7Hk3YFYFCkWnTVkZWws3ZJHPBoT6YYC4iuv3qRVG1usfkBqbnfvhqzg kE3/D4Qsv6pc6AVpJFcWlFezIBmD6AR1u1+K7Bc9C0cOIjvY5Flo6oKDjoCVHNjmiGfFGOpV nk2mgZky9NSeNU0rjfPkt9CDuJhfc3jPVo8IaOyedBHOn4EJgwCnzuf7AS6Q4C+agXN/P8FV xhSFW0k43aeE5Py2r8zvHTPU+e1sY62FMAlA2U3zydmUjkZ3Z//R6K6xtkNYxG/Cx1JGvjBc E0Y71AhESjnhUBz+KQewFRhicLySmmyCRMEecEcCsaqJ2/JbBSIjrFNeDAJRykZ6DXgBnO06 AIF4hrjj4nc/JeDspw3HZQFYVA+uH138jWKOLdVr4J0CC22qZAh71hmFuq9kzrtGMcAq3eJ6 UQOHnNeN19KmNZRQ4ITWEpXINzFGi48z3IkpRccJMpQ5fI/6aE1o4LbIJ4XYgIJI2NfjNedi oyLSHjhkguODO1kCO/C2xBJgbnjSdUG3RF1SiexUMdI1rQW1cK0Bui1vBahHya83ePIi2MzA 4lVNI0Z4erd6eF5tUOD6wnaI5vTW00Y1OiB7tY+Nx/MWNcs0oQXW8BJYRtLbO6FgWhgOrmSY TgbTxsPk1pFRLcwEiMLrwCLTso21xdmy9fgI/uJ0WiuHC9OGJlgELptr7JzD9tLWNSE4SxZk 7TXW2ny8v9usDpkrMYuegcFtTJ1Aw1IBCo4LLde0qF1ZRTHCqobHoJOod2foYLMdJGS83Wrf H86sLx+eVlHT+HCuAmywevchVGHedgDWxUHetq1uAYRdGd1VN38EVDp03eH0DylQUr7yjdk0 A1DRf8nqltkrqlsAzVboI0qRD6+sbjtm2KluGtDEbGKkup1+QXX7PBzd+qVHAnDHRkckq7WN d1oA+6xporY2LWnlEHlaqwyHOqIdYlzMiDCEUoZQjfTWSjdWKcXneRBioAMw08rGRRQqbTR6 PFQUXivSWAY3WglH948BwFynvqb0jLtAqmMTPF41gMscaEdglJu3f373jp7uaXGVCtcVLRc3 q7urxSOtn1a3FTjULNwMJIlKEvBc24CSZPwQtS8nywVKI2rk43q1oRmkoBVBfzQ5pWeumoL/ /lteoo+fLqf1HeryWGVX70VGUh8Qt7Bqo7U1sLsGZikfub6ERrWAay5k4OcxOVPh4y6qwxPB cHMY8aIB7WZUtwLFFVsREE3k/hOlMHjs4qUiADsaCMq+g/DBMQXUxbAIag9gtQgJiRbms3yX PfdulVGc1ndX6+XiaX33njbPy+Vqs9l2PJWlQoDSUIkD8fPEIETOu5BAyRV9G9lX2ToyXj5f wiepgeXAENshAjP50xKAKzxHjwa/Cd5w4440Hdwd3kBHhEmF0mJAFX5FYNG3665F6MPuqJxC Aqvghtstqi9q0X5w1yy8snh97eFxyuPefG2Pjqaeq7BJnj6s1o+7KdLbJo0kejpYCxnaRkUg SouRBLjfQMgSKZd8eoXhwHpxs+lF1FSnVkgjvbnrUVEmvsajIlOugifzNaP2nDD5+eeL2Vdb IK8T+eCcxwF8ObkssphTTSXGEcDP0ypSj1cNvJPAstvNIJnGQfIQ42A/8OGmMA4+xibGwYfn 1Xy4Loyj3j3COEQ3KTrAOA5PiraMw4FqoiDw3biNiUcYx7E2Jt1YyRJySPfUOeA5xjhgqOP9 tNimS93P7PfTLxCvzgww197ArGRY6qcj5jod40DNfHlgdIx4FTOUpKjMMNpP57lCncm1pqOd Wx3JHQ/oIxoNyM7kkrt7HqV20yKJNMpDnLyahzgK47Mc0dvd12Iw4DwU3axrHiNsx1JMPrIg G7EKPs3DKpvqVxlL8TpSZyS6j80BP4dP87RIoj3M0Q20e61bgfQwE44D+lRuHYvuv9i0SKJ0 FDO8dhrMbu7NsMOn/0/Toj/Np0OLcPLofm0LBuwjM2C01Y3VGAjbVmHCEDn2+dcGk+guB16X QIzcqcX20TfGcRMSkFTSSUQoWjOhPHeCLARVCBNmbJMa/TuvFSEqWBAG8IXUMY6cc10Tl0Qh GSw9BioODMM602AEoCDQ8ySAL8prrUutQMCM0WK+lckjOGcD4qfAPkyDUiu5YvFQRrF4j5tY hZGCkgbaWOb7/ZkKHULUhfAPzqFbcXgS4D205oKFNM6JUBGVsbEJ8/2RiSmd0c39+w04ZF37 q5L/oiAwmMg+MH6v5kMYdxZjAjvGv9hhG+MSSwWrVcOkK4B8D0nTJPUQl5OvuG2oR6Jto/Nv aQLj9QGOz+jkW/wWBxPs9O+gmuDjmGHa/BMT14Lt2n7lSfFaqcATkuIW9LV5boeuA78NZRIG Il7KrpjMMbQONHnGA90PZjL8gG34AT7MD/ycxg/8nMYPNEj8AlonfvwjL95PBX8HmsuPcgp6 OP70n51FHpJjsbyu86fdM1U+rM3flUesA+SX/wFOOnFsCmVuZHN0cmVhbQplbmRvYmoKNDAw IDAgb2JqCjIzMTIKZW5kb2JqCjM5OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDM2 OSAwIFIgL1Jlc291cmNlcyA0MDEgMCBSIC9Db250ZW50cyAzOTkgMCBSIC9NZWRpYUJveApb MCAwIDEwMjQgNzg4XSA+PgplbmRvYmoKNDAxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv VGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSSBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAw IFIKL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczEgMTIgMCBSID4+IC9Gb250IDw8 IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUgo+PiAvWE9iamVjdCA8PCAvSW02OSA0MTYgMCBS IC9JbTY3IDQxMiAwIFIgL0ltNzAgNDE4IDAgUiAvSW03MSA0MjAgMCBSIC9JbTYzCjQwNCAw IFIgL0ltNjQgNDA2IDAgUiAvSW02NiA0MTAgMCBSIC9JbTcyIDQyMiAwIFIgL0ltNjIgNDAy IDAgUiAvSW02NSA0MDggMCBSCi9JbTY4IDQxNCAwIFIgPj4gL1Byb3BlcnRpZXMgPDwgL1Bs MSA0MCAwIFIgPj4gPj4KZW5kb2JqCjQxNiAwIG9iago8PCAvTGVuZ3RoIDQxNyAwIFIgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xv clNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA0MjUgMCBSIC9CaXRzUGVy Q29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dABDQAAAMKg 909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAwNPAABvkAAEKZW5kc3RyZWFt CmVuZG9iago0MTcgMCBvYmoKNTUKZW5kb2JqCjQxMiAwIG9iago8PCAvTGVuZ3RoIDQxMyAw IFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4 IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA0MjcgMCBSIC9C aXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dAB DQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAwNPAABvkAAEKZW5k c3RyZWFtCmVuZG9iago0MTMgMCBvYmoKNTUKZW5kb2JqCjQxOCAwIG9iago8PCAvTGVuZ3Ro IDQxOSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMSAvSGVp Z2h0IDI3IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA0Mjkg MCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFt CngBY2AYBaMhMBoCoyEwGgKjITBIQwAABqUAAQplbmRzdHJlYW0KZW5kb2JqCjQxOSAwIG9i agoyNwplbmRvYmoKNDIwIDAgb2JqCjw8IC9MZW5ndGggNDIxIDAgUiAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UKOCAw IFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDQzMSAwIFIgL0JpdHNQZXJDb21wb25lbnQg OCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt0AENAAAAwqD3T20ON4hAYcCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMDA08AAG+QAAQplbmRzdHJlYW0KZW5kb2JqCjQy MSAwIG9iago1NQplbmRvYmoKNDA0IDAgb2JqCjw8IC9MZW5ndGggNDA1IDAgUiAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU5IC9IZWlnaHQgMzQgL0NvbG9yU3Bh Y2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDQzMyAwIFIgL0JpdHNQZXJDb21w b25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt0DEBAAAAwqD1T20J T4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDPwHBheCAAEKZW5kc3RyZWFtCmVuZG9iago0 MDUgMCBvYmoKNTAKZW5kb2JqCjQwNiAwIG9iago8PCAvTGVuZ3RoIDQwNyAwIFIgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNw YWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA0MzUgMCBSIC9CaXRzUGVyQ29t cG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dABDQAAAMKg909t DjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAwNPAABvkAAEKZW5kc3RyZWFtCmVu ZG9iago0MDcgMCBvYmoKNTUKZW5kb2JqCjQxMCAwIG9iago8PCAvTGVuZ3RoIDQxMSAwIFIg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMDggL0hlaWdodCAyOCAv Q29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgNDM3IDAgUiAvQml0 c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QgQAA AADDoPlTX+EAhVBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwMA7MCNw AAEKZW5kc3RyZWFtCmVuZG9iago0MTEgMCBvYmoKNjMKZW5kb2JqCjQyMiAwIG9iago8PCAv TGVuZ3RoIDQyMyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAy MSAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFz ayA0MzkgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITBIQwAABqUAAQplbmRzdHJlYW0KZW5kb2JqCjQy MyAwIG9iagoyNwplbmRvYmoKNDAyIDAgb2JqCjw8IC9MZW5ndGggNDAzIDAgUiAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDExNyAvSGVpZ2h0IDM0IC9Db2xvclNw YWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA0NDEgMCBSIC9CaXRzUGVyQ29t cG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9t CF+IQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAED Bt6BAS6eAAEKZW5kc3RyZWFtCmVuZG9iago0MDMgMCBvYmoKNzYKZW5kb2JqCjQwOCAwIG9i ago8PCAvTGVuZ3RoIDQwOSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCAyMSAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVl IC9TTWFzayA0NDMgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITBIQwAABqUAAQplbmRzdHJlYW0KZW5k b2JqCjQwOSAwIG9iagoyNwplbmRvYmoKNDE0IDAgb2JqCjw8IC9MZW5ndGggNDE1IDAgUiAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQgMjcgL0Nv bG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRlIHRydWUgL1NNYXNrIDQ0NSAwIFIgL0JpdHNQ ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAFjYBgFoyEw GgKjITAaAqMhMBoCoyEwYCEAAAiLAAEKZW5kc3RyZWFtCmVuZG9iago0MTUgMCBvYmoKMzIK ZW5kb2JqCjQzMSAwIG9iago8PCAvTGVuZ3RoIDQzMiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VH cmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVu dCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1W2ZKiWBAt9t0FV8AdcV9R VCw3FFHKDUXL2rofZjpiYv7/B+ZiVXVPx8S8Vb5A5s08JNyT53J3BwyCEWAwDHnO1xiEYCTD cSxNoF8GC6OkP5rMyhkpzOHI1zQLoXQk2xiMJyOtkvDj8Fe8PYRQkYJu7Z2j8zBtCDTyFaAw FpCHm9Npv9vvV70Mh34JKBVvrd2DqWuD0aid+hpQhE0PHXfZykpJuZCNeq//QTBvyyD4d4NA ELoFIe/yycP3EEj9oCXC5SauOyuEWdbPBxkcvhGMZRkSg0EuRpAETpA0TREESXmcg2AUJ0kc QVCcYjmWwhH4PQTyKJrCPVoibHbkPi5rMQYHhiHvBMtkElEfiSAYG4qG+VA8kYiFQtEoz2Iw jNHBaNhHkWxITGfTAs9gCEoFIpEQHxETAk+j8B1MS9ruyRmX4hzoA4ZROpyta7quVdM8hdHR fLWsFBvdbi0vl6pKnEFROipXFDHIS8X2QO+3FYHDiUCqVCkoFVVryWESuYPxUMlwn5xZMx0C D0GoaLG/WNv2ytBkng5ke3PjfmisrLHaHEz1Ypgkgvn+pJtPZFsTy7bXy1FN5Nh4bTwf6+Pl 2mgnWBSCUEZsmO6Tux4U4yxO8MrQ3tmmaW8tLR2MlBfuyZ4vrOVYbY3sdT/t4yTVsu8rxc5i u7FMa/MwrcT4VH/r7kzDXBlqkkOhOxjjpPrscL0eZnXR50t2H07biabNto5ZE4X6w+vzw7Cj qvVCQbOdRTUeKUz3G73WnjvH5aCjW85Wz8Vzo/PbydDUTkuJ3eYHxrl4aWBfnt1FXYqXjMvj uletDezzrpdNNLdv13k1JYrxiFCeOZt+PtdZO0u1poONmDYrbcNxF9VEfnx53WmyJAoR7jbp gDd0KNNeuC/utJpXvdb0Vmtou3s9n2puXpx+0kdRFMkltY1jdtXZfndfqU4vb6dZp9mdH9xl I62M3UezHGZAGuZpksdhlPCJVeP8vNObuvP9dTvp90fLh2Unm2zaj3YjQni8JkLl+fFgLXdH qyVX5s/fz6be02dre1xOKaPjcZRhPfp46gm4ThAYijFCc/3kznvj47enta62VK2vKqLUWJ+t Co95w4WwqcH+6Xq9OiNFKs2fvzmzbqvd7Wu1tJAfHfaDBP0pcTDGBHk/TZBBZXa+LPv3+5ez 0cxnszk5I4TijfXJLAdvKgMTkdrq5c8fb5u2FJEnl+dNv5TL5ORcMhKR7w/bnkR9giJUOKNk hVAwXjbOrqF2rYtr1NOiICWTMT7eWJ0WpXdQCOWyo+tff7/OC7wv2ds/bvqKJIjJlBgOy/f7 rSb+AmWkuq6r1WJ9uLns9FJ5uHMfhjVFKVVK6Zj4L9A7mIy1dn/8cHsJhopUzZMzV0v5QhmM V+w/oAnV3NjLubU/n+ZVSarMDqfNYjyaTPolSawvD0Yx8C6yEObPT8/XZSVEYFxKs0+H1XQ0 no5aWUHWN3ZH+NkpTEUrk83xdHLPB7Od8PvFurE7OnswLsOSECuNLT3n+1BumIo3DbObBLtM 8PJgfTwedlvbaKejaXVhNGLk5zf1Bqo6mK9se3lfT/oJArj6YrWy5notEQwmG92qyHycMaDV VK2e4wmgj1RI7kyt9cqcdJVoIFZQW7kg7kmwZxCCc9F0sd5sVHIxHxBHjI1myo1mvZwT/BQV lFKCn/jsACEDcU/cIFBGBiWl1mzWCinAeS6aTIS9+IcBhSXZQDgS5jnqpssoyQU910cBoSQY jiF+nttgAmiGBIJ5a4bxh4CKBlgCRYBes6D6E9NbhxHME+iPXwnwFAwnPBdIOpg2oOw/k4EP /mRuLqhCPV331r373/LeC8CR86sUHEP/9n5Ceje/rfxf3j/7e+fZCmVuZHN0cmVhbQplbmRv YmoKNDMyIDAgb2JqCjE0MDgKZW5kb2JqCjQzMyAwIG9iago8PCAvTGVuZ3RoIDQzNCAwIFIg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0IDM0IC9D b2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1 ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 AZVV+ZOiVhAeuUTFC2TGG3BQ8RYv1BEUb1AOdfCYnZlkk1Sl8v//A3lo7W5S2dTO9g/witff 6+73dX/ceSAIvhoEeTx3P2MeCMUDBLCAH0dh6GfAEErQaZbjOCYdJwkv/BNY2PcgdEeKPBpK opAhfcjHsUiIGxrO884yDX3a5Sn843HRaGn56deLvd3az4dNPxfBoI9eFUpW9fc3Q+n1FN05 6a2ED/44tLZ5dRQhnc73NudnJRdErmR9uWvA3Y08l7obkYDF6+koWdtcrE4y6Kfyk+N5IZA4 HggGA4Ap4OCBEK/Pf6XOi0AQgvmIIOHDbiQCqH4xW3GfN8zJzsu6Gqceslwu+xDGYeCLh2KJ DMOy2XjUj3kJKslwTIIMoO6FuFFfdhJDRhKV+em8rHN8TRrJ/TpL4ggaoNlKu/80eupVsyQR SRXF/kAS84mgi3Whb+d5s1BoKNZ5p9QqHVU3bWvZy0XxwIPQn2nG3jnow2KCZprKUtPWi1E1 SQD+AXT7+TdnNVFXlrOftUr1p4W2sRxnLabCscKTZhqW8/q6k4U0K862m+V8udHHZRqHXKjx x1+fj7a92xtqI8cIrV63pxing8zfZ1prSxvLK+fF6vNMRbV3i357sLS3AzaIXKG///m+19dL VSqlKCrF5djH+sw5zcupx6FhKLVST3vW21yua5ztcaMsqvZhVoqiHjfhX95NuV2v5DMxAveH Y/cJpjY7XlbVND80NsPio7jYrZpcQXZe95N2ozO1DotqDIPcawItUUzGyHDAiyAYQaVyFWl9 Bjyl2M7aUDvNJ92eVRlBvbw/zwe9wWStyUXqBnVbIoChCCASxkmm0pZk/XQBFCfKqmVqS93a DPhUcXp5syedptiRutVM6JqwfjGaNHZtLggLsy1ZliR1d1xVaJIbmKfj3tRGpTjNK85lIwk5 NveYy1B+xK31Br22JYQ/1KfapFUbGI5Wu49mutvT0Zj2hHgwlOmZx42UTyWSmWzSHex/Q+FA RjJ2s1ZtaJ6NToZmJcOx1FY+HvL66Op8b09bAl8olfNx0BMoWVk7ej2GXqPC/nTPeNaeepP9 p4NczBaV/dkaNx8TEZ83lO1qe2s1HsnjUZNxa40UxttpibxB3YTn1namzKzjTm0I4vL8ftTk dpmJEX7qsb/e7Sxjq6liNoh4ECLTHIhMCLnVioYZUVFHUl+ZTYeiODJe3k67zUrtFe6JQOyx PV6uV3Olk6eBIkDeaJrLkPhNGzywN5LKlwQ+xwvlcr2/svfmerHamtqQj+K+aCpfbTSqhWzM HTvgTIQI/IsQemAsEKHISDhC0qmyYlqLfqPeUc3Duhn3IVggTNE0FSHA3N+EAAHNcM0XPDwQ jGIoiiAoThYntiFXWKYo6Y7RTflhCEYwYMD9JjFfQF/fnusPxIOEciPDGDfyfHWoH1zBc88H m/8D+4q/u4P9yeZ8swStNVpst2OB8n5N7R9e311CWIRrj+fAlquFXLsKw3cd//vRA0YhW74q U18sJIIf13ZQFuwN0mmOz/Ns0hXBH9f4Lb6rwoFQOBIO+rErG9+2frwCVCHAwCB/J+TfF3vV 3AplbmRzdHJlYW0KZW5kb2JqCjQzNCAwIG9iagoxMTkwCmVuZG9iago0MzkgMCBvYmoKPDwg L0xlbmd0aCA0NDAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGgg MjEgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0g L0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAE1kntzmlAQxeUCAopUEB/RxEeDSUwUTZwCjVYdMj4CgV6QC2iD tpNO+/2/QUHs+fM3Z/fu2b2ZDAYAnggADMucheFZJs+ybD5HZwmQYgynuOpVu91uXdYElsJB 4sXIwmVfnU4nz+pjrykwROIFlNhbQLSFtmW+KJLI4DEFdO3Jig7+dwt6nvn1upiNGwCmrriH 8HWizQwUGE91Bj9B1dnbarfVVczQ+9YpnCEM1v0KJ94skK93PxGpE/qr+1Kel2ZbbyFx/+HO fLyqNodL19Ka+XO5GyF9PFKXjreSq3T6uup9/EKmAXfvSO+JZ6ihP3+PQbA/HoPlsMESIJlT 9X5/hLZpOQjZs/tqnCmB7iFYKqORMjdda9rlsyCBzu5t3KqUG7cT2zfHdeYET3MyFFuTN6E3 bbN44oT+sidQJFPub/b+/HMhhaExagjFckexf3iTVup0I28xvLsdqBs/znaR9Lz44vyM3LWu r962yHq+LpIA0NWRsY92WwdCaK+1m2T3WJaXtJVpvq5XL3NN7oi5+EoYkSt3egNZHjzcSc0K R8cp44WSDMeXRLEk8FyeJtPLYwAnyJMIAj9/hn+6N1KkCmVuZHN0cmVhbQplbmRvYmoKNDQw IDAgb2JqCjQ1MAplbmRvYmoKNDM3IDAgb2JqCjw8IC9MZW5ndGggNDM4IDAgUiAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEwOCAvSGVpZ2h0IDI4IC9Db2xvclNw YWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0 c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AbVWWXuq yBaNyiggimgExBlxHlCcNeIIKihOiTE5J31Pn/5u3///A25hTtLd9+G+ZT/t2rVrL4raq1bd uVxuj2Nut9t197XmckOolyBJgsBR2PO1aG6YCPKxRCIu8iEah790bx6czSi9waDXaVYyEQr5 SjAPGVONw9HeWht9WI5SsPvrzgyiM9rj9+e9Ze1P9qzCeT1fiOWXF9fXndbtTXdPhwfJD39d f0CB3OJynpQSyZJ2uKyqIRQ0/4e5HFzXbQS8T+fd+5wDrLnR5tdRv3PIGTgTNwOEcrIB1vzR 7sT9tNAwL1YjgnlgFEMRFPN6MRgkeRAM9zp8cAN2YCDkugMx1CEI4AuCYQgEIThJUYQz53J5 YMyhEAYDFGcalALrEQig3bB27ShFcvXVeaPc4wgZDLNMMBIVwj4MRknmXojyIb8XQYhAmPWh HjeE+9kg5TjeQIilvYQ/Ek8lo6FbCKPDYiIRBWshkBcKBZkQH+UYL+R2sBZPh6EU4aSedZgV gpg3nCnmJbnSbBSiAR8r5mrNVqOS4f1UMJ6XRRqBMDZZyEV9MISHUvmswN6nqp1+r5kXfCjs ZZNltdtVi3HGiwdiuUJWKihqLc1inhvW9bru1pTh5rTtp3yYL9maaP2etlz08mJUVscLw9Dn w1oyEi32BhWeQOlkezYGLYv6062hmo1l20vTXM06cpggwnJ7qhvGUlPTLM2Vh5NhdzjXtXqU hFxgX8tvv1+3K/P08my2YhQWyE8Pe2MyXSyG1VxloJtrXV9Z5lzNpmsTYyQHqUht9XwaSwGK r8+Nfl5q6KejudC6BY5mpZ5hGrOZsVmoyUiivTmYM2221BSRumHpb//+8Xx+en172falIMmW VtfLqtdQGrVyfbS2loOm0pmYu4War2qW3hDD6eHTHz+sejQsDa1VW5K628t+2q4VEyFGbK72 m5Gqjje7WTWRHR5f9poKKkn3gLjOvr7/fLXX6+3hfFiqCTZS2bw8TooxXojLbWOntySBi5fH 2+24WuqtrYdCuqp/+/OPx1EurSx3s7KYUK2LPa5moiGazWqns94qljrG0ezI+YfT1VTTAs+F wO13w3p5MQf1qtKbb/dLJR6trp93bdGHk6w02G6HEuPFKL623OvNXH22M3rN0e7lt7eL0WmO LbOXCt4XZ4ej3skJASpcNsA/6dZqPeNgDQrFh8N5lmcJHL9xxenDy/FB5kL3idr8dNQKybpx NiqA07BfGtvrJo97bu5u05bknmmvFpvj0QY3mrG09stqhPCJjaVt6718hOEV69t1M2q3B/PV XJULI9seJEjIITQgM8CaPwJ+kSjmT/YPzyslq+jHRYGB7yA6q9mr+j0Kdk+lhjuznYxVl+fL 5XIyRpr5CBx7mKERNJBUptZ+M8wLseb29UnvKjVFbStyIjfcWp2o9+M6v2FtWwIBI1S8d3wx m7Ki72f5AHTn8aUfbLMlkjCEMjkNbDEazgxP//r5ZvdLtenTj5/fzAbvhRAylKg+WCerL6cb 6+ejVs0kk6l0QuDAGWxaAv43LMDlQSbkZ/jC9PG6qksAa5pzsIhYx7S1IkdTTEJd7RflMM0p 2x//eTMqsWR7//PPl6kcAPQNhIV0fX56XNYyldnpoJXjPCeIIheRBtZG5f+BdX02WgU5X3/Y gZPLJ2u/sNxYuDyzzVFFSuXUuW0N0jQeyM5efn8apYLhov79x7EjEjDGxCS5oExPz2slKXXN w6pXkqRcIZcU5eE/sfzy/Pr2uJ5pU313OsyrolCebzXZD925IF+8pe/M+WigGdvtpBzBYa/Q sh5XNdAQ8Z59XhRZBCK4YmcwGG/O53mJ5wvj7X49HQ5Go3YhKffXRoP7a1++1Oj4ej3td7vd dj2uigwrDxfdlA+6u3NjTKa9sCzLtKy1VnVEG2Hk/rSTphEsVBxNmjEK8ni58mi5Nu39qp0I 0HxZM+2dtVmDGy6Wbk61yj32cV4egq+MjfVKX860QVPmfbhPrDSLPAH02eXBg8laH9xW83G7 IPjAY8RDcHJZCuMeiIrmS6kgUDs0mG6MZouFpmaCOEoJxe50uVxMuqVYiJOVWiqAONrlmBul hWypUimXCtkkzxAwhAWEGEeDRnfAMJpL5cuVUjYWIp13jxuhQhxLAnFC6XAEKIXLBXnZmFyu lmWRwSEPTIYT+Uq1nE9xfsIXFqMsyLkhOeVQ0s+wbDDI+CkcccQRJSgCfX8qAuXDfQwbCvpJ 1FE7kI7gjg4CTURwLwZE6c4NYWSADbMBEigakE+MCrAhlvEBfUS8JAnegb+gwGq3B3436F2q QQB4v74FqDgEIwgCZPk9clP4G6qj+7cgqA8j6EfKxwhcFk6lv0p9Iv4/Bwj7x19w0j5Hn84t 9rec/1nwWfu/d8pD4AplbmRzdHJlYW0KZW5kb2JqCjQzOCAwIG9iagoxODAyCmVuZG9iago0 NDEgMCBvYmoKPDwgL0xlbmd0aCA0NDIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggMTE3IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0Rl Y29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0Zp bHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVdZe9rIEjXahYRAEmLfQWYTIFaBwYBl IxYZEJvBTmzPTDI33/3/f+B2CzvgzMPkfkk/mO6u4zp0dZ3q4uLCHg7kOFA4EMThALv2Hpyc DbBnQ95gZ5b/f+pAcZIkcIJmWJZlnBSBAV57D0XOvTnQIwSgWIYmPhrPgT8xd6Cki/e4WI8/ mkgk4pGAwJIoijs9gpvGzs4KcJwNAahE1O+h0DPjT/B8gCCEOxiP+KSoovV63Sutmo8JNE55 IsmoQJ85duCuCIBc97rd7lWzEOHwD3H44PPfFgjuCmWLmVCkOLR2G2sxN29bGa/TKabLpYRA nhwjpDd/hCwW96O2fG77N5If7A7U6c/Vq5lQrD5/fnlYzq3t1uykeUZI1TuV2NlxECpQg5CF OZ1O9GaKP/tCPzj9x9IB8/J0GwgpZBpXakyKtdYvh2m33Z/t9rNaiHVF1H5XCdDouweEDkHI 5KpRq1WVjJ/9+fA6EIyA6fnmyoGx0eqgW/B7ItrqaaHJcbllHrbXSY725nq3nYznu2tAakPS oUDAL/EsiaG2uuxTgNlRUPaBjltQYMclSrIeN0MeVxcX8KL6o07Kw4Y1az9WfJz3crh70GU3 6Ypr4zs1+P2okBRAihJDgkEQJEWRUFzgFBRFoChG0KyLhVICW8BIUU4GKAsD3BQfSSeDPAPx 4LQoE2tNjHqYcQKPD0ZBZPhMf7MdZjicCqiG2Uu732Vjkz4YeZHCwMApzusTQIgR3Mn7vBxN sWIonowHBQYHeuP9AZ8/FIuFRIbAaDFd712pckRkYNwcOJ+7WYxKEgVJH81q1B+rjNbzdoxB cSGvL42y9J4vNulhpoZ5juNcrDuYKcgBBsOcvnRBDvFCOFttd7SqHHSRtJgqqeVStanVskHO ySfb5m496akpkQKkICOrs5We9RAgduvnnV5XtdFqa5T9FIK6UtfWXIsyb6kESdfP22ElK8vp RDiUrvc7WS9F8hmt38hEkmrfAGk96ikhzh2t3U1HNzej6bivhMVgafz57z/3s+tiwAmcgehe Wet+yoUBj9svf+7MmfX4eafnvRSCOKMdazNMc9gx6SDp9ssfm7E+HPY1JZ1rTyZanHOFa8a0 W8jWb+9N484wZ4NCQAJXdFiNBsPJct7Ph2Oq+frtdT3Ssj6YIRgn67v1VYwBpO3df7697vdP r6/7USXMYigVbC734wKPfyeFkJfdyrLmo1ZWbkys22JAuhwszI5S1a3VqF3vGNZ9Jx3O3T5+ uu+USp3petZMRop3j6+bGzUT5AgQXozPjw8rLUyj8BhfvxwW5ny12y36BT+Nkb7a4um+4iWO +oIn3f399XExnUxGfTURKQwtU8uk6hNrVFM684M1qBSqN9bmVkkU7va7m1wwkO1bVi8dSF2t HoxKhGcIWFZxoTR7spoBCpKuX/ajlqq2BuZ63pN5gvRW5p+WNR95It28HgxNLZeVbMwrxJqm ddeoDRfzbqE42H1eD+uVhr7cjCop5Xa7aEVYJty4Xw1kX7QJP3ggVOgKF8v3n6y6n4Skq8f7 etwnhbPdxYNZD9GkbWwEqBMpgDQSfq9X5F007c3rq6Uxmq8MNV3QH1+2d51WZziZXheSyu3G rPpI0qfOVjeXUrg2W16nXG8ZaZMu6z6b1NYpTbKB8uSw7SVY6p+kRwgOBoZibKy9OOz3e6sn h3P647M1bKjVhtZUQORv1zNVIglvebrSL32A1DojFUrm07IeeCMd5QUSpyVl8vQwSLkoO7wg DMeXxtbpA4TA4oAiKCkp46cvXz+b1bCU7u8eTS2XSqTSqagvkP9OOgGCBKQmCK8bP9ZBjC+M D1YzaN+pBZUveKRka/Fp242ztK+6eJqr54l0hLjdnIuhcNyV7O2//feTfilw0Ra4Ek0OB0PR WEjyn5Gu9awUqpqbkRLgnBQObhVzA8lY7YjTTiSo/Fy2pE0eQG0KOulAY3mYFIWTZOzioOZk WU5FvQxB+9X5X183rQhDS8W7taXXcpnLfEEOh/L6e3gngNTrL08fFt08qJFOUFRRNtG1VuD+ MDrYXP3xvB7runG/2c2v0h6SibSt7Y18Kg4Q8gIgw+GgW0uLFOHODLb7UUEkcVesOV0vx4Pe 9QBUu0h+uByXJQIXFWM5kAUxq28fzEFLiXvAXSF0sG5aQxBuyq/Onp4fN0D51mLcvvTSOCyD yw6owm/FgfJVpo/PBwhZzvqgpGF0oHJz14iyGHiV0+3JarWc309vqolgpmMM8gKB89m+0U66 uWhjutnM7zRZBKQOXCjcLu6KIknwmbZhmtOxcTtol5NeJ0bwOX05rvjeC76D4NPaaDabjMdj Q9eyEoXi7phSSoG+xYHCl2RgTMZ3/YbsF8LFZiXOYZgrWm4UggzFpxo3Y6NfTXhASXKgrkR7 alSDNO6UkvlSuVwq5jIxH0dhKOkrj+6vM278KNMLB+b0JvJKCQ6lkA64CPBQegLHe3KANzMs K5WKchnzsk7Q6oUFCoWbMVD7MPCgZkulfBycBXhDKH/pZtxOcjhOc7wIZC/wHMhM8PIy0ebo Vg19f8QvEAxCjkNww5IGZONkKAxKCjTFjFuUJNEDWgqMdLpYsO/ASMblBM86aB14ryRytP2K O3Au2dKv817Q6mJQ9ED2sA25QAhBvtLbGf57uwKa/ncIRNklzW75jzKGVgIMu4kBc9CqAC9w Aj6BEX+zwQRBKCl/da1G2PcG4Zg1DpQJlrpXRf/poEfDj39Bb3TaAouz1Wkfzs5toDOLlLR6 +ocuFsE9iapWjp61oB99/NoKITxxpZyRYCNxGkADqZLyodk+GX99BvJOiKZiAgVCfxoIyYOf FeL5z4qT8TfMAKtbFFj4pp8GgjO8+PEH1Mn4O2YIajeu5wcFCsBhM/vhi/wOrpMP2Jt/CC4w wR8fP+6d/uNXZv8DXyN1CAplbmRzdHJlYW0KZW5kb2JqCjQ0MiAwIG9iagoyMjAyCmVuZG9i ago0NDMgMCBvYmoKPDwgL0xlbmd0aCA0NDQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvV2lkdGggMjEgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAv RGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAv RmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAE1kntzmlAQxeUCAopUEB/RxEeDSUwU TZwCjVYdMj4CgV6QC2iDtpNO+/2/QUHs+fM3Z/fu2b2ZDAYAnggADMucheFZJs+ybD5HZwmQ YgynuOpVu91uXdYElsJB4sXIwmVfnU4nz+pjrykwROIFlNhbQLSFtmW+KJLI4DEFdO3Jig7+ dwt6nvn1upiNGwCmrriH8HWizQwUGE91Bj9B1dnbarfVVczQ+9YpnCEM1v0KJ94skK93PxGp E/qr+1Kel2ZbbyFx/+HOfLyqNodL19Ka+XO5GyF9PFKXjreSq3T6uup9/EKmAXfvSO+JZ6ih P3+PQbA/HoPlsMESIJlT9X5/hLZpOQjZs/tqnCmB7iFYKqORMjdda9rlsyCBzu5t3KqUG7cT 2zfHdeYET3MyFFuTN6E3bbN44oT+sidQJFPub/b+/HMhhaExagjFckexf3iTVup0I28xvLsd qBs/znaR9Lz44vyM3LWur962yHq+LpIA0NWRsY92WwdCaK+1m2T3WJaXtJVpvq5XL3NN7oi5 +EoYkSt3egNZHjzcSc0KR8cp44WSDMeXRLEk8FyeJtPLYwAnyJMIAj9/hn+6N1KkCmVuZHN0 cmVhbQplbmRvYmoKNDQ0IDAgb2JqCjQ1MAplbmRvYmoKNDQ1IDAgb2JqCjw8IC9MZW5ndGgg NDQ2IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWln aHQgMjcgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBv bGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBZZJtU9pAFIXZ3bySmKKRig3QYC1WG4mpKNAWpBBNAHHYJDTE6QgIMziO//9z FzEh6n5JdpNz9zzn3kQiXACSBUC4jT0BojmepeD7bwCxUnpHFmgY+331Cmkpd6QXMwL1ToaS Gb3dqR/I7FsZoFP7Tf8OV3MCeiODXMa4mT+Orw63mNcyQEmFuv/wNMdnShK9MgLZ9LF1ez+b +n+KKTpeESAxX73xh44/6v3Y5eMVIbN12HYH5oXt4caXD3EZSirla/fqVKv1h7b+kVvLiPOv TRc3DtTjyyH+pW6ssZfOrwP8u6h+b/0NbG07wgbUxl7Dn47Msl7p/Jt6P/MR9tJ5b7KYOPZl dzh7uLMibICEfM2bLyYjF7vB/WKGz0Ns4vybGYyDQdeyrB6+Ha+xUfJTue/jVrmkaVrpvO34 IfbS+YXjNI+UbVmW01mt5eD6ChtyOycdr2PsCgxN04yonHa9F2wkfq72B439VTzPNQb9Sl5E CdKOvZptnoShkpsN06oVJAoQ3pxeMdQwU8ikCkallCNhAcTLWVXZ5F4aCBC3qahZmSdzACle lAQ2mggydYIkchRJH0BEUSg2mdHBfw7LRK4KZW5kc3RyZWFtCmVuZG9iago0NDYgMCBvYmoK NDUxCmVuZG9iago0MjUgMCBvYmoKPDwgL0xlbmd0aCA0MjYgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2 aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21w b25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVtmSolgQLfbdBVfA HXFfUVQsNxRRyg1Fy9q6H2Y6YmL+/wfmYlV1T8fEvFW+QObNPCTck+dydwcMghFgMAx5ztcY hGAkw3EsTaBfBgujpD+azMoZKczhyNc0C6F0JNsYjCcjrZLw4/BXvD2EUJGCbu2do/MwbQg0 8hWgMBaQh5vTab/b71e9DId+CSgVb63dg6lrg9GonfoaUIRNDx132cpKSbmQjXqv/0Ewb8sg +HeDQBC6BSHv8snD9xBI/aAlwuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQBE6QNE0RBEl5nINg FCdJHEFQnGI5lsIR+D0E8iiawj1aImx25D4uazEGB4Yh7wTLZBJRH4kgGBuKhvlQPJGIhULR KM9iMIzRwWjYR5FsSExn0wLPYAhKBSKREB8REwJPo/AdTEva7skZl+Ic6AOGUTqcrWu6rlXT PIXR0Xy1rBQb3W4tL5eqSpxBUToqVxQxyEvF9kDvtxWBw4lAqlQpKBVVa8lhErmD8VDJcJ+c WTMdAg9BqGixv1jb9srQZJ4OZHtz435orKyx2hxM9WKYJIL5/qSbT2RbE8u218tRTeTYeG08 H+vj5dpoJ1gUglBGbJjuk7seFOMsTvDK0N7ZpmlvLS0djJQX7smeL6zlWG2N7HU/7eMk1bLv K8XOYruxTGvzMK3E+FR/6+5Mw1wZapJDoTsY46T67HC9HmZ10edLdh9O24mmzbaOWROF+sPr 88Owo6r1QkGznUU1HilM9xu91p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3mB8a5eGlgX57dRV2K l4zL47pXrQ3s866XTTS3b9d5NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23DcRfVRH58ed1psiQK Ee426YA3dCjTXrgv7rSaV73W9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV2X53X6lOL2+nWafZ nR/cZSOtjN1HsxxmQBrmaZLHYZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts2o92I0J4vCZC5fnx YC13R6slV+bP38+m3tNna3tcTimj43GUYT36eOoJuE4QGIoxQnP95M574+O3p7WutlStryqi 1FifrQqPecOFsKnB/ul6vTojRSrNn785s26r3e1rtbSQHx32gwT9KXEwxgR5P02QQWV2viz7 9/uXs9HMZ7M5OSOE4o31ySwHbyoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+TkXDISke8P255EfYIi VDijZIVQMF42zq6hdq2La9TToiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8L9nbP276iiSIyZQY Dsv3+60m/gJlpLquq9Vifbi57PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ//HB7CYaKVM2TM1dL +UIZjFfsP6AJ1dzYy7m1P5/mVUmqzA6nzWI8mkz6JUmsLw9GMfAushDmz0/P12UlRGBcSrNP h9V0NJ6OWllB1jd2R/jZKUxFK5PN8XRyzweznfD7xbqxOzp7MC7DkhArjS095/tQbpiKNw2z mwS7TPDyYH08HnZb22ino2l1YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1suZ6LREMJhvdqsh8 nDGg1VStnuMJoI9USO5MrfXKnHSVaCBWUFu5IO5JsGcQgnPRdLHebFRyMR8QR4yNZsqNZr2c E/wUFZRSgp/47AAhA3FP3CBQRgYlpdZs1gopwHkumkyEvfiHAYUl2UA4EuY56qbLKMkFPddH AaEkGI4hfp7bYAJohgSCeWuG8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J8BQMJzwXSDqYNqDs P5OBD/5kbi6oQj1d99a9+9/y3gvAkfOrFBxD//Z+Qno3v638X94/+3vn2QplbmRzdHJlYW0K ZW5kb2JqCjQyNiAwIG9iagoxNDA4CmVuZG9iago0MzUgMCBvYmoKPDwgL0xlbmd0aCA0MzYg MCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAy OCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRl IHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAGtVtmSolgQLfbdBVfAHXFfUVQsNxRRyg1Fy9q6H2Y6YmL+/wfmYlV1T8fEvFW+QObN PCTck+dydwcMghFgMAx5ztcYhGAkw3EsTaBfBgujpD+azMoZKczhyNc0C6F0JNsYjCcjrZLw 4/BXvD2EUJGCbu2do/MwbQg08hWgMBaQh5vTab/b71e9DId+CSgVb63dg6lrg9GonfoaUIRN Dx132cpKSbmQjXqv/0Ewb8sg+HeDQBC6BSHv8snD9xBI/aAlwuUmrjsrhFnWzwcZHL4RjGUZ EoNBLkaQBE6QNE0RBEl5nINgFCdJHEFQnGI5lsIR+D0E8iiawj1aImx25D4uazEGB4Yh7wTL ZBJRH4kgGBuKhvlQPJGIhULRKM9iMIzRwWjYR5FsSExn0wLPYAhKBSKREB8REwJPo/AdTEva 7skZl+Ic6AOGUTqcrWu6rlXTPIXR0Xy1rBQb3W4tL5eqSpxBUToqVxQxyEvF9kDvtxWBw4lA qlQpKBVVa8lhErmD8VDJcJ+cWTMdAg9BqGixv1jb9srQZJ4OZHtz435orKyx2hxM9WKYJIL5 /qSbT2RbE8u218tRTeTYeG08H+vj5dpoJ1gUglBGbJjuk7seFOMsTvDK0N7ZpmlvLS0djJQX 7smeL6zlWG2N7HU/7eMk1bLvK8XOYruxTGvzMK3E+FR/6+5Mw1wZapJDoTsY46T67HC9HmZ1 0edLdh9O24mmzbaOWROF+sPr88Owo6r1QkGznUU1HilM9xu91p47x+Wgo1vOVs/Fc6Pz28nQ 1E5Lid3mB8a5eGlgX57dRV2Kl4zL47pXrQ3s866XTTS3b9d5NSWK8YhQnjmbfj7XWTtLtaaD jZg2K23DcRfVRH58ed1psiQKEe426YA3dCjTXrgv7rSaV73W9FZraLt7PZ9qbl6cftJHURTJ JbWNY3bV2X53X6lOL2+nWafZnR/cZSOtjN1HsxxmQBrmaZLHYZTwiVXj/LzTm7rz/XU76fdH y4dlJ5ts2o92I0J4vCZC5fnxYC13R6slV+bP38+m3tNna3tcTimj43GUYT36eOoJuE4QGIox QnP95M574+O3p7WutlStryqi1FifrQqPecOFsKnB/ul6vTojRSrNn785s26r3e1rtbSQHx32 gwT9KXEwxgR5P02QQWV2viz79/uXs9HMZ7M5OSOE4o31ySwHbyoDE5Ha6uXPH2+bthSRJ5fn Tb+Uy+TkXDISke8P255EfYIiVDijZIVQMF42zq6hdq2La9TToiAlkzE+3lidFqV3UAjlsqPr X3+/zgu8L9nbP276iiSIyZQYDsv3+60m/gJlpLquq9Vifbi57PRSebhzH4Y1RSlVSumY+C/Q O5iMtXZ//HB7CYaKVM2TM1dL+UIZjFfsP6AJ1dzYy7m1P5/mVUmqzA6nzWI8mkz6JUmsLw9G MfAushDmz0/P12UlRGBcSrNPh9V0NJ6OWllB1jd2R/jZKUxFK5PN8XRyzweznfD7xbqxOzp7 MC7DkhArjS095/tQbpiKNw2zmwS7TPDyYH08HnZb22ino2l1YTRi5Oc39QaqOpivbHt5X0/6 CQK4+mK1suZ6LREMJhvdqsh8nDGg1VStnuMJoI9USO5MrfXKnHSVaCBWUFu5IO5JsGcQgnPR dLHebFRyMR8QR4yNZsqNZr2cE/wUFZRSgp/47AAhA3FP3CBQRgYlpdZs1gopwHkumkyEvfiH AYUl2UA4EuY56qbLKMkFPddHAaEkGI4hfp7bYAJohgSCeWuG8YeAigZYAkWAXrOg+hPTW4cR zBPoj18J8BQMJzwXSDqYNqDsP5OBD/5kbi6oQj1d99a9+9/y3gvAkfOrFBxD//Z+Qno3v638 X94/+3vn2QplbmRzdHJlYW0KZW5kb2JqCjQzNiAwIG9iagoxNDA4CmVuZG9iago0MjcgMCBv YmoKPDwgL0xlbmd0aCA0MjggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv V2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsg MCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtVtmSolgQLfbdBVfAHXFfUVQsNxRRyg1Fy9q6H2Y6 YmL+/wfmYlV1T8fEvFW+QObNPCTck+dydwcMghFgMAx5ztcYhGAkw3EsTaBfBgujpD+azMoZ KczhyNc0C6F0JNsYjCcjrZLw4/BXvD2EUJGCbu2do/MwbQg08hWgMBaQh5vTab/b71e9DId+ CSgVb63dg6lrg9GonfoaUIRNDx132cpKSbmQjXqv/0Ewb8sg+HeDQBC6BSHv8snD9xBI/aAl wuUmrjsrhFnWzwcZHL4RjGUZEoNBLkaQBE6QNE0RBEl5nINgFCdJHEFQnGI5lsIR+D0E8iia wj1aImx25D4uazEGB4Yh7wTLZBJRH4kgGBuKhvlQPJGIhULRKM9iMIzRwWjYR5FsSExn0wLP YAhKBSKREB8REwJPo/AdTEva7skZl+Ic6AOGUTqcrWu6rlXTPIXR0Xy1rBQb3W4tL5eqSpxB UToqVxQxyEvF9kDvtxWBw4lAqlQpKBVVa8lhErmD8VDJcJ+cWTMdAg9BqGixv1jb9srQZJ4O ZHtz435orKyx2hxM9WKYJIL5/qSbT2RbE8u218tRTeTYeG08H+vj5dpoJ1gUglBGbJjuk7se FOMsTvDK0N7ZpmlvLS0djJQX7smeL6zlWG2N7HU/7eMk1bLvK8XOYruxTGvzMK3E+FR/6+5M w1wZapJDoTsY46T67HC9HmZ10edLdh9O24mmzbaOWROF+sPr88Owo6r1QkGznUU1HilM9xu9 1p47x+Wgo1vOVs/Fc6Pz28nQ1E5Lid3mB8a5eGlgX57dRV2Kl4zL47pXrQ3s866XTTS3b9d5 NSWK8YhQnjmbfj7XWTtLtaaDjZg2K23DcRfVRH58ed1psiQKEe426YA3dCjTXrgv7rSaV73W 9FZraLt7PZ9qbl6cftJHURTJJbWNY3bV2X53X6lOL2+nWafZnR/cZSOtjN1HsxxmQBrmaZLH YZTwiVXj/LzTm7rz/XU76fdHy4dlJ5ts2o92I0J4vCZC5fnxYC13R6slV+bP38+m3tNna3tc Timj43GUYT36eOoJuE4QGIoxQnP95M574+O3p7WutlStryqi1FifrQqPecOFsKnB/ul6vToj RSrNn785s26r3e1rtbSQHx32gwT9KXEwxgR5P02QQWV2viz79/uXs9HMZ7M5OSOE4o31ySwH byoDE5Ha6uXPH2+bthSRJ5fnTb+Uy+TkXDISke8P255EfYIiVDijZIVQMF42zq6hdq2La9TT oiAlkzE+3lidFqV3UAjlsqPrX3+/zgu8L9nbP276iiSIyZQYDsv3+60m/gJlpLquq9Vifbi5 7PRSebhzH4Y1RSlVSumY+C/QO5iMtXZ//HB7CYaKVM2TM1dL+UIZjFfsP6AJ1dzYy7m1P5/m VUmqzA6nzWI8mkz6JUmsLw9GMfAushDmz0/P12UlRGBcSrNPh9V0NJ6OWllB1jd2R/jZKUxF K5PN8XRyzweznfD7xbqxOzp7MC7DkhArjS095/tQbpiKNw2zmwS7TPDyYH08HnZb22ino2l1 YTRi5Oc39QaqOpivbHt5X0/6CQK4+mK1suZ6LREMJhvdqsh8nDGg1VStnuMJoI9USO5MrfXK nHSVaCBWUFu5IO5JsGcQgnPRdLHebFRyMR8QR4yNZsqNZr2cE/wUFZRSgp/47AAhA3FP3CBQ RgYlpdZs1gopwHkumkyEvfiHAYUl2UA4EuY56qbLKMkFPddHAaEkGI4hfp7bYAJohgSCeWuG 8YeAigZYAkWAXrOg+hPTW4cRzBPoj18J8BQMJzwXSDqYNqDsP5OBD/5kbi6oQj1d99a9+9/y 3gvAkfOrFBxD//Z+Qno3v638X94/+3vn2QplbmRzdHJlYW0KZW5kb2JqCjQyOCAwIG9iagox NDA4CmVuZG9iago0MjkgMCBvYmoKPDwgL0xlbmd0aCA0MzAgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjEgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQovRGV2 aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21w b25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAE1kntzmlAQxeUCAopU EB/RxEeDSUwUTZwCjVYdMj4CgV6QC2iDtpNO+/2/QUHs+fM3Z/fu2b2ZDAYAnggADMucheFZ Js+ybD5HZwmQYgynuOpVu91uXdYElsJB4sXIwmVfnU4nz+pjrykwROIFlNhbQLSFtmW+KJLI 4DEFdO3Jig7+dwt6nvn1upiNGwCmrriH8HWizQwUGE91Bj9B1dnbarfVVczQ+9YpnCEM1v0K J94skK93PxGpE/qr+1Kel2ZbbyFx/+HOfLyqNodL19Ka+XO5GyF9PFKXjreSq3T6uup9/EKm AXfvSO+JZ6ihP3+PQbA/HoPlsMESIJlT9X5/hLZpOQjZs/tqnCmB7iFYKqORMjdda9rlsyCB zu5t3KqUG7cT2zfHdeYET3MyFFuTN6E3bbN44oT+sidQJFPub/b+/HMhhaExagjFckexf3iT Vup0I28xvLsdqBs/znaR9Lz44vyM3LWur962yHq+LpIA0NWRsY92WwdCaK+1m2T3WJaXtJVp vq5XL3NN7oi5+EoYkSt3egNZHjzcSc0KR8cp44WSDMeXRLEk8FyeJtPLYwAnyJMIAj9/hn+6 N1KkCmVuZHN0cmVhbQplbmRvYmoKNDMwIDAgb2JqCjQ1MAplbmRvYmoKNDQ5IDAgb2JqCjw8 IC9MZW5ndGggNDUwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFtUEFO hEAQvPOKOkIiMNPAAleJmnhYo0ziYeNBcTFrBLKLa+Lv7ZmeA6hwqHRPd1VXHXGPIxRIQSvK UW4qnPZ4xIi0mTW6GRpz93eih0o2yn042FkKeFa5//95K6SVQlFuULGUrmkhRSKlnVyw5OYt xxrzG6/bC7sBlwZVLn3GPE9KKooamgqYAem1TtgRTB+E22mMm7uHFu30cf48TOMcwbzjyrB1 Zz7JvI+2YcJfSbRIbziHt9nlYT26PAgZdMkShfXQO6J1bxmhshEufBB0FYgJTd4coYDmi+3x 5I/HDqGJEFcIzww1wr0AW7DVq8BzFNjqW6oLBl6AwFaak8CXgGcZpHpZNU9C5tczeVtzkjTV CuoITzC3Ptcf+Ud/DAplbmRzdHJlYW0KZW5kb2JqCjQ1MCAwIG9iagoyODkKZW5kb2JqCjQ0 NyAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQ0OCAwIFIgL1Jlc291cmNlcyA0NTEg MCBSIC9Db250ZW50cyA0NDkgMCBSIC9NZWRpYUJveApbMCAwIDEwMjQgNzg4XSA+PgplbmRv YmoKNDUxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8 IC9DczEgNyAwIFIgL0NzMiA4IDAgUiA+PiAvRXh0R1N0YXRlCjw8IC9HczEgMTIgMCBSID4+ IC9Gb250IDw8IC9GMS4wIDkgMCBSIC9GMi4wIDExIDAgUiA+PiA+PgplbmRvYmoKNDU0IDAg b2JqCjw8IC9MZW5ndGggNDU1IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAF1Uk1Pg0AQve+veEc2sXRn2S1w1MaaeKhRSDwYD7VSrSnFltboD/J/OsvSFNRCyGNn5+O9 mdngFhsoaAVS2iAeJdgWuMcaw3FNmNcg1PO/HguocKSaB0vnqwX7qub9398VIqVg4xESLkWp 7pTSvhQ15UQ3N0c1WQd8x+GO4bzERY7EeDujMWGsrU1B2iIvMZxQyIqQL0QwrdaD8c1dhqxa 7XfLal1L5G+4zFn6gROxfsfJWHWK01GvWDolXU42Vi2nmMJE+yv/qx2nOOTP9Ikh+JbiwONk PtMmY+QERPGvJA8IJhJkRFBtUXzOyvdVITFgOcGZRJoiwI1ExHi+371KPCK/PkpXYdSOMBsz 6c4SCF6CDMMrXoGXur8KGhGIBZN1rVo0PezbutujBG9DR54GHeZHrTZGy9K8Mt3ODawsZyUJ gj0DCyikcMDTc/DsYebhywNLdgHwMPXGysOHB9cdDi99sqeecetPbXjkT/2c2htVD1IpOn39 AS6QtNYKZW5kc3RyZWFtCmVuZG9iago0NTUgMCBvYmoKMzgzCmVuZG9iago0NTMgMCBvYmoK PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCA0NDggMCBSIC9SZXNvdXJjZXMgNDU2IDAgUiAvQ29u dGVudHMgNDU0IDAgUiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjQ1NiAw IG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSIC9DczIgOCAwIFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8 PCAvRjEuMCA5IDAgUiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjQ1OCAwIG9iago8PCAv TGVuZ3RoIDQ1OSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBfVNNb5tA EL3vr3hHkAreXcDAsbWaSDkkao2UQ9SDS3FDZCAGUzU/qP+zb1ncgD9qZL3dndmZ92Zn9viC PSS0hJI6RLxM0BZ4RI3FqlPIOyh0+bnHFtJfyuGH0vhqQV85fJf9TSIlJaJ4iYSpVKonqbRN pYZ0Yhqbt4aoHm28bhjmFT5lSEJ7TgxDP9ZRlELpCFmFxY3yqQjZVjj3Te2tHr6usW52/aFs 6s5F9oLPGaUfOSnqN5zCSF7j9K5XlEbJlFMUy5FTrPxEW5NdasMp9vkP58Tg/HHFkcfVeOEY jMgASsUnQZ7g3LhQoXCaFsXvTfW6K1x4lON8cJGmcPDgIiB+7A/PLr4hu7PSr6UUlyRoKa9I +FfK83jCPtOJhFSeS7gt6qLd7HZkDOcNLRVxUez78rhEV7Su8ALq+jVaaYrp5R0azxgxN+L/ Wi9y06zTrHnA8uZNVQ28+rrMN6Z/ppHZQGzWYByE9YpPfzJKayxuOUg/u/lAaQRQbBsVmYbb Dp34fiZOZlCaGZxUWEMdp0CNHUKM2CBWgB67H0/CyViaBE5PMEW1wBkwux8WNhbeLLBxzAVW 0MC9PWxYfV5g8SdRWBiz+z47NE/Bw/F6YHfzmNoGk9Y2Qjqr618l0v4xCmVuZHN0cmVhbQpl bmRvYmoKNDU5IDAgb2JqCjQ4MgplbmRvYmoKNDU3IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgNDQ4IDAgUiAvUmVzb3VyY2VzIDQ2MCAwIFIgL0NvbnRlbnRzIDQ1OCAwIFIgL01l ZGlhQm94ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iago0NjAgMCBvYmoKPDwgL1Byb2NTZXQg WyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+ IC9FeHRHU3RhdGUKPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOSAwIFIgL0Yy LjAgMTEgMCBSID4+ID4+CmVuZG9iago0NjIgMCBvYmoKPDwgL0xlbmd0aCA0NjMgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1UTW+cMBC98yveEaTC2gYWOLarJlIP iZpFyqHpgRBvQsVHF9iq+UH9nx3b0OL9aHtoVtFgjz3z3vPM7PERezAIBs5EhGSdope4R4vV ZuAoB3AM5emJHViwZvoPlTorHDrL9O/8eZWIM4Y4WSOlVDwTi1TCpOI6nbOMTbd0VJ98dF0h LBu8y5FGZp9sFAWJiOMMXMTIG6yueECMkO8c96Zr/c3t3Rbbrj6MVdcOHvIveJ8T9RkTJ/4K UxSzS5h+83UqxWSJKU7YhCnhQSqMy3wKhSkJ6D+ygcH94TkzjovxoikYWQrAeXIU5BPcKw88 ctyuh/xeNF9r6cEnOu4bD1kGF7ceQrJvD+OLh8/IPxjql1I65ygIxi5Q+CXlaTzHPNMRhYyd UriWreyLuibEcF/REyP6kPtDNX9ikL3n+CHx+jZ5yZXQKX/sfOWE7cSfuZ7FJkgnq3hA8pZd 02hch7YqC1U//xT5nIqhEP9JxZCLU6R3sq7kgK7FY1UXo1IUxfOsoGxkO+LBHV4KUlLr+/QX kaaath8wXFNbWR1GIg2ynPOMD95SID1egnCaFNsN9cbRrNlidU2T5nnQE0dNET1xBEJw6ise q47c6Va195ZDiqkhtShBAZ5Ob0xSqbHkk42pgwx4MY0H9cI51U4K90BGVZ0xNCTU6smYgmqP Vq9mRZ2lLpB6ytyYzc4Yqs5FFKoctXq0NlUh0+Z0PTQ+O6Ywm8wymaXrTySUQEoKZW5kc3Ry ZWFtCmVuZG9iago0NjMgMCBvYmoKNTU4CmVuZG9iago0NjEgMCBvYmoKPDwgL1R5cGUgL1Bh Z2UgL1BhcmVudCA0NDggMCBSIC9SZXNvdXJjZXMgNDY0IDAgUiAvQ29udGVudHMgNDYyIDAg UiAvTWVkaWFCb3gKWzAgMCAxMDI0IDc4OF0gPj4KZW5kb2JqCjQ2NCAwIG9iago8PCAvUHJv Y1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSIC9DczIgOCAw IFIgPj4gL0V4dEdTdGF0ZQo8PCAvR3MxIDEyIDAgUiA+PiAvRm9udCA8PCAvRjEuMCA5IDAg UiAvRjIuMCAxMSAwIFIgPj4gPj4KZW5kb2JqCjQ2NiAwIG9iago8PCAvTGVuZ3RoIDQ2NyAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1ZvbctzIkYbv8RR1SUZYEAqH KsB3kjyzh1h7xyNFrCNWe0FTrRF3KNESKU9439Pvs9+fVUADDTSblGZ8GIVNdrJQhcrK+vPP Q390v3cfXeXqyvmqbl0Mvfu0c//lPrinL269u7x13t1erke8dVUZKvvPXWlsXTC2sn/b47VQ 7ULfsVjv+mq2Tp3W8XmtceLiike8TfnE82wMnbt8756/cqFJUn76UDb14F2o3av37um3vmQr 7tVb99/u7D/PXTO4s2ef796dF//jXv27++YVGz665cMt6bWqsqv8EHjlqqy7auirtqikktpH 11ad83XPS3ht5y0v+ZNr3W9NIe7FS95E/16+mG+kcrHvtRHNUNf1OEPBDC/z6z199uy7//j1 y7u/XO/c0++uvXv+mxf23rM/vLj5cLf7cOee/zb/6bvdp8vdn+4+X1wXn0x1zK8TaVqWaVzb o2dU9G/vY+N+c5NX+iY/fdQGdK5mA/Oz8L3rptNo0rE/4Wd0ceMcXp89f33uvvnzeeE5Dt75 3D3xwZ25c7c8lfFlZrs8tf1iY/vOtt8N0+672rVtHHffnti9DmJ1Ax6y+6Yrm9ChAV/FyRoL s8az7y5+2J27V/+7N8Fxs5uav9cUi8kU2SGm2A29i1VTdu69CywfmsZdu9iGLL02aYwt0neL 0W+LR1msFurbaR3fdXkdCYu0jN+vkod+gVEfP1XwQ+bGpQvYWxjCeKrdV56qKREVJYSZ2XTT lpVvA6bdHBwqEPNy9wljZvTZn8+dWbc+e/8I4y4ed7eTcdcJF+voAsin/+WrHYqHX+0J3mfG vVBDMVND6Mqu67j4HixcQu3Z8wdY9nirNi17DrMjuIYIdgpcq2ENrsVDwJVn988fs8IvUr90 kM2wZonoK/RfCFrjCTOcub29e53pv0bDMQ7Fygy9L31s+saF9kD9mOFzrA73fXZz7kDYn25l lRlai+Tw7kWbLrut1dlkLVfmwkAy7RlfPLmwrvdl3YfgetDHN20DAnWxL/uq6STD76Cpa1xQ cF1XDsMQBj6+5KXEGUa/n1As1lgYz4WhK+sGb8VcA5ykEpp1sS2HGnuPHkOsqtpkaaUiVm0Z o00Nvm3M8zZ7YqMmC1rRAFIVk6N0XH1We75dT/gptMN5Lg0ejePN0n3HAwvb3fe7j593t7i2 vd7n6pwd8aS9vh3KrhEDaGMJ/+rZcc+v1RARBf5mW4p1VXh8OXrDaXMp0D8b6Zuh7Gs8TWjq MvS8K08HLyUPyKT2vm3LtulhR510i/aui3GB0PqyDY1n2LvNue7RWfRl3+P/AYSv0tjtn24+ 3OIWt1VmtGKiX9qxb7AIdqKd9tF1qO7aDZCvJGXDSAOs8LpgT7PRiZlJdUfZmIZ7LG+cvMaq bXJIi6Rpcl/rtzT5OPoYstxD2h7i3/oWBePuMrD3J4BlxNcFb/9oxmJ3VvuTalbA8o/p3xJ1 xWJ73C5+Z1TD8JX+baGGhX9ruDmdF3lb+bdnj/BvD8PS/blMaNB0oQxR8dEAcBJaFO9d0w2l 79oeWV32CTwDJlgzluBLl1fWt8LSJjC8amvXVaBuFVvN1bauHYSlkFRirJ6PfVdGm2VaqMXY fZVhYTUNF+8tbkD/1lAau6b0DaSzNlJGnDbDUd/AoniROZgmagyYPrv90X0LnsqDfRqRlOjA y6e90h/wajc/4uMsfpgAw0KiySvN1t9GJUKAFY6/Pru9+uHD7o376am7fXeB3zQW98bd7i7t Q3G2u3t9Pl9yDusb4WFCZ/Eo4NHgRJwcVUOQxcmTNJHlgKpGTj6OfgBWMXlRg/oj4W/MRWry JM1MHFY4Tj6O3sCq4gsCzERCl1wcM5XaIUEE919PQlFNPsUZCd3CKmwxhfv3cfGD8H9kQ48I NMc4G3VNcfYWF++w4qwGf0INpyBbNiQLWUH2JhfPgeZDuPhIQo9h1ciuE+/bwKoIc2kjqFxz rzPv42M5eOL62mOZMkZcpve4z+FerIodHGvouRg9lKcy3hebkHiMommujWCQyLroAhhpd2Za rYtd2dZdijq35jrOY2Krl4eyQzu3EWOL+WWidw88zYxtjhUzZzyBfu8HSDJuroHN1U0Mojbk tGLNxiWroDQAhwh0Q1h5yAGJCuCNZKI0tGnEmXv+v8VlSPs1jgQm2KK/BlIJ+xvnZoROS+5A bGY9zXG1yX0MXRdYZbyiM6A/Rpi/3725GtH18s7d3cxwHsJqWbqbT1f/d3F3dfPBkSp6FPbP 3ynfl9k7oeQQOGTXxmLDA1x9uLz+/GZ3617c3Px4BR99Qj707FfEUryX46Dt/f567iKfb/fv fewd73EXOIe9y8iUtq2VPUmUtjFDFqU1qQ5RpzvsWWeS44ct2Zh88UaCUfYsrtOElBeyacgE Jr6cpGly6EY2gv3oX8hNiNK2Po5uoj6BjyNM3UdpUc0/i5tYUFpF8tlNnMrGnnITOmZZyNpN bFHa7CYeQmlH/X+xm2i6viSEAY+ibiCgBA0lRK1aYRQySgGKa/vGF80gpD/CZtuSHDwgyUWO XSWQNEDkN7HZCJIZb2aRoR4El+MipB/KOGSYa8J6nuMwR9BRVkFXqB3TMTNIeSDMPb+4/NH9 dHX3bkQRahEPA7e559hDxkHmVyUELrXSXE3dyFBOwIKMxCoXMPz8lE75Z73vylUods91h7oy 9YkXnsq8jwZ37MIrOUaYtL7w5EsIPDagPRcexlTNqvBwkB37Aj5IgWLig6nusiw8+JRT1vZP pajn2z9WdmH764u+LzyQM11qwQoPWNxW5eFn2S3AMx42ZQdPwS3DWngEuj9qt55kWaw575r7 v9wtseTrswvu2F/PCznrN0tXrMrfSP1/jrIL9TvSdSkK4z7BJBXiEZ6bVFGYB7NExVR22Y9+ dNkFitoCAuCepgxGBLWQSa3wAmGI1bTQOHrjXn95QW0W7hGHk6EYT/pUzvuUA5NqpKaVA9sK 96akwX3h3phRPChyHhr8F+X+sxOAswdommwwG3z/lamphRoWqSnSCL9g6WXNSIm1zNhEGo16 ipCaEFuTULcvBQ5c+Tw4eZ4HV79hLUWo98ncYDRUCyVpWoik9bTQOHrDqH+OHIbIqe+mHMbw CPjaKqSJlaGmta/aMuq/fw5jQU4VeyWjHk6lck7d7ayG9d0mLlnnW/+W5JT2FUJvWCdFTdIA ncgpV7CM8D1kkEoYpyJv0g4MpaoiIN8kqN1A6qPD4dSBOSsjqDDHlPaorYjTkdRtmq4u6h4g tyhvWqym9ETwboa+NdVxjqq0ba/Cfk1yJMHnAzjqH/71e8XfF2+sWvjGXV5c7z68ufjkru52 78l0FmOnzMd96me+Uj7M+UpU7OKAAg5TrIV5ZAXYCwJ8LLO7dNdzCvwR0xDPmFcfe7JElDRI tKrToLcT7LleZIOoGVB+JCxQuTE2SvHoMHV6ZKSYR7F3zeMeUqpCjnwqETNHz/kxkiwKdUEC /5p6Yx1JCkuW566pN1bKbRkGrqc5fmBRaRdiFBoYrKSxTJKnoGKdohhTTvcd2tTeNDu0+Wpr 8yA4o3ar9MJmXvzooRUH6fjjh3Y0blFmk7Sgsh5KjqOPlBuXjF8l8xOdSUM5nROxjXZoKdOe qNOoEj1jkPE0dTBpTrtPnIwEax79C3kVdakMNMdZYpw+ta9PjKOYfJb/ZIlxI3jEQUDu/Vo4 5VN0yDKPBHgzLfwD5MWFWdaR4/mF+vR7AgJqcRQxA76hI+khIPEd3GcEpFX1zvLSdDb5hv4G 1ROYpM5JdA/qYtDkJuJAG6Gvq5KcoZBoXMfXsWw7G/YOISnu5VTHwQlcAvPAw6287nYbxIvs OhRYH/Q8zXDo3onZQUWOSAHMOpqbtVnMS3APnVu9Il77X8XFqjpm/7fj574PcTZ1hKMoWeKb h5YHzl5+vrzc3d7u68ULH7Z3p1YA0DVusIroqTPEGtSq4KCS6dBgvpJRTTFIpMQXoSFUfcc8 mbfpcGTKgFWhD/TBqAuHrjzlx+QWNTwnySjYMGOnBBKpImxoWgUOEXsqJ8jebc513GJaGp98 ioC2PNl0npnXrbSjgPwgKKvvaZtQDY6MDc/scy65BkcVW/TAh8p1rkFHGXE3kqsUVvi7Omd8 sJyZNXt++z6D84kUgVW+YQ1onIilqWmA6mAN752HcPS97wvJqgApMwlJgQYTpzuJ8MKajWAi knQ9MHZpsppKj8laXW+N6ho6ETSq9aGQAAaSHguykfTYUiYW06pToml82VTYy0pS8Jy4Tkv4 plFtTxY6SSJaQ0L/Aa5XMwWth2QI9A2k53DTlJhK31Ka9QP9WANpXJOoW0uSnlaq9FSnI9iQ rTRnu1vq8hI7VIM5tFv/iat5eWm1Skm5LYBnCu9LWs6U+uQQQpSikDRwPmmObglOWM95iot2 BuSmTELbqI6Ou6mbpzHDwJRJAnpDG0tPqYyjrNRHQevwJLNRJpOaNApJUMcbq60kUgFdwRGu qFFQv6TeBvNoAGpUag8NOAh9bqEjWduVpwNJskCl1TSZz1uSfAJZJQJ83l+LyXRMTVm2VtxK glVI39mwyZc3hH/JsDFLGTY6pMBosmzYOg3YjGk1WTbPMdA0Nlk27mugTUyjsmWj1wFyniR4 OBRNf5qOUECZLTvJbCqTmQrTKBi7WgvXkqToLipfj6IjJEODqEPLZsBHbpt1clEH1RuhehAz q7r2fO/B1N9yDmbaVK2zBGVIkrXCc+zcLtKBzPS01J00t5RkVdPNM7A+Kwg+mA8tI4tNhpSk ZZNw+/Za1nOe1L0ko5YJLKvBCgBJy+ySUBPF2yjwg6mpAUblImdaXslmOq3Llil5DtNNiJYl Cy2Tu1GIPFOzepSURdFzSc28GwqYqZlTxakayAAgSctqd+LtZlrmMebOBp01mGXS01J3KwnP bQBII9NBBRAzIr8M2K162CWjgEZgCITj0qQ5um11JyVB0ek+VJ76PCpAFoEbUyddmLAwcwd4 ASm4B5IM1NhlvjO6kXpO4eNcZpYmDDborfM1h9ftJRmyyS1nYNULS8G+x4EJfCEIKYSFGbAe Em7mqLuexh+TdcHsH3ioaSDWKL7AkSw7IaaeUyZBR9xmFB1l2vFCeVnAYWZtJo3PmewEJ3Wg ZJEG8sYJTqpI+DuqHcVAVDhlmy6rHeKDkWjIpPWeXlbtWTpOWud2SWmj1m2iwacDrVC6lCdw n4lsd0kAKMjL2iHYiCyQBtQEhyUbTsjzJgl9dJJ0QmZ7LL0PgDzQXJA0p64YDepFANBkiyvP AjiKJFkhPCUXk55ayOyll2rTNpaSSePWRj45yyI7y+Xg+7TOy03GvtR6Vt9jtW6mvtR6ogtz JT9K66a/hdbtHL5c6/mspKQ0k9z4WsdryR6/1ZBj1p+MGlSiZaczExaWcNJI5GL26kVCy0zC oNGqkamhaW/UCCAJcygBqT3WaBPJqu3lD2V7fQLC6htfCS7N/WWzBkxrPMto1syNz9C3xOyx ZNYgHxY7t2pQgCyfjZFZs1lJiDT0VLY4EFTR7sKss0wqmavt4DPmlmB7+cXC9C28PpFBWCFH ZawQb9cNEz8c+EMPI4EBy/l586jsElbGq+Jg7KZnAd1rsVP0PD1FwS7oiya8tny2RretWLBc AAlARhd7gSmfZOf8KRFO+jCmqUnzmmBaHAzlGHlqfEOtlaZGBqqIQE6Lj4LpDfNTvCHUOH/n Mn9/gujKbj1uSdEhXJDvodm3Ccx9AbYm8wFOYxJSBEgIV3TAkvClCt4dibimXfsDmb1qr6Ci JfXQqQdZL7+UpA0tZOZS0+zWMigXN603SvQcxmZvhQxIxzIlsTdXxpSwJs1k+0MSA3F5eq6H DaB3GKm+KWJO1nN/kgT2Jwlu3gR4UUzTvPNCRIRAyrAlOu715bmDj1rn4O+sRjlUa2hKJlwK RjvqoTWzF4H9qgV69rJQ3Yp+c5vItsRUROoKEyTTxlkciTiBjCsrh1+sr2auwgMZM0FWk0FM R3Yo0dYOZVovzT4axEpi+xvfam9I45tjgNnYxv1lkzTTGrWgvk/V98zoTVMmsUPM6tRjLcxH r7kUsbt0JEJZtHXwcX9k09+zFYxTTmaRBfZqoJjZzv5FuCRmXyaxlz28ZQm17EvFOkz9V9CQ t+oveOme/sutdz/cql3fnLZdW0iOJTOxUGvf0UR72WEq1ILhj/s8kjae86BAViqQkOVxVDOs M4IiBoPVH12okf5J784+84PWCLU5qp0x/SAFpk8X6cdf0g86IPUAlRv9+F0S3pwXGsnXn2az UDXSpz8uhHR7Spgfb9Kn5Zx1mqxKf8s/hnk67vf/D8NOpMAKZW5kc3RyZWFtCmVuZG9iago0 NjcgMCBvYmoKNDc1MwplbmRvYmoKNDY1IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQg NDQ4IDAgUiAvUmVzb3VyY2VzIDQ2OCAwIFIgL0NvbnRlbnRzIDQ2NiAwIFIgL01lZGlhQm94 ClswIDAgMTAyNCA3ODhdID4+CmVuZG9iago0NjggMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERG IC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3 IDAgUgovQ3MyIDggMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMSAxMiAwIFIgPj4gL0ZvbnQg PDwgL0YxLjAgOSAwIFIgL0YyLjAgMTEgMCBSCj4+IC9YT2JqZWN0IDw8IC9JbTg0IDQ5MSAw IFIgL0ltODMgNDg5IDAgUiAvSW03NSA0NzMgMCBSIC9JbTg1IDQ5MyAwIFIgL0ltODAKNDgz IDAgUiAvSW03NiA0NzUgMCBSIC9JbTczIDQ2OSAwIFIgL0ltNzkgNDgxIDAgUiAvSW04NyA0 OTcgMCBSIC9JbTkxIDUwNSAwIFIKL0ltODYgNDk1IDAgUiAvSW04OCA0OTkgMCBSIC9JbTkw IDUwMyAwIFIgL0ltODIgNDg3IDAgUiAvSW03NyA0NzcgMCBSIC9JbTkyCjUwNyAwIFIgL0lt OTMgNTA5IDAgUiAvSW03NCA0NzEgMCBSIC9JbTgxIDQ4NSAwIFIgL0ltNzggNDc5IDAgUiAv SW04OSA1MDEgMCBSCi9GbTEgNTExIDAgUiA+PiAvUHJvcGVydGllcyA8PCAvUGwyIDUxNSAw IFIgL1BsMSA0MCAwIFIgPj4gPj4KZW5kb2JqCjUxMSAwIG9iago8PCAvTGVuZ3RoIDUxMiAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0g L0Zvcm1UeXBlCjEgL0JCb3ggWzExIDMxMiAyMDAgNDYwXSAvUmVzb3VyY2VzIDUxMyAwIFIg L0dyb3VwIDw8IC9TIC9UcmFuc3BhcmVuY3kgL0NTCjggMCBSIC9JIHRydWUgL0sgZmFsc2Ug Pj4gPj4Kc3RyZWFtCngBlVTLjtNAELz7K4qbI7Gz7nl5fAQEB04sWOKw4hAZh0QkYRNnEeJj +RaqZ72JV+Gh5NLtnp7pqpqa7HCDHcSaBB8rbCBNMCHn60mu1SrA+WiScw62quAkGduEiA7C 1NlQOB4UUoLUpqrZLsHUrhauM6+NiK+125nGctU2ppYqnqYfYXTF8lTd4CO2uPKwjYWVBpIc 9n2uXr/r911/d7ifr7FfkUkFMRwiphHNFaUvug2uPywFw5Jsle9fDns1WHQDKkN6+vtTVgyd CsbDK1xlZqobJ7xsIXEsR+I0TSMeLqDl9DfOEA3aBW5RtssZEfii7Bm5uSSZFVPnUQ6Ya9ag 3OK4rG2RbYyW8dvYsc+7fNLeWfEJ7Vu8bh/u87/wrKnERotgz/EdZsVVCCgVphOUJ2yfFQFX tOIZFaslgS/a6UaExD7fsBAJ7Dmmh3kS7DHD5VDVOLEpzqS8mw4epfEE0Gmd3yphzTgwBgIc oOKp9ossbyL4H7mZifINip4x34DGCbvMWtWe1mNRXsyI3qgj4aX4VPyC5pjj/Xi8YlcuO/1m vGe09imnSEUPaGd8LVzJ3HhhX3mBnmyzgdixxYJ7A1dO1rn0FsSkOnGIVO78Go6K4YWC5WgF W1O7gw4evcS/ihMA1qMUD05i/0/tY8yOIlndFxmz9x6pcZ1O/5d99KmfPcSYHP8xhEY988+5 ctScY3oqqNpuJw9TtQuk9J3RUsvj81Rz+cd3Qo5qfn3L2Zz8XvMw/V79ylt4vL4jVenZlMzN b42sIasKZW5kc3RyZWFtCmVuZG9iago1MTIgMCBvYmoKNTg2CmVuZG9iago1MTMgMCBvYmoK PDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMiA4IDAgUiA+ PiAvRm9udCA8PCAvRjMuMCA1MTcgMCBSCj4+IC9TaGFkaW5nIDw8IC9TaDEgNTE2IDAgUiA+ PiA+PgplbmRvYmoKNTE2IDAgb2JqCjw8IC9Db2xvclNwYWNlIDggMCBSIC9TaGFkaW5nVHlw ZSAyIC9Db29yZHMgWyAwIDAgMTAwIDAgXSAvRG9tYWluIFsgMCAxIF0KL0V4dGVuZCBbIGZh bHNlIGZhbHNlIF0gL0Z1bmN0aW9uIDUxOCAwIFIgPj4KZW5kb2JqCjQ5MSAwIG9iago8PCAv TGVuZ3RoIDQ5MiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAx MTcgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01h c2sgNTE5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+ CnN0cmVhbQp4Ae3QMQEAAADCoPVPbQhfiEBhwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwIABAwbegQEungABCmVuZHN0cmVhbQplbmRvYmoKNDkyIDAg b2JqCjc2CmVuZG9iago0ODkgMCBvYmoKPDwgL0xlbmd0aCA0OTAgMCBSIC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjcgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQo4 IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgNTIxIDAgUiAvQml0c1BlckNvbXBvbmVu dCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4AWNgGAWjITAaAqMhMBoCoyEw GgKjITBgIQAACIsAAQplbmRzdHJlYW0KZW5kb2JqCjQ5MCAwIG9iagozMgplbmRvYmoKNDcz IDAgb2JqCjw8IC9MZW5ndGggNDc0IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDg1IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVycG9sYXRl IHRydWUgL1NNYXNrIDUyMyAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0 ZURlY29kZQo+PgpzdHJlYW0KeAHt0AENAAAAwqD3T20ON4hAYcCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMDA08AAG+QAAQplbmRzdHJlYW0KZW5kb2JqCjQ3NCAwIG9iago1NQplbmRv YmoKNDkzIDAgb2JqCjw8IC9MZW5ndGggNDk0IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDU5IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKOCAwIFIgL0ludGVy cG9sYXRlIHRydWUgL1NNYXNrIDUyNSAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVy IC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHt0DEBAAAAwqD1T20JT4hAYcCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDPwHBheCAAEKZW5kc3RyZWFtCmVuZG9iago0OTQgMCBvYmoKNTAKZW5k b2JqCjQ4MyAwIG9iago8PCAvTGVuZ3RoIDQ4NCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRl cnBvbGF0ZSB0cnVlIC9TTWFzayA1MjcgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDA gAEDBgwYMGDAgAEDBgwYMGDAwNPAABvkAAEKZW5kc3RyZWFtCmVuZG9iago0ODQgMCBvYmoK NTUKZW5kb2JqCjQ3NSAwIG9iago8PCAvTGVuZ3RoIDQ3NiAwIFIgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMSAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjggMCBS IC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA1MjkgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDgg L0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITBIQwAA BqUAAQplbmRzdHJlYW0KZW5kb2JqCjQ3NiAwIG9iagoyNwplbmRvYmoKNDY5IDAgb2JqCjw8 IC9MZW5ndGggNDcwIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDExNyAvSGVpZ2h0IDM0IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9T TWFzayA1MzEgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUK Pj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9tCF+IQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBt6BAS6eAAEKZW5kc3RyZWFtCmVuZG9iago0NzAg MCBvYmoKNzYKZW5kb2JqCjQ4MSAwIG9iago8PCAvTGVuZ3RoIDQ4MiAwIFIgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNyAvSGVpZ2h0IDI3IC9Db2xvclNwYWNl CjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA1MzMgMCBSIC9CaXRzUGVyQ29tcG9u ZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKj ITAaAqMhMGAhAAAIiwABCmVuZHN0cmVhbQplbmRvYmoKNDgyIDAgb2JqCjMyCmVuZG9iago0 OTcgMCBvYmoKPDwgL0xlbmd0aCA0OTggMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xh dGUgdHJ1ZSAvU01hc2sgNTM1IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ43iEBhwIABAwYMGDBgwIABAwYM GDBgwIABAwYMGDBgwMDTwAAb5AABCmVuZHN0cmVhbQplbmRvYmoKNDk4IDAgb2JqCjU1CmVu ZG9iago1MDUgMCBvYmoKPDwgL0xlbmd0aCA1MDYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggODUgL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50 ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgNTM3IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QAQ0AAADCoPdPbQ43iEBhwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwMDTwAAb5AABCmVuZHN0cmVhbQplbmRvYmoKNTA2IDAgb2Jq CjU1CmVuZG9iago0OTUgMCBvYmoKPDwgL0xlbmd0aCA0OTYgMCBSIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggOTUgL0hlaWdodCAzNCAvQ29sb3JTcGFjZQo4IDAg UiAvSW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgNTM5IDAgUiAvQml0c1BlckNvbXBvbmVudCA4 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4Ae3QMQEAAADCoPVPbQ0PiEBhwIAB AwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABAwYMGDBgwIABA18DAyXaAAEKZW5kc3RyZWFt CmVuZG9iago0OTYgMCBvYmoKNjYKZW5kb2JqCjQ5OSAwIG9iago8PCAvTGVuZ3RoIDUwMCAw IFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMSAvSGVpZ2h0IDI3 IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA1NDEgMCBSIC9C aXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AY BaMhMBoCoyEwGgKjITBIQwAABqUAAQplbmRzdHJlYW0KZW5kb2JqCjUwMCAwIG9iagoyNwpl bmRvYmoKNTAzIDAgb2JqCjw8IC9MZW5ndGggNTA0IDAgUiAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3BhY2UKOCAwIFIgL0lu dGVycG9sYXRlIHRydWUgL1NNYXNrIDU0MyAwIFIgL0JpdHNQZXJDb21wb25lbnQgOCAvRmls dGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAFjYBgFoyEwGgKjITAaAqMhMBoCoyEwYCEA AAiLAAEKZW5kc3RyZWFtCmVuZG9iago1MDQgMCBvYmoKMzIKZW5kb2JqCjQ4NyAwIG9iago8 PCAvTGVuZ3RoIDQ4OCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0 aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9T TWFzayA1NDUgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUK Pj4Kc3RyZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAwNPAABvkAAEKZW5kc3RyZWFtCmVuZG9iago0ODggMCBvYmoKNTUKZW5kb2JqCjQ3NyAw IG9iago8PCAvTGVuZ3RoIDQ3OCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCAxMDggL0hlaWdodCAyOCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUg dHJ1ZSAvU01hc2sgNTQ3IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlCj4+CnN0cmVhbQp4Ae3QgQAAAADDoPlTX+EAhVBhwIABAwYMGDBgwIABAwYMGDBg wIABAwYMGDBgwIABAwYMGDBgwMA7MCNwAAEKZW5kc3RyZWFtCmVuZG9iago0NzggMCBvYmoK NjMKZW5kb2JqCjUwNyAwIG9iago8PCAvTGVuZ3RoIDUwOCAwIFIgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMSAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCjggMCBS IC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA1NDkgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDgg L0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITBIQwAA BqUAAQplbmRzdHJlYW0KZW5kb2JqCjUwOCAwIG9iagoyNwplbmRvYmoKNTA5IDAgb2JqCjw8 IC9MZW5ndGggNTEwIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDIwMSAvSGVpZ2h0IDE2MCAvQ29sb3JTcGFjZQo4IDAgUiAvSW50ZXJwb2xhdGUgdHJ1ZSAv U01hc2sgNTUxIDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Cj4+CnN0cmVhbQp4Ae3QgQAAAADDoPlTH+SFUGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwY MGDAgAEDBgwYMGDAgAEDjwMDeO8AAQplbmRzdHJlYW0KZW5kb2JqCjUxMCAwIG9iago0NDMK ZW5kb2JqCjQ3MSAwIG9iago8PCAvTGVuZ3RoIDQ3MiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9XaWR0aCA1OSAvSGVpZ2h0IDM0IC9Db2xvclNwYWNlCjggMCBSIC9J bnRlcnBvbGF0ZSB0cnVlIC9TTWFzayA1NTMgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0Zp bHRlciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngB7dAxAQAAAMKg9U9tCU+IQGHAgAEDBgwY MGDAgAEDBgwYMGDAgAEDBgz8BwYXggABCmVuZHN0cmVhbQplbmRvYmoKNDcyIDAgb2JqCjUw CmVuZG9iago0ODUgMCBvYmoKPDwgL0xlbmd0aCA0ODYgMCBSIC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvV2lkdGggMjEgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQo4IDAgUiAv SW50ZXJwb2xhdGUgdHJ1ZSAvU01hc2sgNTU1IDAgUiAvQml0c1BlckNvbXBvbmVudCA4IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4AWNgGAWjITAaAqMhMBoCoyEwSEMAAAal AAEKZW5kc3RyZWFtCmVuZG9iago0ODYgMCBvYmoKMjcKZW5kb2JqCjQ3OSAwIG9iago8PCAv TGVuZ3RoIDQ4MCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4 NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVlIC9TTWFz ayA1NTcgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUKPj4K c3RyZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAEDBgwYMGDA wNPAABvkAAEKZW5kc3RyZWFtCmVuZG9iago0ODAgMCBvYmoKNTUKZW5kb2JqCjUwMSAwIG9i ago8PCAvTGVuZ3RoIDUwMiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCjggMCBSIC9JbnRlcnBvbGF0ZSB0cnVl IC9TTWFzayA1NTkgMCBSIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNv ZGUKPj4Kc3RyZWFtCngB7dABDQAAAMKg909tDjeIQGHAgAEDBgwYMGDAgAEDBgwYMGDAgAED BgwYMGDAwNPAABvkAAEKZW5kc3RyZWFtCmVuZG9iago1MDIgMCBvYmoKNTUKZW5kb2JqCjU1 NyAwIG9iago8PCAvTGVuZ3RoIDU1OCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNv ZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0 ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1W2ZKiWBAt9t0FV8AdcV9RVCw3FFHKDUXL 2rofZjpiYv7/B+ZiVXVPx8S8Vb5A5s08JNyT53J3BwyCEWAwDHnO1xiEYCTDcSxNoF8GC6Ok P5rMyhkpzOHI1zQLoXQk2xiMJyOtkvDj8Fe8PYRQkYJu7Z2j8zBtCDTyFaAwFpCHm9Npv9vv V70Mh34JKBVvrd2DqWuD0aid+hpQhE0PHXfZykpJuZCNeq//QTBvyyD4d4NAELoFIe/yycP3 EEj9oCXC5SauOyuEWdbPBxkcvhGMZRkSg0EuRpAETpA0TREESXmcg2AUJ0kcQVCcYjmWwhH4 PQTyKJrCPVoibHbkPi5rMQYHhiHvBMtkElEfiSAYG4qG+VA8kYiFQtEoz2IwjNHBaNhHkWxI TGfTAs9gCEoFIpEQHxETAk+j8B1MS9ruyRmX4hzoA4ZROpyta7quVdM8hdHRfLWsFBvdbi0v l6pKnEFROipXFDHIS8X2QO+3FYHDiUCqVCkoFVVryWESuYPxUMlwn5xZMx0CD0GoaLG/WNv2 ytBkng5ke3PjfmisrLHaHEz1Ypgkgvn+pJtPZFsTy7bXy1FN5Nh4bTwf6+Pl2mgnWBSCUEZs mO6Tux4U4yxO8MrQ3tmmaW8tLR2MlBfuyZ4vrOVYbY3sdT/t4yTVsu8rxc5iu7FMa/MwrcT4 VH/r7kzDXBlqkkOhOxjjpPrscL0eZnXR50t2H07biabNto5ZE4X6w+vzw7CjqvVCQbOdRTUe KUz3G73WnjvH5aCjW85Wz8Vzo/PbydDUTkuJ3eYHxrl4aWBfnt1FXYqXjMvjuletDezzrpdN NLdv13k1JYrxiFCeOZt+PtdZO0u1poONmDYrbcNxF9VEfnx53WmyJAoR7jbpgDd0KNNeuC/u tJpXvdb0Vmtou3s9n2puXpx+0kdRFMkltY1jdtXZfndfqU4vb6dZp9mdH9xlI62M3UezHGZA GuZpksdhlPCJVeP8vNObuvP9dTvp90fLh2Unm2zaj3YjQni8JkLl+fFgLXdHqyVX5s/fz6be 02dre1xOKaPjcZRhPfp46gm4ThAYijFCc/3kznvj47enta62VK2vKqLUWJ+tCo95w4WwqcH+ 6Xq9OiNFKs2fvzmzbqvd7Wu1tJAfHfaDBP0pcTDGBHk/TZBBZXa+LPv3+5ez0cxnszk5I4Ti jfXJLAdvKgMTkdrq5c8fb5u2FJEnl+dNv5TL5ORcMhKR7w/bnkR9giJUOKNkhVAwXjbOrqF2 rYtr1NOiICWTMT7eWJ0WpXdQCOWyo+tff7/OC7wv2ds/bvqKJIjJlBgOy/f7rSb+AmWkuq6r 1WJ9uLns9FJ5uHMfhjVFKVVK6Zj4L9A7mIy1dn/8cHsJhopUzZMzV0v5QhmMV+w/oAnV3NjL ubU/n+ZVSarMDqfNYjyaTPolSawvD0Yx8C6yEObPT8/XZSVEYFxKs0+H1XQ0no5aWUHWN3ZH +NkpTEUrk83xdHLPB7Od8PvFurE7OnswLsOSECuNLT3n+1BumIo3DbObBLtM8PJgfTwedlvb aKejaXVhNGLk5zf1Bqo6mK9se3lfT/oJArj6YrWy5notEQwmG92qyHycMaDVVK2e4wmgj1RI 7kyt9cqcdJVoIFZQW7kg7kmwZxCCc9F0sd5sVHIxHxBHjI1myo1mvZwT/BQVlFKCn/jsACED cU/cIFBGBiWl1mzWCinAeS6aTIS9+IcBhSXZQDgS5jnqpssoyQU910cBoSQYjiF+nttgAmiG BIJ5a4bxh4CKBlgCRYBes6D6E9NbhxHME+iPXwnwFAwnPBdIOpg2oOw/k4EP/mRuLqhCPV33 1r373/LeC8CR86sUHEP/9n5Ceje/rfxf3j/7e+fZCmVuZHN0cmVhbQplbmRvYmoKNTU4IDAg b2JqCjE0MDgKZW5kb2JqCjU1OSAwIG9iago8PCAvTGVuZ3RoIDU2MCAwIFIgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNl Ci9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1Bl ckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1W2ZKiWBAt 9t0FV8AdcV9RVCw3FFHKDUXL2rofZjpiYv7/B+ZiVXVPx8S8Vb5A5s08JNyT53J3BwyCEWAw DHnO1xiEYCTDcSxNoF8GC6OkP5rMyhkpzOHI1zQLoXQk2xiMJyOtkvDj8Fe8PYRQkYJu7Z2j 8zBtCDTyFaAwFpCHm9Npv9vvV70Mh34JKBVvrd2DqWuD0aid+hpQhE0PHXfZykpJuZCNeq// QTBvyyD4d4NAELoFIe/yycP3EEj9oCXC5SauOyuEWdbPBxkcvhGMZRkSg0EuRpAETpA0TREE SXmcg2AUJ0kcQVCcYjmWwhH4PQTyKJrCPVoibHbkPi5rMQYHhiHvBMtkElEfiSAYG4qG+VA8 kYiFQtEoz2IwjNHBaNhHkWxITGfTAs9gCEoFIpEQHxETAk+j8B1MS9ruyRmX4hzoA4ZROpyt a7quVdM8hdHRfLWsFBvdbi0vl6pKnEFROipXFDHIS8X2QO+3FYHDiUCqVCkoFVVryWESuYPx UMlwn5xZMx0CD0GoaLG/WNv2ytBkng5ke3PjfmisrLHaHEz1Ypgkgvn+pJtPZFsTy7bXy1FN 5Nh4bTwf6+Pl2mgnWBSCUEZsmO6Tux4U4yxO8MrQ3tmmaW8tLR2MlBfuyZ4vrOVYbY3sdT/t 4yTVsu8rxc5iu7FMa/MwrcT4VH/r7kzDXBlqkkOhOxjjpPrscL0eZnXR50t2H07biabNto5Z E4X6w+vzw7CjqvVCQbOdRTUeKUz3G73WnjvH5aCjW85Wz8Vzo/PbydDUTkuJ3eYHxrl4aWBf nt1FXYqXjMvjuletDezzrpdNNLdv13k1JYrxiFCeOZt+PtdZO0u1poONmDYrbcNxF9VEfnx5 3WmyJAoR7jbpgDd0KNNeuC/utJpXvdb0Vmtou3s9n2puXpx+0kdRFMkltY1jdtXZfndfqU4v b6dZp9mdH9xlI62M3UezHGZAGuZpksdhlPCJVeP8vNObuvP9dTvp90fLh2Unm2zaj3YjQni8 JkLl+fFgLXdHqyVX5s/fz6be02dre1xOKaPjcZRhPfp46gm4ThAYijFCc/3kznvj47enta62 VK2vKqLUWJ+tCo95w4WwqcH+6Xq9OiNFKs2fvzmzbqvd7Wu1tJAfHfaDBP0pcTDGBHk/TZBB ZXa+LPv3+5ez0cxnszk5I4TijfXJLAdvKgMTkdrq5c8fb5u2FJEnl+dNv5TL5ORcMhKR7w/b nkR9giJUOKNkhVAwXjbOrqF2rYtr1NOiICWTMT7eWJ0WpXdQCOWyo+tff7/OC7wv2ds/bvqK JIjJlBgOy/f7rSb+AmWkuq6r1WJ9uLns9FJ5uHMfhjVFKVVK6Zj4L9A7mIy1dn/8cHsJhopU zZMzV0v5QhmMV+w/oAnV3NjLubU/n+ZVSarMDqfNYjyaTPolSawvD0Yx8C6yEObPT8/XZSVE YFxKs0+H1XQ0no5aWUHWN3ZH+NkpTEUrk83xdHLPB7Od8PvFurE7OnswLsOSECuNLT3n+1Bu mIo3DbObBLtM8PJgfTwedlvbaKejaXVhNGLk5zf1Bqo6mK9se3lfT/oJArj6YrWy5notEQwm G92qyHycMaDVVK2e4wmgj1RI7kyt9cqcdJVoIFZQW7kg7kmwZxCCc9F0sd5sVHIxHxBHjI1m yo1mvZwT/BQVlFKCn/jsACEDcU/cIFBGBiWl1mzWCinAeS6aTIS9+IcBhSXZQDgS5jnqpsso yQU910cBoSQYjiF+nttgAmiGBIJ5a4bxh4CKBlgCRYBes6D6E9NbhxHME+iPXwnwFAwnPBdI Opg2oOw/k4EP/mRuLqhCPV331r373/LeC8CR86sUHEP/9n5Ceje/rfxf3j/7e+fZCmVuZHN0 cmVhbQplbmRvYmoKNTYwIDAgb2JqCjE0MDgKZW5kb2JqCjU0MyAwIG9iago8PCAvTGVuZ3Ro IDU0NCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyNyAvSGVp Z2h0IDI3IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJw b2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4AWWSbVPaQBSF2d28kpiikYoN0GAtVhuJqSjQFqQQTQBx2CQ0xOkICDM4jv// cxcxIep+SXaTc/c8595EIlwAkgVAuI09AaI5nqXg+28AsVJ6RxZoGPt99QppKXekFzMC9U6G khm93akfyOxbGaBT+03/DldzAnojg1zGuJk/jq8Ot5jXMkBJhbr/8DTHZ0oSvTIC2fSxdXs/ m/p/iik6XhEgMV+98YeOP+r92OXjFSGzddh2B+aF7eHGlw9xGUoq5Wv36lSr9Ye2/pFby4jz r00XNw7U48sh/qVurLGXzq8D/Luofm/9DWxtO8IG1MZew5+OzLJe6fybej/zEfbSeW+ymDj2 ZXc4e7izImyAhHzNmy8mIxe7wf1ihs9DbOL8mxmMg0HXsqwevh2vsVHyU7nv41a5pGla6bzt +CH20vmF4zSPlG1ZltNZreXg+gobcjsnHa9j7AoMTdOMqJx2vRdsJH6u9geN/VU8zzUG/Upe RAnSjr2abZ6EoZKbDdOqFSQKEN6cXjHUMFPIpApGpZQjYQHEy1lV2eReGggQt6moWZkncwAp XpQENpoIMnWCJHIUSR9ARFEoNpnRwX8Oy0SuCmVuZHN0cmVhbQplbmRvYmoKNTQ0IDAgb2Jq CjQ1MQplbmRvYmoKNTE5IDAgb2JqCjw8IC9MZW5ndGggNTIwIDAgUiAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDExNyAvSGVpZ2h0IDM0IC9Db2xvclNwYWNlCi9E ZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNv bXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1XWXvayBI12oWE QBJi30FmEyBWgcGAZSMWGRCbwU5sz0wyN9/9/3/gdgs74MzD5H5JP5juruM6dHWd6uLiwh4O 5DhQOBDE4QC79h6cnA2wZ0PeYGeW/3/qQHGSJHCCZliWZZwUgQFeew9Fzr050CMEoFiGJj4a z4E/MXegpIv3uFiPP5pIJOKRgMCSKIo7PYKbxs7OCnCcDQGoRNTvodAz40/wfIAghDsYj/ik qKL1et0rrZqPCTROeSLJqECfOXbgrgiAXPe63e5VsxDh8A9x+ODz3xYI7gpli5lQpDi0dhtr MTdvWxmv0ymmy6WEQJ4cI6Q3f4QsFvejtnxu+zeSH+wO1OnP1auZUKw+f355WM6t7dbspHlG SNU7ldjZcRAqUIOQhTmdTvRmij/7Qj84/cfSAfPydBsIKWQaV2pMirXWL4dpt92f7fazWoh1 RdR+VwnQ6LsHhA5ByOSqUatVlYyf/fnwOhCMgOn55sqBsdHqoFvweyLa6mmhyXG5ZR6210mO 9uZ6t52M57trQGpD0qFAwC/xLImhtrrsU4DZUVD2gY5bUGDHJUqyHjdDHlcXF/Ci+qNOysOG NWs/Vnyc93K4e9BlN+mKa+M7Nfj9qJAUQIoSQ4JBECRFkVBc4BQURaAoRtCsi4VSAlvASFFO BigLA9wUH0kngzwD8eC0KBNrTYx6mHECjw9GQWT4TH+zHWY4nAqohtlLu99lY5M+GHmRwsDA Kc7rE0CIEdzJ+7wcTbFiKJ6MBwUGB3rj/QGfPxSLhUSGwGgxXe9dqXJEZGDcHDifu1mMShIF SR/NatQfq4zW83aMQXEhry+NsvSeLzbpYaaGeY7jXKw7mCnIAQbDnL50QQ7xQjhbbXe0qhx0 kbSYKqnlUrWp1bJBzskn2+ZuPempKZECpCAjq7OVnvUQIHbr551eV7XRamuU/RSCulLX1lyL Mm+pBEnXz9thJSvL6UQ4lK73O1kvRfIZrd/IRJJq3wBpPeopIc4drd1NRzc3o+m4r4TFYGn8 +e8/97PrYsAJnIHoXlnrfsqFAY/bL3/uzJn1+Hmn570UgjijHWszTHPYMekg6fbLH5uxPhz2 NSWda08mWpxzhWvGtFvI1m/vTePOMGeDQkACV3RYjQbDyXLez4djqvn67XU90rI+mCEYJ+u7 9VWMAaTt3X++ve73T6+v+1ElzGIoFWwu9+MCj38nhZCX3cqy5qNWVm5MrNtiQLocLMyOUtWt 1ahd7xjWfScdzt0+frrvlEqd6XrWTEaKd4+vmxs1E+QIEF6Mz48PKy1Mo/AYX78cFuZ8tdst +gU/jZG+2uLpvuIljvqCJ939/fVxMZ1MRn01ESkMLVPLpOoTa1RTOvODNagUqjfW5lZJFO72 u5tcMJDtW1YvHUhdrR6MSoRnCFhWcaE0e7KaAQqSrl/2o5aqtgbmet6TeYL0VuafljUfeSLd vB4MTS2XlWzMK8SapnXXqA0X826hONh9Xg/rlYa+3IwqKeV2u2hFWCbcuF8NZF+0CT94IFTo ChfL95+sup+EpKvH+3rcJ4Wz3cWDWQ/RpG1sBKgTKYA0En6vV+RdNO3N66ulMZqvDDVd0B9f tnedVmc4mV4Xksrtxqz6SNKnzlY3l1K4Nltep1xvGWmTLus+m9TWKU2ygfLksO0lWOqfpEcI DgaGYmysvTjs93urJ4dz+uOzNWyo1YbWVEDkb9czVSIJb3m60i99gNQ6IxVK5tOyHngjHeUF EqclZfL0MEi5KDu8IAzHl8bW6QOEwOKAIigpKeOnL18/m9WwlO7vHk0tl0qk0qmoL5D/TjoB ggSkJgivGz/WQYwvjA9WM2jfqQWVL3ikZGvxaduNs7Svuniaq+eJdIS43ZyLoXDcleztv/33 k34pcNEWuBJNDgdD0VhI8p+RrvWsFKqam5ES4JwUDm4VcwPJWO2I004kqPxctqRNHkBtCjrp QGN5mBSFk2Ts4qDmZFlORb0MQfvV+V9fN60IQ0vFu7Wl13KZy3xBDofy+nt4J4DU6y9PHxbd PKiRTlBUUTbRtVbg/jA62Fz98bwe67pxv9nNr9Iekom0re2NfCoOEPICIMPhoFtLixThzgy2 +1FBJHFXrDldL8eD3vUAVLtIfrgclyUCFxVjOZAFMatvH8xBS4l7wF0hdLBuWkMQbsqvzp6e HzdA+dZi3L700jgsg8sOqMJvxYHyVaaPzwcIWc76oKRhdKByc9eIshh4ldPtyWq1nN9Pb6qJ YKZjDPICgfPZvtFOurloY7rZzO80WQSkDlwo3C7uiiJJ8Jm2YZrTsXE7aJeTXidG8Dl9Oa74 3gu+g+DT2mg2m4zHY0PXshKF4u6YUkqBvsWBwpdkYEzGd/2G7BfCxWYlzmGYK1puFIIMxaca N2OjX014QElyoK5Ee2pUgzTulJL5UrlcKuYyMR9HYSjpK4/urzNu/CjTCwfm9CbySgkOpZAO uAjwUHoCx3tygDczLCuVinIZ87JO0OqFBQqFmzFQ+zDwoGZLpXwcnAV4Qyh/6WbcTnI4TnO8 CGQv8BzITPDyMtHm6FYNfX/ELxAMQo5DcMOSBmTjZCgMSgo0xYxblCTRA1oKjHS6WLDvwEjG 5QTPOmgdeK8kcrT9ijtwLtnSr/Ne0OpiUPRA9rANuUAIQb7S2xn+e7sCmv53CETZJc1u+Y8y hlYCDLuJAXPQqgAvcAI+gRF/s8EEQSgpf3WtRtj3BuGYNQ6UCZa6V0X/6aBHw49/QW902gKL s9VpH87ObaAzi5S0evqHLhbBPYmqVo6etaAfffzaCiE8caWckWAjcRpAA6mS8qHZPhl/fQby ToimYgIFQn8aCMmDnxXi+c+Kk/E3zACrWxRY+KafBoIzvPjxB9TJ+DtmCGo3rucHBQrAYTP7 4Yv8Dq6TD9ibfwguMMEfHz/unf7jV2b/A18jdQgKZW5kc3RyZWFtCmVuZG9iago1MjAgMCBv YmoKMjIwMgplbmRvYmoKNTI3IDAgb2JqCjw8IC9MZW5ndGggNTI4IDAgUiAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UK L0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVy Q29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVbZkqJYEC32 3QVXwB1xX1FULDcUUcoNRcvauh9mOmJi/v8H5mJVdU/HxLxVvkDmzTwk3JPncncHDIIRYDAM ec7XGIRgJMNxLE2gXwYLo6Q/mszKGSnM4cjXNAuhdCTbGIwnI62S8OPwV7w9hFCRgm7tnaPz MG0INPIVoDAWkIeb02m/2+9XvQyHfgkoFW+t3YOpa4PRqJ36GlCETQ8dd9nKSkm5kI16r/9B MG/LIPh3g0AQugUh7/LJw/cQSP2gJcLlJq47K4RZ1s8HGRy+EYxlGRKDQS5GkAROkDRNEQRJ eZyDYBQnSRxBUJxiOZbCEfg9BPIomsI9WiJsduQ+LmsxBgeGIe8Ey2QSUR+JIBgbiob5UDyR iIVC0SjPYjCM0cFo2EeRbEhMZ9MCz2AISgUikRAfERMCT6PwHUxL2u7JGZfiHOgDhlE6nK1r uq5V0zyF0dF8tawUG91uLS+XqkqcQVE6KlcUMchLxfZA77cVgcOJQKpUKSgVVWvJYRK5g/FQ yXCfnFkzHQIPQahosb9Y2/bK0GSeDmR7c+N+aKyssdocTPVimCSC+f6km09kWxPLttfLUU3k 2HhtPB/r4+XaaCdYFIJQRmyY7pO7HhTjLE7wytDe2aZpby0tHYyUF+7Jni+s5Vhtjex1P+3j JNWy7yvFzmK7sUxr8zCtxPhUf+vuTMNcGWqSQ6E7GOOk+uxwvR5mddHnS3YfTtuJps22jlkT hfrD6/PDsKOq9UJBs51FNR4pTPcbvdaeO8floKNbzlbPxXOj89vJ0NROS4nd5gfGuXhpYF+e 3UVdipeMy+O6V60N7POul000t2/XeTUlivGIUJ45m34+11k7S7Wmg42YNittw3EX1UR+fHnd abIkChHuNumAN3Qo0164L+60mle91vRWa2i7ez2fam5enH7SR1EUySW1jWN21dl+d1+pTi9v p1mn2Z0f3GUjrYzdR7McZkAa5mmSx2GU8IlV4/y805u68/11O+n3R8uHZSebbNqPdiNCeLwm QuX58WAtd0erJVfmz9/Ppt7TZ2t7XE4po+NxlGE9+njqCbhOEBiKMUJz/eTOe+Pjt6e1rrZU ra8qotRYn60Kj3nDhbCpwf7per06I0UqzZ+/ObNuq93ta7W0kB8d9oME/SlxMMYEeT9NkEFl dr4s+/f7l7PRzGezOTkjhOKN9cksB28qAxOR2urlzx9vm7YUkSeX502/lMvk5FwyEpHvD9ue RH2CIlQ4o2SFUDBeNs6uoXati2vU06IgJZMxPt5YnRald1AI5bKj619/v84LvC/Z2z9u+ook iMmUGA7L9/utJv4CZaS6rqvVYn24uez0Unm4cx+GNUUpVUrpmPgv0DuYjLV2f/xwewmGilTN kzNXS/lCGYxX7D+gCdXc2Mu5tT+f5lVJqswOp81iPJpM+iVJrC8PRjHwLrIQ5s9Pz9dlJURg XEqzT4fVdDSejlpZQdY3dkf42SlMRSuTzfF0cs8Hs53w+8W6sTs6ezAuw5IQK40tPef7UG6Y ijcNs5sEu0zw8mB9PB52W9top6NpdWE0YuTnN/UGqjqYr2x7eV9P+gkCuPpitbLmei0RDCYb 3arIfJwxoNVUrZ7jCaCPVEjuTK31ypx0lWggVlBbuSDuSbBnEIJz0XSx3mxUcjEfEEeMjWbK jWa9nBP8FBWUUoKf+OwAIQNxT9wgUEYGJaXWbNYKKcB5LppMhL34hwGFJdlAOBLmOeqmyyjJ BT3XRwGhJBiOIX6e22ACaIYEgnlrhvGHgIoGWAJFgF6zoPoT01uHEcwT6I9fCfAUDCc8F0g6 mDag7D+TgQ/+ZG4uqEI9XffWvfvf8t4LwJHzqxQcQ//2fkJ6N7+t/F/eP/t759kKZW5kc3Ry ZWFtCmVuZG9iago1MjggMCBvYmoKMTQwOAplbmRvYmoKNTM3IDAgb2JqCjw8IC9MZW5ndGgg NTM4IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWln aHQgMjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBv bGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBrVbZkqJYEC323QVXwB1xX1FULDcUUcoNRcvauh9mOmJi/v8H5mJVdU/HxLxV vkDmzTwk3JPncncHDIIRYDAMec7XGIRgJMNxLE2gXwYLo6Q/mszKGSnM4cjXNAuhdCTbGIwn I62S8OPwV7w9hFCRgm7tnaPzMG0INPIVoDAWkIeb02m/2+9XvQyHfgkoFW+t3YOpa4PRqJ36 GlCETQ8dd9nKSkm5kI16r/9BMG/LIPh3g0AQugUh7/LJw/cQSP2gJcLlJq47K4RZ1s8HGRy+ EYxlGRKDQS5GkAROkDRNEQRJeZyDYBQnSRxBUJxiOZbCEfg9BPIomsI9WiJsduQ+LmsxBgeG Ie8Ey2QSUR+JIBgbiob5UDyRiIVC0SjPYjCM0cFo2EeRbEhMZ9MCz2AISgUikRAfERMCT6Pw HUxL2u7JGZfiHOgDhlE6nK1ruq5V0zyF0dF8tawUG91uLS+XqkqcQVE6KlcUMchLxfZA77cV gcOJQKpUKSgVVWvJYRK5g/FQyXCfnFkzHQIPQahosb9Y2/bK0GSeDmR7c+N+aKyssdocTPVi mCSC+f6km09kWxPLttfLUU3k2HhtPB/r4+XaaCdYFIJQRmyY7pO7HhTjLE7wytDe2aZpby0t HYyUF+7Jni+s5Vhtjex1P+3jJNWy7yvFzmK7sUxr8zCtxPhUf+vuTMNcGWqSQ6E7GOOk+uxw vR5mddHnS3YfTtuJps22jlkThfrD6/PDsKOq9UJBs51FNR4pTPcbvdaeO8floKNbzlbPxXOj 89vJ0NROS4nd5gfGuXhpYF+e3UVdipeMy+O6V60N7POul000t2/XeTUlivGIUJ45m34+11k7 S7Wmg42YNittw3EX1UR+fHndabIkChHuNumAN3Qo0164L+60mle91vRWa2i7ez2fam5enH7S R1EUySW1jWN21dl+d1+pTi9vp1mn2Z0f3GUjrYzdR7McZkAa5mmSx2GU8IlV4/y805u68/11 O+n3R8uHZSebbNqPdiNCeLwmQuX58WAtd0erJVfmz9/Ppt7TZ2t7XE4po+NxlGE9+njqCbhO EBiKMUJz/eTOe+Pjt6e1rrZUra8qotRYn60Kj3nDhbCpwf7per06I0UqzZ+/ObNuq93ta7W0 kB8d9oME/SlxMMYEeT9NkEFldr4s+/f7l7PRzGezOTkjhOKN9cksB28qAxOR2urlzx9vm7YU kSeX502/lMvk5FwyEpHvD9ueRH2CIlQ4o2SFUDBeNs6uoXati2vU06IgJZMxPt5YnRald1AI 5bKj619/v84LvC/Z2z9u+ookiMmUGA7L9/utJv4CZaS6rqvVYn24uez0Unm4cx+GNUUpVUrp mPgv0DuYjLV2f/xwewmGilTNkzNXS/lCGYxX7D+gCdXc2Mu5tT+f5lVJqswOp81iPJpM+iVJ rC8PRjHwLrIQ5s9Pz9dlJURgXEqzT4fVdDSejlpZQdY3dkf42SlMRSuTzfF0cs8Hs53w+8W6 sTs6ezAuw5IQK40tPef7UG6YijcNs5sEu0zw8mB9PB52W9top6NpdWE0YuTnN/UGqjqYr2x7 eV9P+gkCuPpitbLmei0RDCYb3arIfJwxoNVUrZ7jCaCPVEjuTK31ypx0lWggVlBbuSDuSbBn EIJz0XSx3mxUcjEfEEeMjWbKjWa9nBP8FBWUUoKf+OwAIQNxT9wgUEYGJaXWbNYKKcB5LppM hL34hwGFJdlAOBLmOeqmyyjJBT3XRwGhJBiOIX6e22ACaIYEgnlrhvGHgIoGWAJFgF6zoPoT 01uHEcwT6I9fCfAUDCc8F0g6mDag7D+TgQ/+ZG4uqEI9XffWvfvf8t4LwJHzqxQcQ//2fkJ6 N7+t/F/eP/t759kKZW5kc3RyZWFtCmVuZG9iago1MzggMCBvYmoKMTQwOAplbmRvYmoKNTQ1 IDAgb2JqCjw8IC9MZW5ndGggNTQ2IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDg1IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29k ZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRl cgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVbZkqJYEC323QVXwB1xX1FULDcUUcoNRcva uh9mOmJi/v8H5mJVdU/HxLxVvkDmzTwk3JPncncHDIIRYDAMec7XGIRgJMNxLE2gXwYLo6Q/ mszKGSnM4cjXNAuhdCTbGIwnI62S8OPwV7w9hFCRgm7tnaPzMG0INPIVoDAWkIeb02m/2+9X vQyHfgkoFW+t3YOpa4PRqJ36GlCETQ8dd9nKSkm5kI16r/9BMG/LIPh3g0AQugUh7/LJw/cQ SP2gJcLlJq47K4RZ1s8HGRy+EYxlGRKDQS5GkAROkDRNEQRJeZyDYBQnSRxBUJxiOZbCEfg9 BPIomsI9WiJsduQ+LmsxBgeGIe8Ey2QSUR+JIBgbiob5UDyRiIVC0SjPYjCM0cFo2EeRbEhM Z9MCz2AISgUikRAfERMCT6PwHUxL2u7JGZfiHOgDhlE6nK1ruq5V0zyF0dF8tawUG91uLS+X qkqcQVE6KlcUMchLxfZA77cVgcOJQKpUKSgVVWvJYRK5g/FQyXCfnFkzHQIPQahosb9Y2/bK 0GSeDmR7c+N+aKyssdocTPVimCSC+f6km09kWxPLttfLUU3k2HhtPB/r4+XaaCdYFIJQRmyY 7pO7HhTjLE7wytDe2aZpby0tHYyUF+7Jni+s5Vhtjex1P+3jJNWy7yvFzmK7sUxr8zCtxPhU f+vuTMNcGWqSQ6E7GOOk+uxwvR5mddHnS3YfTtuJps22jlkThfrD6/PDsKOq9UJBs51FNR4p TPcbvdaeO8floKNbzlbPxXOj89vJ0NROS4nd5gfGuXhpYF+e3UVdipeMy+O6V60N7POul000 t2/XeTUlivGIUJ45m34+11k7S7Wmg42YNittw3EX1UR+fHndabIkChHuNumAN3Qo0164L+60 mle91vRWa2i7ez2fam5enH7SR1EUySW1jWN21dl+d1+pTi9vp1mn2Z0f3GUjrYzdR7McZkAa 5mmSx2GU8IlV4/y805u68/11O+n3R8uHZSebbNqPdiNCeLwmQuX58WAtd0erJVfmz9/Ppt7T Z2t7XE4po+NxlGE9+njqCbhOEBiKMUJz/eTOe+Pjt6e1rrZUra8qotRYn60Kj3nDhbCpwf7p er06I0UqzZ+/ObNuq93ta7W0kB8d9oME/SlxMMYEeT9NkEFldr4s+/f7l7PRzGezOTkjhOKN 9cksB28qAxOR2urlzx9vm7YUkSeX502/lMvk5FwyEpHvD9ueRH2CIlQ4o2SFUDBeNs6uoXat i2vU06IgJZMxPt5YnRald1AI5bKj619/v84LvC/Z2z9u+ookiMmUGA7L9/utJv4CZaS6rqvV Yn24uez0Unm4cx+GNUUpVUrpmPgv0DuYjLV2f/xwewmGilTNkzNXS/lCGYxX7D+gCdXc2Mu5 tT+f5lVJqswOp81iPJpM+iVJrC8PRjHwLrIQ5s9Pz9dlJURgXEqzT4fVdDSejlpZQdY3dkf4 2SlMRSuTzfF0cs8Hs53w+8W6sTs6ezAuw5IQK40tPef7UG6YijcNs5sEu0zw8mB9PB52W9to p6NpdWE0YuTnN/UGqjqYr2x7eV9P+gkCuPpitbLmei0RDCYb3arIfJwxoNVUrZ7jCaCPVEju TK31ypx0lWggVlBbuSDuSbBnEIJz0XSx3mxUcjEfEEeMjWbKjWa9nBP8FBWUUoKf+OwAIQNx T9wgUEYGJaXWbNYKKcB5LppMhL34hwGFJdlAOBLmOeqmyyjJBT3XRwGhJBiOIX6e22ACaIYE gnlrhvGHgIoGWAJFgF6zoPoT01uHEcwT6I9fCfAUDCc8F0g6mDag7D+TgQ/+ZG4uqEI9XffW vfvf8t4LwJHzqxQcQ//2fkJ6N7+t/F/eP/t759kKZW5kc3RyZWFtCmVuZG9iago1NDYgMCBv YmoKMTQwOAplbmRvYmoKNTIzIDAgb2JqCjw8IC9MZW5ndGggNTI0IDAgUiAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDg1IC9IZWlnaHQgMjggL0NvbG9yU3BhY2UK L0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVy Q29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrVbZkqJYEC32 3QVXwB1xX1FULDcUUcoNRcvauh9mOmJi/v8H5mJVdU/HxLxVvkDmzTwk3JPncncHDIIRYDAM ec7XGIRgJMNxLE2gXwYLo6Q/mszKGSnM4cjXNAuhdCTbGIwnI62S8OPwV7w9hFCRgm7tnaPz MG0INPIVoDAWkIeb02m/2+9XvQyHfgkoFW+t3YOpa4PRqJ36GlCETQ8dd9nKSkm5kI16r/9B MG/LIPh3g0AQugUh7/LJw/cQSP2gJcLlJq47K4RZ1s8HGRy+EYxlGRKDQS5GkAROkDRNEQRJ eZyDYBQnSRxBUJxiOZbCEfg9BPIomsI9WiJsduQ+LmsxBgeGIe8Ey2QSUR+JIBgbiob5UDyR iIVC0SjPYjCM0cFo2EeRbEhMZ9MCz2AISgUikRAfERMCT6PwHUxL2u7JGZfiHOgDhlE6nK1r uq5V0zyF0dF8tawUG91uLS+XqkqcQVE6KlcUMchLxfZA77cVgcOJQKpUKSgVVWvJYRK5g/FQ yXCfnFkzHQIPQahosb9Y2/bK0GSeDmR7c+N+aKyssdocTPVimCSC+f6km09kWxPLttfLUU3k 2HhtPB/r4+XaaCdYFIJQRmyY7pO7HhTjLE7wytDe2aZpby0tHYyUF+7Jni+s5Vhtjex1P+3j JNWy7yvFzmK7sUxr8zCtxPhUf+vuTMNcGWqSQ6E7GOOk+uxwvR5mddHnS3YfTtuJps22jlkT hfrD6/PDsKOq9UJBs51FNR4pTPcbvdaeO8floKNbzlbPxXOj89vJ0NROS4nd5gfGuXhpYF+e 3UVdipeMy+O6V60N7POul000t2/XeTUlivGIUJ45m34+11k7S7Wmg42YNittw3EX1UR+fHnd abIkChHuNumAN3Qo0164L+60mle91vRWa2i7ez2fam5enH7SR1EUySW1jWN21dl+d1+pTi9v p1mn2Z0f3GUjrYzdR7McZkAa5mmSx2GU8IlV4/y805u68/11O+n3R8uHZSebbNqPdiNCeLwm QuX58WAtd0erJVfmz9/Ppt7TZ2t7XE4po+NxlGE9+njqCbhOEBiKMUJz/eTOe+Pjt6e1rrZU ra8qotRYn60Kj3nDhbCpwf7per06I0UqzZ+/ObNuq93ta7W0kB8d9oME/SlxMMYEeT9NkEFl dr4s+/f7l7PRzGezOTkjhOKN9cksB28qAxOR2urlzx9vm7YUkSeX502/lMvk5FwyEpHvD9ue RH2CIlQ4o2SFUDBeNs6uoXati2vU06IgJZMxPt5YnRald1AI5bKj619/v84LvC/Z2z9u+ook iMmUGA7L9/utJv4CZaS6rqvVYn24uez0Unm4cx+GNUUpVUrpmPgv0DuYjLV2f/xwewmGilTN kzNXS/lCGYxX7D+gCdXc2Mu5tT+f5lVJqswOp81iPJpM+iVJrC8PRjHwLrIQ5s9Pz9dlJURg XEqzT4fVdDSejlpZQdY3dkf42SlMRSuTzfF0cs8Hs53w+8W6sTs6ezAuw5IQK40tPef7UG6Y ijcNs5sEu0zw8mB9PB52W9top6NpdWE0YuTnN/UGqjqYr2x7eV9P+gkCuPpitbLmei0RDCYb 3arIfJwxoNVUrZ7jCaCPVEjuTK31ypx0lWggVlBbuSDuSbBnEIJz0XSx3mxUcjEfEEeMjWbK jWa9nBP8FBWUUoKf+OwAIQNxT9wgUEYGJaXWbNYKKcB5LppMhL34hwGFJdlAOBLmOeqmyyjJ BT3XRwGhJBiOIX6e22ACaIYEgnlrhvGHgIoGWAJFgF6zoPoT01uHEcwT6I9fCfAUDCc8F0g6 mDag7D+TgQ/+ZG4uqEI9XffWvfvf8t4LwJHzqxQcQ//2fkJ6N7+t/F/eP/t759kKZW5kc3Ry ZWFtCmVuZG9iago1MjQgMCBvYmoKMTQwOAplbmRvYmoKNTI1IDAgb2JqCjw8IC9MZW5ndGgg NTI2IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU5IC9IZWln aHQgMzQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRlcnBv bGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBlVX5k6JWEB65RMULZMYbcFDxFi/UERRvUA518JidmWSTVKXy//8DeWjtblLZ 1M72D/CK19/r7vd1f9x5IAi+GgR5PHc/Yx4IxQMEsIAfR2HoZ8AQStBpluM4Jh0nCS/8E1jY 9yB0R4o8GkqikCF9yMexSIgbGs7zzjINfdrlKfzjcdFoafnp14u93drPh00/F8Ggj14VSlb1 9zdD6fUU3TnprYQP/ji0tnl1FCGdzvc252clF0SuZH25a8DdjTyXuhuRgMXr6ShZ21ysTjLo p/KT43khkDgeCAYDgCng4IEQr89/pc6LQBCC+Ygg4cNuJAKofjFbcZ83zMnOy7oapx6yXC77 EMZh4IuHYokMw7LZeNSPeQkqyXBMggyg7oW4UV92EkNGEpX56bysc3xNGsn9OkviCBqg2Uq7 /zR66lWzJBFJFcX+QBLziaCLdaFv53mzUGgo1nmn1CodVTdta9nLRfHAg9CfacbeOejDYoJm mspS09aLUTVJAP4BdPv5N2c1UVeWs5+1SvWnhbaxHGctpsKxwpNmGpbz+rqThTQrzrab5Xy5 0cdlGodcqPHHX5+Ptr3bG2ojxwitXrenGKeDzN9nWmtLG8sr58Xq80xFtXeLfnuwtLcDNohc ob//+b7X10tVKqUoKsXl2Mf6zDnNy6nHoWEotVJPe9bbXK5rnO1xoyyq9mFWiqIeN+Ff3k25 Xa/kMzEC94dj9wmmNjteVtU0PzQ2w+KjuNitmlxBdl73k3ajM7UOi2oMg9xrAi1RTMbIcMCL IBhBpXIVaX0GPKXYztpQO80n3Z5VGUG9vD/PB73BZK3JReoGdVsigKEIIBLGSabSlmT9dAEU J8qqZWpL3doM+FRxenmzJ52m2JG61UzomrB+MZo0dm0uCAuzLVmWJHV3XFVokhuYp+Pe1Eal OM0rzmUjCTk295jLUH7ErfUGvbYlhD/Up9qkVRsYjla7j2a629PRmPaEeDCU6ZnHjZRPJZKZ bNId7H9D4UBGMnazVm1ono1OhmYlw7HUVj4e8vro6nxvT1sCXyiV83HQEyhZWTt6PYZeo8L+ dM941p56k/2ng1zMFpX92Ro3HxMRnzeU7Wp7azUeyeNRk3FrjRTG22mJvEHdhOfWdqbMrONO bQji8vx+1OR2mYkRfuqxv97tLGOrqWI2iHgQItMciEwIudWKhhlRUUdSX5lNh6I4Ml7eTrvN Su0V7olA7LE9Xq5Xc6WTp4EiQN5omsuQ+E0bPLA3ksqXBD7HC+Vyvb+y9+Z6sdqa2pCP4r5o Kl9tNKqFbMwdO+BMhAj8ixB6YCwQochIOELSqbJiWot+o95RzcO6GfchWCBM0TQVIcDc34QA Ac1wzRc8PBCMYiiKIChOFie2IVdYpijpjtFN+WEIRjBgwP0mMV9AX9+e6w/Eg4RyI8MYN/J8 dagfXMFzzweb/wP7ir+7g/3J5nyzBK01Wmy3Y4Hyfk3tH17fXUJYhGuP58CWq4VcuwrDdx3/ +9EDRiFbvipTXywkgh/XdlAW7A3SaY7P82zSFcEf1/gtvqvCgVA4Eg76sSsb37Z+vAJUIcDA IH8n5N8Xe9XcCmVuZHN0cmVhbQplbmRvYmoKNTI2IDAgb2JqCjExOTAKZW5kb2JqCjUzNSAw IG9iago8PCAvTGVuZ3RoIDUzNiAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9XaWR0aCA4NSAvSGVpZ2h0IDI4IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNvZGUg WyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIK L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1W2ZKiWBAt9t0FV8AdcV9RVCw3FFHKDUXL2rof ZjpiYv7/B+ZiVXVPx8S8Vb5A5s08JNyT53J3BwyCEWAwDHnO1xiEYCTDcSxNoF8GC6OkP5rM yhkpzOHI1zQLoXQk2xiMJyOtkvDj8Fe8PYRQkYJu7Z2j8zBtCDTyFaAwFpCHm9Npv9vvV70M h34JKBVvrd2DqWuD0aid+hpQhE0PHXfZykpJuZCNeq//QTBvyyD4d4NAELoFIe/yycP3EEj9 oCXC5SauOyuEWdbPBxkcvhGMZRkSg0EuRpAETpA0TREESXmcg2AUJ0kcQVCcYjmWwhH4PQTy KJrCPVoibHbkPi5rMQYHhiHvBMtkElEfiSAYG4qG+VA8kYiFQtEoz2IwjNHBaNhHkWxITGfT As9gCEoFIpEQHxETAk+j8B1MS9ruyRmX4hzoA4ZROpyta7quVdM8hdHRfLWsFBvdbi0vl6pK nEFROipXFDHIS8X2QO+3FYHDiUCqVCkoFVVryWESuYPxUMlwn5xZMx0CD0GoaLG/WNv2ytBk ng5ke3PjfmisrLHaHEz1Ypgkgvn+pJtPZFsTy7bXy1FN5Nh4bTwf6+Pl2mgnWBSCUEZsmO6T ux4U4yxO8MrQ3tmmaW8tLR2MlBfuyZ4vrOVYbY3sdT/t4yTVsu8rxc5iu7FMa/MwrcT4VH/r 7kzDXBlqkkOhOxjjpPrscL0eZnXR50t2H07biabNto5ZE4X6w+vzw7CjqvVCQbOdRTUeKUz3 G73WnjvH5aCjW85Wz8Vzo/PbydDUTkuJ3eYHxrl4aWBfnt1FXYqXjMvjuletDezzrpdNNLdv 13k1JYrxiFCeOZt+PtdZO0u1poONmDYrbcNxF9VEfnx53WmyJAoR7jbpgDd0KNNeuC/utJpX vdb0Vmtou3s9n2puXpx+0kdRFMkltY1jdtXZfndfqU4vb6dZp9mdH9xlI62M3UezHGZAGuZp ksdhlPCJVeP8vNObuvP9dTvp90fLh2Unm2zaj3YjQni8JkLl+fFgLXdHqyVX5s/fz6be02dr e1xOKaPjcZRhPfp46gm4ThAYijFCc/3kznvj47enta62VK2vKqLUWJ+tCo95w4WwqcH+6Xq9 OiNFKs2fvzmzbqvd7Wu1tJAfHfaDBP0pcTDGBHk/TZBBZXa+LPv3+5ez0cxnszk5I4TijfXJ LAdvKgMTkdrq5c8fb5u2FJEnl+dNv5TL5ORcMhKR7w/bnkR9giJUOKNkhVAwXjbOrqF2rYtr 1NOiICWTMT7eWJ0WpXdQCOWyo+tff7/OC7wv2ds/bvqKJIjJlBgOy/f7rSb+AmWkuq6r1WJ9 uLns9FJ5uHMfhjVFKVVK6Zj4L9A7mIy1dn/8cHsJhopUzZMzV0v5QhmMV+w/oAnV3NjLubU/ n+ZVSarMDqfNYjyaTPolSawvD0Yx8C6yEObPT8/XZSVEYFxKs0+H1XQ0no5aWUHWN3ZH+Nkp TEUrk83xdHLPB7Od8PvFurE7OnswLsOSECuNLT3n+1BumIo3DbObBLtM8PJgfTwedlvbaKej aXVhNGLk5zf1Bqo6mK9se3lfT/oJArj6YrWy5notEQwmG92qyHycMaDVVK2e4wmgj1RI7kyt 9cqcdJVoIFZQW7kg7kmwZxCCc9F0sd5sVHIxHxBHjI1myo1mvZwT/BQVlFKCn/jsACEDcU/c IFBGBiWl1mzWCinAeS6aTIS9+IcBhSXZQDgS5jnqpssoyQU910cBoSQYjiF+nttgAmiGBIJ5 a4bxh4CKBlgCRYBes6D6E9NbhxHME+iPXwnwFAwnPBdIOpg2oOw/k4EP/mRuLqhCPV331r37 3/LeC8CR86sUHEP/9n5Ceje/rfxf3j/7e+fZCmVuZHN0cmVhbQplbmRvYmoKNTM2IDAgb2Jq CjE0MDgKZW5kb2JqCjU0OSAwIG9iago8PCAvTGVuZ3RoIDU1MCAwIFIgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMSAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCi9E ZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNv bXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4ATWSe3OaUBDF5QIC ilQQH9HER4NJTBRNnAKNVh0yPgKBXpALaIO2k077/b9BQez58zdn9+7ZvZkMBgCeCAAMy5yF 4Vkmz7JsPkdnCZBiDKe46lW73W5d1gSWwkHixcjCZV+dTifP6mOvKTBE4gWU2FtAtIW2Zb4o ksjgMQV07cmKDv53C3qe+fW6mI0bAKauuIfwdaLNDBQYT3UGP0HV2dtqt9VVzND71imcIQzW /Qon3iyQr3c/EakT+qv7Up6XZltvIXH/4c58vKo2h0vX0pr5c7kbIX08UpeOt5KrdPq66n38 QqYBd+9I74lnqKE/f49BsD8eg+WwwRIgmVP1fn+Etmk5CNmz+2qcKYHuIVgqo5EyN11r2uWz IIHO7m3cqpQbtxPbN8d15gRPczIUW5M3oTdts3jihP6yJ1AkU+5v9v78cyGFoTFqCMVyR7F/ eJNW6nQjbzG8ux2oGz/OdpH0vPji/Izcta6v3rbIer4ukgDQ1ZGxj3ZbB0Jor7WbZPdYlpe0 lWm+rlcvc03uiLn4ShiRK3d6A1kePNxJzQpHxynjhZIMx5dEsSTwXJ4m08tjACfIkwgCP3+G f7o3UqQKZW5kc3RyZWFtCmVuZG9iago1NTAgMCBvYmoKNDUwCmVuZG9iago1MjEgMCBvYmoK PDwgL0xlbmd0aCA1MjIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjcgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAx IF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAFlkm1T2kAUhdndvJKYopGKDdBgLVYbiako0BakEE0Acdgk NMTpCAgzOI7//3MXMSHqfkl2k3P3POfeRCJcAJIFQLiNPQGiOZ6l4PtvALFSekcWaBj7ffUK aSl3pBczAvVOhpIZvd2pH8jsWxmgU/tN/w5XcwJ6I4NcxriZP46vDreY1zJASYW6//A0x2dK Er0yAtn0sXV7P5v6f4opOl4RIDFfvfGHjj/q/djl4xUhs3XYdgfmhe3hxpcPcRlKKuVr9+pU q/WHtv6RW8uI869NFzcO1OPLIf6lbqyxl86vA/y7qH5v/Q1sbTvCBtTGXsOfjsyyXun8m3o/ 8xH20nlvspg49mV3OHu4syJsgIR8zZsvJiMXu8H9YobPQ2zi/JsZjINB17KsHr4dr7FR8lO5 7+NWuaRpWum87fgh9tL5heM0j5RtWZbTWa3l4PoKG3I7Jx2vY+wKDE3TjKicdr0XbCR+rvYH jf1VPM81Bv1KXkQJ0o69mm2ehKGSmw3TqhUkChDenF4x1DBTyKQKRqWUI2EBxMtZVdnkXhoI ELepqFmZJ3MAKV6UBDaaCDJ1giRyFEkfQERRKDaZ0cF/DstErgplbmRzdHJlYW0KZW5kb2Jq CjUyMiAwIG9iago0NTEKZW5kb2JqCjU0NyAwIG9iago8PCAvTGVuZ3RoIDU0OCAwIFIgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMDggL0hlaWdodCAyOCAvQ29s b3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVycG9sYXRlIHRydWUg L0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1 Vll7qsgWjcooIIpoBMQZcR5QnDXiCCooTokxOSd9T5/+bt///wNuYU7S3ffhvmU/7dq1ay+K 2qtW3blcbo9jbrfbdfe15nJDqJcgSYLAUdjztWhumAjysUQiLvIhGoe/dG8enM0ovcGg12lW MhEK+UowDxlTjcPR3lobfViOUrD7684MojPa4/fnvWXtT/aswnk9X4jllxfX153W7U13T4cH yQ9/XX9Agdzicp6UEsmSdrisqiEUNP+HuRxc120EvE/n3fucA6y50ebXUb9zyBk4EzcDhHKy Adb80e7E/bTQMC9WI4J5YBRDERTzejEYJHkQDPc6fHADdmAg5LoDMdQhCOALgmEIBCE4SVGE M+dyeWDMoRAGAxRnGpQC6xEIoN2wdu0oRXL11Xmj3OMIGQyzTDASFcI+DEZJ5l6I8iG/F0GI QJj1oR43hPvZIOU43kCIpb2EPxJPJaOhWwijw2IiEQVrIZAXCgWZEB/lGC/kdrAWT4ehFOGk nnWYFYKYN5wp5iW50mwUogEfK+ZqzVajkuH9VDCel0UagTA2WchFfTCEh1L5rMDep6qdfq+Z F3wo7GWTZbXbVYtxxosHYrlCViooai3NYp4b1vW67taU4ea07ad8mC/Zmmj9nrZc9PJiVFbH C8PQ58NaMhIt9gYVnkDpZHs2Bi2L+tOtoZqNZdtL01zNOnKYIMJye6obxlJT0yzNlYeTYXc4 17V6lIRcYF/Lb79ftyvz9PJstmIUFshPD3tjMl0shtVcZaCba11fWeZczaZrE2MkB6lIbfV8 GksBiq/PjX5eauino7nQugWOZqWeYRqzmbFZqMlIor05mDNtttQUkbph6W///vF8fnp9e9n2 pSDJllbXy6rXUBq1cn20tpaDptKZmLuFmq9qlt4Qw+nh0x8/rHo0LA2tVVuSutvLftquFRMh Rmyu9puRqo43u1k1kR0eX/aaCipJ94C4zr6+/3y11+vt4XxYqgk2Utm8PE6KMV6Iy21jp7ck gYuXx9vtuFrqra2HQrqqf/vzj8dRLq0sd7OymFCtiz2uZqIhms1qp7PeKpY6xtHsyPmH09VU 0wLPhcDtd8N6eTEH9arSm2/3SyUera6fd23Rh5OsNNhuhxLjxSi+ttzrzVx9tjN6zdHu5be3 i9Fpji2zlwreF2eHo97JCQEqXDbAP+nWaj3jYA0KxYfDeZZnCRy/ccXpw8vxQeZC94na/HTU Csm6cTYqgNOwXxrb6yaPe27ubtOW5J5prxab49EGN5qxtPbLaoTwiY2lbeu9fIThFevbdTNq twfz1VyVCyPbHiRIyCE0IDPAmj8CfpEo5k/2D88rJavox0WBge8gOqvZq/o9CnZPpYY7s52M VZfny+VyMkaa+Qgce5ihETSQVKbWfjPMC7Hm9vVJ7yo1RW0rciI33FqdqPfjOr9hbVsCASNU vHd8MZuyou9n+QB05/GlH2yzJZIwhDI5DWwxGs4MT//6+Wb3S7Xp04+f38wG74UQMpSoPlgn qy+nG+vno1bNJJOpdELgwBlsWgL+NyzA5UEm5Gf4wvTxuqpLAGuac7CIWMe0tSJHU0xCXe0X 5TDNKdsf/3kzKrFke//zz5epHAD0DYSFdH1+elzWMpXZ6aCV4zwniCIXkQbWRuX/gXV9NloF OV9/2IGTyydrv7DcWLg8s81RRUrl1LltDdI0HsjOXn5/GqWC4aL+/cexIxIwxsQkuaBMT89r JSl1zcOqV5KkXCGXFOXhP7H88vz69rieaVN9dzrMq6JQnm812Q/duSBfvKXvzPlooBnb7aQc wWGv0LIeVzXQEPGefV4UWQQiuGJnMBhvzud5iecL4+1+PR0ORqN2ISn310aD+2tfvtTo+Ho9 7Xe73XY9rooMKw8X3ZQPurtzY0ymvbAsy7SstVZ1RBth5P60k6YRLFQcTZoxCvJ4ufJouTbt /aqdCNB8WTPtnbVZgxsulm5Otco99nFeHoKvjI31Sl/OtEFT5n24T6w0izwB9NnlwYPJWh/c VvNxuyD4wGPEQ3ByWQrjHoiK5kupIFA7NJhujGaLhaZmgjhKCcXudLlcTLqlWIiTlVoqgDja 5ZgbpYVsqVIplwrZJM8QMIQFhBhHg0Z3wDCaS+XLlVI2FiKdd48boUIcSwJxQulwBCiFywV5 2ZhcrpZlkcEhD0yGE/lKtZxPcX7CFxajLMi5ITnlUNLPsGwwyPgpHHHEESUoAn1/KgLlw30M Gwr6SdRRO5CO4I4OAk1EcC8GROnODWFkgA2zARIoGpBPjAqwIZbxAX1EvCQJ3oG/oMBqtwd+ N+hdqkEAeL++Bag4BCMIAmT5PXJT+Buqo/u3IKgPI+hHyscIXBZOpb9KfSL+PwcI+8dfcNI+ R5/OLfa3nP9Z8Fn7v3fKQ+AKZW5kc3RyZWFtCmVuZG9iago1NDggMCBvYmoKMTgwMgplbmRv YmoKNTMzIDAgb2JqCjw8IC9MZW5ndGggNTM0IDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL1dpZHRoIDI3IC9IZWlnaHQgMjcgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkg L0RlY29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDgg L0ZpbHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBZZJtU9pAFIXZ3bySmKKRig3QYC1W G4mpKNAWpBBNAHHYJDTE6QgIMziO//9zFzEh6n5JdpNz9zzn3kQiXACSBUC4jT0BojmepeD7 bwCxUnpHFmgY+331Cmkpd6QXMwL1ToaSGb3dqR/I7FsZoFP7Tf8OV3MCeiODXMa4mT+Orw63 mNcyQEmFuv/wNMdnShK9MgLZ9LF1ez+b+n+KKTpeESAxX73xh44/6v3Y5eMVIbN12HYH5oXt 4caXD3EZSirla/fqVKv1h7b+kVvLiPOvTRc3DtTjyyH+pW6ssZfOrwP8u6h+b/0NbG07wgbU xl7Dn47Msl7p/Jt6P/MR9tJ5b7KYOPZldzh7uLMibICEfM2bLyYjF7vB/WKGz0Ns4vybGYyD QdeyrB6+Ha+xUfJTue/jVrmkaVrpvO34IfbS+YXjNI+UbVmW01mt5eD6ChtyOycdr2PsCgxN 04yonHa9F2wkfq72B439VTzPNQb9Sl5ECdKOvZptnoShkpsN06oVJAoQ3pxeMdQwU8ikCkal lCNhAcTLWVXZ5F4aCBC3qahZmSdzAClelAQ2mggydYIkchRJH0BEUSg2mdHBfw7LRK4KZW5k c3RyZWFtCmVuZG9iago1MzQgMCBvYmoKNDUxCmVuZG9iago1NTMgMCBvYmoKPDwgL0xlbmd0 aCA1NTQgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTkgL0hl aWdodCAzNCAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAxIF0gL0ludGVy cG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0ZURlY29kZSA+ PgpzdHJlYW0KeAGVVfmTolYQHrlExQtkxhtwUPEWL9QRFG9QDnXwmJ2ZZJNUpfL//wN5aO1u UtnUzvYP8IrX3+vu93V/3HkgCL4aBHk8dz9jHgjFAwSwgB9HYehnwBBK0GmW4zgmHScJL/wT WNj3IHRHijwaSqKQIX3Ix7FIiBsazvPOMg192uUp/ONx0Whp+enXi73d2s+HTT8XwaCPXhVK VvX3N0Pp9RTdOemthA/+OLS2eXUUIZ3O9zbnZyUXRK5kfblrwN2NPJe6G5GAxevpKFnbXKxO Muin8pPjeSGQOB4IBgOAKeDggRCvz3+lzotAEIL5iCDhw24kAqh+MVtxnzfMyc7LuhqnHrJc LvsQxmHgi4diiQzDstl41I95CSrJcEyCDKDuhbhRX3YSQ0YSlfnpvKxzfE0ayf06S+IIGqDZ Srv/NHrqVbMkEUkVxf5AEvOJoIt1oW/nebNQaCjWeafUKh1VN21r2ctF8cCD0J9pxt456MNi gmaaylLT1otRNUkA/gF0+/k3ZzVRV5azn7VK9aeFtrEcZy2mwrHCk2YalvP6upOFNCvOtpvl fLnRx2Uah1yo8cdfn4+2vdsbaiPHCK1et6cYp4PM32daa0sbyyvnxerzTEW1d4t+e7C0twM2 iFyhv//5vtfXS1UqpSgqxeXYx/rMOc3LqcehYSi1Uk971ttcrmuc7XGjLKr2YVaKoh434V/e Tbldr+QzMQL3h2P3CaY2O15W1TQ/NDbD4qO42K2aXEF2XveTdqMztQ6LagyD3GsCLVFMxshw wIsgGEGlchVpfQY8pdjO2lA7zSfdnlUZQb28P88HvcFkrclF6gZ1WyKAoQggEsZJptKWZP10 ARQnyqplakvd2gz4VHF6ebMnnabYkbrVTOiasH4xmjR2bS4IC7MtWZYkdXdcVWiSG5in497U RqU4zSvOZSMJOTb3mMtQfsSt9Qa9tiWEP9Sn2qRVGxiOVruPZrrb09GY9oR4MJTpmceNlE8l kpls0h3sf0PhQEYydrNWbWiejU6GZiXDsdRWPh7y+ujqfG9PWwJfKJXzcdATKFlZO3o9hl6j wv50z3jWnnqT/aeDXMwWlf3ZGjcfExGfN5TtantrNR7J41GTcWuNFMbbaYm8Qd2E59Z2psys 405tCOLy/H7U5HaZiRF+6rG/3u0sY6upYjaIeBAi0xyITAi51YqGGVFRR1JfmU2HojgyXt5O u81K7RXuiUDssT1erldzpZOngSJA3miay5D4TRs8sDeSypcEPscL5XK9v7L35nqx2prakI/i vmgqX200qoVszB074EyECPyLEHpgLBChyEg4QtKpsmJai36j3lHNw7oZ9yFYIEzRNBUhwNzf hAABzXDNFzw8EIxiKIogKE4WJ7YhV1imKOmO0U35YQhGMGDA/SYxX0Bf357rD8SDhHIjwxg3 8nx1qB9cwXPPB5v/A/uKv7uD/cnmfLMErTVabLdjgfJ+Te0fXt9dQliEa4/nwJarhVy7CsN3 Hf/70QNGIVu+KlNfLCSCH9d2UBbsDdJpjs/zbNIVwR/X+C2+q8KBUDgSDvqxKxvftn68AlQh wMAgfyfk3xd71dwKZW5kc3RyZWFtCmVuZG9iago1NTQgMCBvYmoKMTE5MAplbmRvYmoKNTMx IDAgb2JqCjw8IC9MZW5ndGggNTMyIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL1dpZHRoIDExNyAvSGVpZ2h0IDM0IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9EZWNv ZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0 ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1XWXvayBI12oWEQBJi30FmEyBWgcGAZSMW GRCbwU5sz0wyN9/9/3/gdgs74MzD5H5JP5juruM6dHWd6uLiwh4O5DhQOBDE4QC79h6cnA2w Z0PeYGeW/3/qQHGSJHCCZliWZZwUgQFeew9Fzr050CMEoFiGJj4az4E/MXegpIv3uFiPP5pI JOKRgMCSKIo7PYKbxs7OCnCcDQGoRNTvodAz40/wfIAghDsYj/ikqKL1et0rrZqPCTROeSLJ qECfOXbgrgiAXPe63e5VsxDh8A9x+ODz3xYI7gpli5lQpDi0dhtrMTdvWxmv0ymmy6WEQJ4c I6Q3f4QsFvejtnxu+zeSH+wO1OnP1auZUKw+f355WM6t7dbspHlGSNU7ldjZcRAqUIOQhTmd TvRmij/7Qj84/cfSAfPydBsIKWQaV2pMirXWL4dpt92f7fazWoh1RdR+VwnQ6LsHhA5ByOSq UatVlYyf/fnwOhCMgOn55sqBsdHqoFvweyLa6mmhyXG5ZR6210mO9uZ6t52M57trQGpD0qFA wC/xLImhtrrsU4DZUVD2gY5bUGDHJUqyHjdDHlcXF/Ci+qNOysOGNWs/Vnyc93K4e9BlN+mK a+M7Nfj9qJAUQIoSQ4JBECRFkVBc4BQURaAoRtCsi4VSAlvASFFOBigLA9wUH0kngzwD8eC0 KBNrTYx6mHECjw9GQWT4TH+zHWY4nAqohtlLu99lY5M+GHmRwsDAKc7rE0CIEdzJ+7wcTbFi KJ6MBwUGB3rj/QGfPxSLhUSGwGgxXe9dqXJEZGDcHDifu1mMShIFSR/NatQfq4zW83aMQXEh ry+NsvSeLzbpYaaGeY7jXKw7mCnIAQbDnL50QQ7xQjhbbXe0qhx0kbSYKqnlUrWp1bJBzskn 2+ZuPempKZECpCAjq7OVnvUQIHbr551eV7XRamuU/RSCulLX1lyLMm+pBEnXz9thJSvL6UQ4 lK73O1kvRfIZrd/IRJJq3wBpPeopIc4drd1NRzc3o+m4r4TFYGn8+e8/97PrYsAJnIHoXlnr fsqFAY/bL3/uzJn1+Hmn570UgjijHWszTHPYMekg6fbLH5uxPhz2NSWda08mWpxzhWvGtFvI 1m/vTePOMGeDQkACV3RYjQbDyXLez4djqvn67XU90rI+mCEYJ+u79VWMAaTt3X++ve73T6+v +1ElzGIoFWwu9+MCj38nhZCX3cqy5qNWVm5MrNtiQLocLMyOUtWt1ahd7xjWfScdzt0+frrv lEqd6XrWTEaKd4+vmxs1E+QIEF6Mz48PKy1Mo/AYX78cFuZ8tdst+gU/jZG+2uLpvuIljvqC J939/fVxMZ1MRn01ESkMLVPLpOoTa1RTOvODNagUqjfW5lZJFO72u5tcMJDtW1YvHUhdrR6M SoRnCFhWcaE0e7KaAQqSrl/2o5aqtgbmet6TeYL0VuafljUfeSLdvB4MTS2XlWzMK8SapnXX qA0X826hONh9Xg/rlYa+3IwqKeV2u2hFWCbcuF8NZF+0CT94IFToChfL95+sup+EpKvH+3rc J4Wz3cWDWQ/RpG1sBKgTKYA0En6vV+RdNO3N66ulMZqvDDVd0B9ftnedVmc4mV4Xksrtxqz6 SNKnzlY3l1K4Nltep1xvGWmTLus+m9TWKU2ygfLksO0lWOqfpEcIDgaGYmysvTjs93urJ4dz +uOzNWyo1YbWVEDkb9czVSIJb3m60i99gNQ6IxVK5tOyHngjHeUFEqclZfL0MEi5KDu8IAzH l8bW6QOEwOKAIigpKeOnL18/m9WwlO7vHk0tl0qk0qmoL5D/TjoBggSkJgivGz/WQYwvjA9W M2jfqQWVL3ikZGvxaduNs7Svuniaq+eJdIS43ZyLoXDcleztv/33k34pcNEWuBJNDgdD0VhI 8p+RrvWsFKqam5ES4JwUDm4VcwPJWO2I004kqPxctqRNHkBtCjrpQGN5mBSFk2Ts4qDmZFlO Rb0MQfvV+V9fN60IQ0vFu7Wl13KZy3xBDofy+nt4J4DU6y9PHxbdPKiRTlBUUTbRtVbg/jA6 2Fz98bwe67pxv9nNr9Iekom0re2NfCoOEPICIMPhoFtLixThzgy2+1FBJHFXrDldL8eD3vUA VLtIfrgclyUCFxVjOZAFMatvH8xBS4l7wF0hdLBuWkMQbsqvzp6eHzdA+dZi3L700jgsg8sO qMJvxYHyVaaPzwcIWc76oKRhdKByc9eIshh4ldPtyWq1nN9Pb6qJYKZjDPICgfPZvtFOurlo Y7rZzO80WQSkDlwo3C7uiiJJ8Jm2YZrTsXE7aJeTXidG8Dl9Oa743gu+g+DT2mg2m4zHY0PX shKF4u6YUkqBvsWBwpdkYEzGd/2G7BfCxWYlzmGYK1puFIIMxacaN2OjX014QElyoK5Ee2pU gzTulJL5UrlcKuYyMR9HYSjpK4/urzNu/CjTCwfm9CbySgkOpZAOuAjwUHoCx3tygDczLCuV inIZ87JO0OqFBQqFmzFQ+zDwoGZLpXwcnAV4Qyh/6WbcTnI4TnO8CGQv8BzITPDyMtHm6FYN fX/ELxAMQo5DcMOSBmTjZCgMSgo0xYxblCTRA1oKjHS6WLDvwEjG5QTPOmgdeK8kcrT9ijtw LtnSr/Ne0OpiUPRA9rANuUAIQb7S2xn+e7sCmv53CETZJc1u+Y8yhlYCDLuJAXPQqgAvcAI+ gRF/s8EEQSgpf3WtRtj3BuGYNQ6UCZa6V0X/6aBHw49/QW902gKLs9VpH87ObaAzi5S0evqH LhbBPYmqVo6etaAfffzaCiE8caWckWAjcRpAA6mS8qHZPhl/fQbyToimYgIFQn8aCMmDnxXi +c+Kk/E3zACrWxRY+KafBoIzvPjxB9TJ+DtmCGo3rucHBQrAYTP74Yv8Dq6TD9ibfwguMMEf Hz/unf7jV2b/A18jdQgKZW5kc3RyZWFtCmVuZG9iago1MzIgMCBvYmoKMjIwMgplbmRvYmoK NTM5IDAgb2JqCjw8IC9MZW5ndGggNTQwIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL1dpZHRoIDk1IC9IZWlnaHQgMzQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0Rl Y29kZSBbIDAgMSBdIC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0Zp bHRlcgovRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBjZZnd+JKEoZHWaCEJEROIomck4mWAIHA BIGxPfbdnZ0Pe/b//4MtCdtzPWfWa33QoVVdT3dXvXTVt2/ug6DwINffn7+Rj1Pd4Zvj1eai 3j5d6RhBUQT24dufV0FQnKJ/TUVQAob4dWdgI2mKJEjq7cuVgWAUJ/oYAv0z8u9fUdwrKjJL vk5FSVYOSK+eV5vACZL4PsHxRUkhnIxJ9Be2j9KyWswGvZi7JoIzoXwlH2Jw5+AoJaUKuagS TqZC3K+9ogQX0coZv+fq4zr+rxfGxJrjblrAr3hCyAyMYV5yT4Mx0ca4r8WSxboWZt0VYRaC eYOFdjMjUZ8F5zWHGJcZb/SSRLzixYJ+WDWCtOOKcerQmtfiiUq/qyn062bhTNnOsBHn3tZz PX97OWkjIYU4n9ePq6r/FY8L2eneaoVdPM5nZ4d1IxrKD2ZdVbiGB8HZeHM2KgVoUBQGjyuD d/25OgQDxfoEhsIIQTNO65pCwTwUQTAm0VnolQDluJJiXretRkiMtw29Hr7mB6X8xenyJi0Q GEEzHMfQoNB3/SEgWRAi7hFjGTUsMl6pYJysZoRnGC/ID/MEi92m6qMIysv6wtXledMIcEpZ X4+yPsLJN2ygtzbbUYaghWBCTSeCAo29689RniKyrD/THg8buVggXJqfd4NcIp6IyAyBU1Ii l1JYD6/EUtnKaP941wh4hcz4zmyEnIghBGRnv6wqHo+cqvbHk0EtJdHEm/4g7dliOhRID7aX 03rcyKnV5cN50W91ey0tzJGUszrHyslydzgxds//2DcVmon1truRyoG8UDrU3NiGJnqEVEvf 7I8Hs5f20ZCPcQ/0hwvp3riVVeurv/7983EzqeXr5veX40Kfr1fTapghKY/Xw/iz3bm12eyf fv48NBWKCjSs06IoQXQgNsPjaZrmvX5tuLS2h8tl3YywcL6NAfojpJKxmZRz7e2P//w4Lful bM18+ed5OZmtj/uZJlE4jlO+dH99uDPn5unHvxw8KZXN+20zBErH+ZxxOQ0TrNefbfW6venu 8TxJ+0AEjv5I0l9dHfWKWll8/3HWG9lYrGw+v9wNKpWbzXnbjngwBPOEmyt7N2tWmvr9yw7w uJCfX+xB3At4sbh6svtRLy1E1HQqU5tfHheaLOUd/Tn4mmUbxWhmaD+Y9ZjI+4uLx/uZFgpp M/s4SrEYbDAzOR5vSxEl3rQu2wbg+czt5X6qgpGQqpvnYzfkITyCPxBOVucP31clv/x3vK4F 4907e5YTKdKnze933QjDRru70yzDOYTS8rRpR1iPVJifNoDHWHV6edCzPP6NkGt3L8d2kMJA gtF0ub9+el6XFcDb77vX80q0tTlM0hwG5wbd1930bU56jscRiN/6tIQ8QZydv5WDT03uH+d5 uJlc/KEdoDBaSpbb/cnm8TvgJecPWFdIUqlb9hV/fMfDugTpB4MBBMDX1va84PszXqpunw/t EE2CMCeTfl+3H1aAz93am2aQpoOt7QnwkdYWgiMQEBw3KQThQB08BKe8tM2KQpM+91J4C44B R4PUllZPx27Y4wnWDOu2Vb3ZXaxqUM5M7f0g6RNTN8d7I6+Em9vzshLiOaU0d3Lu4k8uHhdy s8O2r0p8sOxcCpBa7j21YDQux0GMZeP9nT1vVYf7p10nrqRu9va8pqr15RNE0R+sWQ/7UTEZ SzXM3/BQAjrWftHOq9pg9+gqB4T5YN84woQ0jI72OMWzsd7u3hr1bk8v53EuFKub9k7v924P L6ABSdaM+4ftrFevdM2jWZEJQq6Yh5lzfpSUtfHmbjm5mVgPz1tIOymVzMsdBBz9hnrC7e3x NudjgrXF4W4+nR8e7NtiOJDprfbbpbG8O++GKYGPd6zzebe4abZnq6kmEoSoTc2BCsJEcG+o NDIta709PV0WJYmkAnXrvCzLcCkgINv5flH2e4Vkc6qP+4Pp3Ohl/bySaU+N2WgwnNyUQwwt pjv6ypy2i4V6twalB+fitU7JvdRRgg3mWsOZsVit550UT3qj3e1+nHauNATjUgPLbEYYjy+a Kxay6WyhkA5ytFeK50rFnKpmUmGexGkxplWrxVQ4FEtGRSg9tBhNgMGpgijhlSJprVSpVgpJ 2UPy6dHWbIY9ro0OVvXVQOVJivHJkk/wSZLAkBjuDGUfz/Gcl8ScciX6FVlgvCzHUDiCgN0x uL0RipFeXpRkvyxyNEHJxdlqlLuWE4Tg1Z4xKfopDCdIgsBxgiCgIiIoBj8IHMNxpz46QxLK LVRLGMO+oPy5Brcog9X1c+dDw3A7eyuGcOMrxeGkEYPWAR6YfX07bu7Q9b+OPo7fDR9+oKSY 6U46b6UcMs/Gqv32/2lEPiA+G0B9K3Y7eWhE3LjBMUlfslLLKm438ZnnV2yw2UihpoWvjZvj gcBtFk8nJPprPfLni0BfGEipIf5XE+jwBVn60HZ+zvjECiz+dxYIi6ZfRfaJ65dMbhf+WzMP vdi1O/sS4dNJLuotzP8FzRAwsgplbmRzdHJlYW0KZW5kb2JqCjU0MCAwIG9iagoxODgxCmVu ZG9iago1NTEgMCBvYmoKPDwgL0xlbmd0aCA1NTIgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvV2lkdGggMjAxIC9IZWlnaHQgMTYwIC9Db2xvclNwYWNlCi9EZXZpY2VH cmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNvbXBvbmVu dCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ae2dZ1fiXhfFR+lIsaMoKhbE XrE37A0bKvZesItdx/bR//vcJIBlXLPWM2vmOVnuF8A4yb37d08SyC05P36oRgkJiRqtTm8w mkxmTjKZjAadVpOYmCCHIiExUaszmJIsVpudkWw2a5LZqAeJAgIOvcliT81wZGUzUpYjMy3Z ajboNIlyRBI1epM1NcvlLvKUMpKnuDAvO91uNmiVkGi0Rmua0+2trvc1t7BRc1NDbXlxbobd pNPIx5ZGZ07OKqz0dfYODo/w0VBfV3NNSU6axRAF0VvS88p9/tHp+YUlNloMBQP9rVVuh82o lU8SrcHmKKztGptf294Ls9H+zvrCRG+jx5lsioIY7dkeX//M2v5J5IKNIqcHm/MjbeWuVLNO iYgx2eltGQ7tnF7dPbDR/fV5eCXQWZWflhQHklPWNrYUjtw9PrPR08PV0fpUd3VBejxIbnn7 +MrB1c/nVzZ6ebw52ZzuqXGnW+Ij8g3yzyL4i4iUtank0MLJro5zRGUgD9yuWjMfrlqIyPLB FUOQ2neXX64g/k9BLvlF5D2IU0TkG+RffCuKL8SZjxFpxcmuioioB2R0OayOiHyD/IszHXX+ 8mT/jsi/j4g+vvOhlWFETjeD4nskBmJ3evmCZFgUEI2RL0hvnfsdSAvHQ2sr+BnIErsvxFMC KfwQEXYgt98g/+gb4/NqXx5/HZELXneIqgLp+/RkZxiRvvq3V61sb8vo0j43kLPtoFpAZtUJ kmiycz20KCKZ0R+N3yCff1P9rb8+3Z5tz/XVF8UiksDy0Hp9ugNIvzpAdub6G+Ii8sPM8WSn iEggVuUOkS3IuQxi0MgTtrhGREUg8wMNxZlWFURkfqCx2KECkN1vkL/1rf079TzdnasnIqFB lZwjAClRxckeGvSVOGzsL7+R3dCQGkDuI3uhoaaSLPYRAcjCN8jvXOD/0jZPFJHhJg/7Q+v5 /mJfNSCLw82IiFG+H2F6z04RAUhptipARgBiVyLCs1/rFREJL420qAHkUkUgo61eZ/TQwji7 6PsNsxpWeH1+QETeg2D9yOgSP5CD5TEREa3UHSRmPnAFaSvLSTaqB0RavxeNCKupgDhHrg5W xtvKKSIqAGkvz8WyN94gP68OV8YBksIc5IVAAu0VH0CYTZd9JZDVQEeF621E2M2g+wREy3IG HYEcrU50VrpSlXNESytDWUZEBjHrpKsWgZRxBLk+WkNE8qKLdTmDTHZVqQJk/RMQbutHcLJf HwOkOj9NWQcuDi1a9cbrt5YAwfJpFYDcHG+8B6H17Owi8ggQrAMvSI87tJiCiAXtsZX5OEcI BIuOOc0yja6EUQXIVtBPs/zlRwzEIsLpUQmIiDTxN7ZcgUD4PSpBAYmbL8sX5GzrzTRTgDB8 CgdFRMwFjM3OVEAOWT1O5PVVTGqkKXRWvTRAojOliIjwA8GErYFGFYDcne+8mR4kItIRWGEX EZpVEz8ZBSCuCqYgYg6HMvNMBllFRF7+0tDyH6mGxqdpDkd0fJozyJvxaQKp7JhYO2IWEXlY 1xMd1hUgnTxB3oyG6syICEeQBwzrjraURgcRdebUPJ4glwfLNIioDFkRSBVF5JrXVQujoRhE jBt7EyBdkwxBaMiqHUNWcuevDLLOLyLySI8Cojen5VV1TbIDUQZIoiM9Csgxs3OExhWoF5se OSm64wGSX909tc4PhLrj43qxGYNQ529VntL5K4NsMIzIMT07M9r5q09Kz6/pmd44vuH1PULP qhF9psrTTAFSwBVkUzxhK0laLmaQQDZPbh5Z3Y986KEjkFr/DFOQuPXTBkuGmyOI3B+EtaHy SkQCqfMHt06ZHVpYUql0o0gdWwKkFyC3vM4RAtmN730ASGE9S5B3vQ9GAumb3T7jFhF5dnyp 0o1itGTyBcFNu1eZi220ZhbV988hIk9/pL/prxXyLG7aY/e6BNIwMLdzzg8E97rj0r0u/Y43 Wh3FjQPzO+d3zCLy8oCpZ+OxOXQCZHB+lx/Iuzsrk9VR4hsMcQTBnVVsWk2CyZZV4hsK7UXY HVo090HckIiH+ROIp2l4YS9yz+0cEQ/z99fKUwYSTbZsT/Pw4v7FPaNne9M1XvkdLz/QiRb0 lDaPMAShn7/KE0UwHKqRn+/CbNUFhUQsaY8OvmlM0txMZvPOJBCxylVeU6k1yZODeE2gIxAx 1BNdL6aNDrOzmuUkg4SxqKeMBhYSftA4T0XHBLuxUIrIz0vRHy/1/rIbHnmR9fz8iKWIGFjA PH8zIqKncR4aHsEEOmxCIfu/keIZ7yJ50BPpEfoJPTzcXZ/tLY21VUiZk0RnfGdgJRy5faBt xMaxnENxZUkf/xzlh6JjtQoTkmfJNWw/3N/f393d3d7e3txcX19fXV1enIY35oZaynJTzchl hYi4KtpGF7aPItc3N7e32PYOu9xLiaAInUSIsuRKYm+x+r/6FNv+jUtRqFQHmSVR7WSZPMO0 Yvvy4iISOT8/Oz09OTk+Ojo8PAjvIimXX0nKpTen5Hib+qdXtsPHJ6enZ2fn5xFKzHUJXUGA vwahEJUMUSVCosq3L5IX+fXtf9G/lD0llyhLKpjqoMqoUtQdgWD5DKbJtWw7vL+3t7uzvb21 ubG+vra6srIUCo7H0qTpTPas4trO4emFlY3Nra3tnZ3dvb39/XD44ODg8PDw6OjoGDqBUCqB QudCVJ3Q76QjU7aFQZIohnySU1iFV7TxIeoMh/f3yfHuDjxvb21tKraXlxYXQvNzc7PBmemp yYnA+NjoUD8lrstF4jocWjqjNT3P29DRPxKYmgkGZ+fmQ6GFxcWlpeXllZXV1dW1tfX19Y2N jc1NYG6hbKACVmhPCBVH9TZXXPTP+CBtK+1HJVBJKBBGNzfQwutra6to5OVlpM1bXFgIhebJ 82wQrmXbYyMjQ0ODA/19vf6e7q7Ojva21uZGpBJ0ZdjNemR31OqRRbDAW+Nr7ez29/b19Q8M Dg0hn+Do6Nj4eCAwMTE5OTU1NT09MwPM4Ozs7Bw0D4WgBUmLUb3N3hf9M6wJ0T6wSCbhEjZh FE5hdXJiIhAYRyuPjo4MD8Px4AA89/WSa9l2S3OTr7Ghob6utqa6qrKivMxbKiV3TBLJHZHX 0ZLicBWWllfW1NbV1Tc0+nxNzUjx2NrW1t7e0dHZ2dXV3d3T4/f7e3sJFBoYGBgkDZGGhb5K pChtITYWu2H3AZTSRz57/f4estrV2dmBRm5rbW1paYZjXyN5rq+Da9k2fHtKiouLCt0FBfl5 LldujjM7K5puM+FHokZntNjTHM7cvIICd2FRUXFJiQdJN71lZeXlFRWVlVVV1dXVNTW1tcCs q6+vb4AaIR/UJKk5qrcZLqN/bpY3pH1gkUzCJWzCKJzCalVlZUVFeXlZmddbWurxlJDloqLC Qre7IF+2Dd9IFJqZkZGenpaampKSnGyPJUAFCEgMJostOSU1LT0jIzPT4ciiLKhOZ05Obq7L 5crLy8/PLwCk210IofiiYlKJkEfWl9lG5W2kPWBRmIRL8on2Jat51Ma5OTlOpzMbhrMcDniG aXKt2LbbbFarxWJJSkLaXGSjNRoNBr2UkRbdQchGS2l1KatuUhK2slqtNhslpk2GUlJSUlNT 06B0CMUClIRqINQnC+BfS9mQDJJEKVQejJJVeEUbo5GTUTPqh2MIduA6zjaMQzpIS9JokFYX iXUTxPB0AlDAotXiv2kzvQECrRFskMgZjNIgKhcSddALVRivT7Pyxm9An6N7S4WRUWGV2li0 MrUzSXiRXEdty84l85J9aS278gomwhHCxkKCWeKjJpAp5eKluj5/FY0gu/l8C7kQ6U0qXG5j 0cqKA8WRaPPPbCv2v34nOChWWuyTUtP/8B4rTPkkVScOkq+Nff/vdwv81Rb4D0mj2q8KZW5k c3RyZWFtCmVuZG9iago1NTIgMCBvYmoKMjkzMQplbmRvYmoKNTQxIDAgb2JqCjw8IC9MZW5n dGggNTQyIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDIxIC9I ZWlnaHQgMjcgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0RlY29kZSBbIDAgMSBdIC9JbnRl cnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29tcG9uZW50IDggL0ZpbHRlcgovRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBNZJ7c5pQEMXlAgKKVBAf0cRHg0lMFE2cAo1WHTI+AoFekAtog7aTTvv9 v0FB7PnzN2f37tm9mQwGAJ4IAAzLnIXhWSbPsmw+R2cJkGIMp7jqVbvdbl3WBJbCQeLFyMJl X51OJ8/qY68pMETiBZTYW0C0hbZlviiSyOAxBXTtyYoO/ncLep759bqYjRsApq64h/B1os0M FBhPdQY/QdXZ22q31VXM0PvWKZwhDNb9CifeLJCvdz8RqRP6q/tSnpdmW28hcf/hzny8qjaH S9fSmvlzuRshfTxSl463kqt0+rrqffxCpgF370jviWeooT9/j0GwPx6D5bDBEiCZU/V+f4S2 aTkI2bP7apwpge4hWCqjkTI3XWva5bMggc7ubdyqlBu3E9s3x3XmBE9zMhRbkzehN22zeOKE /rInUCRT7m/2/vxzIYWhMWoIxXJHsX94k1bqdCNvMby7HagbP852kfS8+OL8jNy1rq/etsh6 vi6SANDVkbGPdlsHQmivtZtk91iWl7SVab6uVy9zTe6IufhKGJErd3oDWR483EnNCkfHKeOF kgzHl0SxJPBcnibTy2MAJ8iTCAI/f4Z/ujdSpAplbmRzdHJlYW0KZW5kb2JqCjU0MiAwIG9i ago0NTAKZW5kb2JqCjUyOSAwIG9iago8PCAvTGVuZ3RoIDUzMCAwIFIgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAyMSAvSGVpZ2h0IDI3IC9Db2xvclNwYWNlCi9E ZXZpY2VHcmF5IC9EZWNvZGUgWyAwIDEgXSAvSW50ZXJwb2xhdGUgdHJ1ZSAvQml0c1BlckNv bXBvbmVudCA4IC9GaWx0ZXIKL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4ATWSe3OaUBDF5QIC ilQQH9HER4NJTBRNnAKNVh0yPgKBXpALaIO2k077/b9BQez58zdn9+7ZvZkMBgCeCAAMy5yF 4Vkmz7JsPkdnCZBiDKe46lW73W5d1gSWwkHixcjCZV+dTifP6mOvKTBE4gWU2FtAtIW2Zb4o ksjgMQV07cmKDv53C3qe+fW6mI0bAKauuIfwdaLNDBQYT3UGP0HV2dtqt9VVzND71imcIQzW /Qon3iyQr3c/EakT+qv7Up6XZltvIXH/4c58vKo2h0vX0pr5c7kbIX08UpeOt5KrdPq66n38 QqYBd+9I74lnqKE/f49BsD8eg+WwwRIgmVP1fn+Etmk5CNmz+2qcKYHuIVgqo5EyN11r2uWz IIHO7m3cqpQbtxPbN8d15gRPczIUW5M3oTdts3jihP6yJ1AkU+5v9v78cyGFoTFqCMVyR7F/ eJNW6nQjbzG8ux2oGz/OdpH0vPji/Izcta6v3rbIer4ukgDQ1ZGxj3ZbB0Jor7WbZPdYlpe0 lWm+rlcvc03uiLn4ShiRK3d6A1kePNxJzQpHxynjhZIMx5dEsSTwXJ4m08tjACfIkwgCP3+G f7o3UqQKZW5kc3RyZWFtCmVuZG9iago1MzAgMCBvYmoKNDUwCmVuZG9iago1NTUgMCBvYmoK PDwgL0xlbmd0aCA1NTYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lk dGggMjEgL0hlaWdodCAyNyAvQ29sb3JTcGFjZQovRGV2aWNlR3JheSAvRGVjb2RlIFsgMCAx IF0gL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAvRmlsdGVyCi9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAE1kntzmlAQxeUCAopUEB/RxEeDSUwUTZwCjVYdMj4CgV6Q C2iDtpNO+/2/QUHs+fM3Z/fu2b2ZDAYAnggADMucheFZJs+ybD5HZwmQYgynuOpVu91uXdYE lsJB4sXIwmVfnU4nz+pjrykwROIFlNhbQLSFtmW+KJLI4DEFdO3Jig7+dwt6nvn1upiNGwCm rriH8HWizQwUGE91Bj9B1dnbarfVVczQ+9YpnCEM1v0KJ94skK93PxGpE/qr+1Kel2ZbbyFx /+HOfLyqNodL19Ka+XO5GyF9PFKXjreSq3T6uup9/EKmAXfvSO+JZ6ihP3+PQbA/HoPlsMES IJlT9X5/hLZpOQjZs/tqnCmB7iFYKqORMjdda9rlsyCBzu5t3KqUG7cT2zfHdeYET3MyFFuT N6E3bbN44oT+sidQJFPub/b+/HMhhaExagjFckexf3iTVup0I28xvLsdqBs/znaR9Lz44vyM 3LWur962yHq+LpIA0NWRsY92WwdCaK+1m2T3WJaXtJVpvq5XL3NN7oi5+EoYkSt3egNZHjzc Sc0KR8cp44WSDMeXRLEk8FyeJtPLYwAnyJMIAj9/hn+6N1KkCmVuZHN0cmVhbQplbmRvYmoK NTU2IDAgb2JqCjQ1MAplbmRvYmoKNTE1IDAgb2JqCjw8IC9UeXBlIC9Qcm9wZXJ0eUxpc3Qg L1N0eWxlIDw8IC9UeXBlIC9TdHlsZSAvU3VidHlwZSAvU2hhZG93IC9PZmZzZXQgWyAwCi00 IF0gL1JhZGl1cyA2IC9Db2xvclNwYWNlIDggMCBSIC9Db2xvciBbIDAgMCAwIDAuNTAwMDAw MCBdID4+ID4+CmVuZG9iago1MTggMCBvYmoKPDwgL0xlbmd0aCA1NjEgMCBSIC9GdW5jdGlv blR5cGUgMCAvQml0c1BlclNhbXBsZSA4IC9TaXplIFsgMTM2NSBdIC9Eb21haW4KWyAwIDEg XSAvUmFuZ2UgWyAwIDEgMCAxIDAgMSBdIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4AZ3Ch1bTUAAA0P9EkL2nTEFAEBBk7ykI+ieWUegeSdt0pDtpOtJ0UaCgpjYnTZrxknuu /nedXramTq+pM2jeqV1v0DCv6w1M43W95AbjtdybBiPTdNPAfG+6UfW20VTVfNsItsl8K/Su ycxtuWvibrbcgdU2W9gtFm2lVduiZKtVW37fahVqu28V2ma7l/zQZhPebn9QXtdu13WIhXQd 4jshXU19JyQZ1nfC+i6ghi6Ysxs28DsM3QB7HIYehxGo09jD7HUaxZt6naL7nCa2y9Qn39zn oveDRMz93AOIuaplAAE9iFgG3dKtg27+IbdVqsc6JPKDx6bisNcm0j7slTritQv32Uf4oREf e9QHKYhCo+VjKMSEx1AFx1GY0w+PczrG/QIn/A7QAccE2/kxoOZkwMkOOifpLpBTQZfMkGuK jvB+CiEqToeQ6fC/bqVnwm7REc+MyNmIR2HvbJT+WdW5qJfbNxf1zWHy5zEfQHQeK8fReeYX HFVxAUcXcD875l8AuxjzCw0sxqoSgUXuJSKgZHCJqPxKBOlxZZfjwaqh5XjNRGhZ6EoiJDe8 khD4LRlWcTUZEZ6KrEpeS0VqRtdS4snoGhldVxBbJ9kbJMafxjbkbqYxJr6Zlkvhm8wtCpcc 26KEb1OxykxsGyixnSF2QGaJnZq7WYI7vpuVv5eN03OyE3s5zv1cQmo+sS/0IJ8oTx7klSwk D0WnDgtSjwopgY+pI+Hk0SP9WOkieVx+UiSrpk+KQE+Laf6n9Ck/dfrEf/ZEAX2mzqp+f86o e/6cqXzJnLOz5y8yL16yMkvZi8rcRanyRymn7mUpd/n6f/7yFfTVa170W/7qrSD251tB8T+P vwD/Bd8WAr8KZW5kc3RyZWFtCmVuZG9iago1NjEgMCBvYmoKNjU0CmVuZG9iagozIDAgb2Jq Cjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDU2MiAwIFIgL0NvdW50IDggL0tpZHMgWyAyIDAg UiAxNyAwIFIgNTkgMCBSIDEwMCAwIFIKMTQxIDAgUiAxNDYgMCBSIDE1MCAwIFIgMTU0IDAg UiBdID4+CmVuZG9iagoxNTkgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgNTYyIDAg UiAvQ291bnQgOCAvS2lkcyBbIDE1OCAwIFIgMjAwIDAgUiAyMDUgMCBSIDIxMCAwIFIKMjE0 IDAgUiAyMTggMCBSIDIyMiAwIFIgMjI2IDAgUiBdID4+CmVuZG9iagoyMzEgMCBvYmoKPDwg L1R5cGUgL1BhZ2VzIC9QYXJlbnQgNTYyIDAgUiAvQ291bnQgOCAvS2lkcyBbIDIzMCAwIFIg MjcyIDAgUiAzMTMgMCBSIDM0NiAwIFIKMzUxIDAgUiAzNTUgMCBSIDM1OSAwIFIgMzYzIDAg UiBdID4+CmVuZG9iagozNjkgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgNTYyIDAg UiAvQ291bnQgOCAvS2lkcyBbIDM2OCAwIFIgMzczIDAgUiAzNzcgMCBSIDM4MiAwIFIKMzg2 IDAgUiAzOTAgMCBSIDM5NCAwIFIgMzk4IDAgUiBdID4+CmVuZG9iago0NDggMCBvYmoKPDwg L1R5cGUgL1BhZ2VzIC9QYXJlbnQgNTYyIDAgUiAvQ291bnQgNSAvS2lkcyBbIDQ0NyAwIFIg NDUzIDAgUiA0NTcgMCBSIDQ2MSAwIFIKNDY1IDAgUiBdID4+CmVuZG9iago1NjIgMCBvYmoK PDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAwIDEwMjQgNzg4XSAvQ291bnQgMzcgL0tp ZHMgWyAzIDAgUiAxNTkgMCBSIDIzMSAwIFIKMzY5IDAgUiA0NDggMCBSIF0gPj4KZW5kb2Jq CjU2MyAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgNTYyIDAgUiAvVmVyc2lvbiAv MS40ID4+CmVuZG9iagozNTAgMCBvYmoKWyAzNDYgMCBSIC9YWVogMCA3ODggMCBdCmVuZG9i ago0MjQgMCBvYmoKWyAzOTggMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iagoxODEgMCBvYmoK WyAxNTggMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iago0NTIgMCBvYmoKWyA0NDcgMCBSIC9Y WVogMCA3ODggMCBdCmVuZG9iagozMzEgMCBvYmoKWyAzMTMgMCBSIC9YWVogMCA3ODggMCBd CmVuZG9iago1MTQgMCBvYmoKWyA0NjUgMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iagoxMCAw IG9iagpbIDIgMCBSIC9YWVogMCA3ODggMCBdCmVuZG9iagoyNTMgMCBvYmoKWyAyMzAgMCBS IC9YWVogMCA3ODggMCBdCmVuZG9iagozODEgMCBvYmoKWyAzNzcgMCBSIC9YWVogMCA3ODgg MCBdCmVuZG9iago4MSAwIG9iagpbIDU5IDAgUiAvWFlaIDAgNzg4IDAgXQplbmRvYmoKMTQ1 IDAgb2JqClsgMTQxIDAgUiAvWFlaIDAgNzg4IDAgXQplbmRvYmoKMzY3IDAgb2JqClsgMzYz IDAgUiAvWFlaIDAgNzg4IDAgXQplbmRvYmoKMzkgMCBvYmoKWyAxNyAwIFIgL1hZWiAwIDc4 OCAwIF0KZW5kb2JqCjIwOSAwIG9iagpbIDIwNSAwIFIgL1hZWiAwIDc4OCAwIF0KZW5kb2Jq CjI5NCAwIG9iagpbIDI3MiAwIFIgL1hZWiAwIDc4OCAwIF0KZW5kb2JqCjIwNCAwIG9iagpb IDIwMCAwIFIgL1hZWiAwIDc4OCAwIF0KZW5kb2JqCjEyMiAwIG9iagpbIDEwMCAwIFIgL1hZ WiAwIDc4OCAwIF0KZW5kb2JqCjU2NCAwIG9iago8PCAvTGVuZ3RoIDU2NSAwIFIgL0xlbmd0 aDEgOTMzMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG9WntwXNV5P+fcu/e9 d++9u3v3vdpd7UvalVYrrVa2rDe2sbAxNja2ZGKDsU2MsXkYBpwUU9MSN3Va0qEpJSST9yQp 01In0IxttRkP00A6ZSaeTMqk1Glp2jz6mDZN2kxDQerv3LsrRMpQ/kjr9dH9zuMene93vveK UEKIQc4QgcwcOnHwng9tP/UgRl4ihDqHHrg/F7hMnwX9KsZyt9/z3hN/duxLTxLC0BVj7z3+ vts/Is/9jBApTki6dfTIwcM/+s8NZwgpbMOC9lEMBL4pfA79R9EvHj1x/6mhPfTf0f8i+qeO 333o4J0zhy4T0ptDf+rEwVP3sGnxG+jfin7uroMnjjzx01uS6J9Bv3rP3ffdL5rCP6PP3z9w z8kj98S/1FvB1gr6x9AoPvyfAVLyqHf8QTkjnX9Cl1j7FNd2OB0gb9lWJoqq6UbQJCHLdsKR qBuLJ5IkRdI//+L/QT/zbvaMkNvIr5PfAzqnsDy9UsbtTRMizKAXIZELhNS3XiDqjoUvUfrY 4gW68oELZGPmIlGJcMuBgQuE1nO5TXdsPE9vRYfVMdCfByXUc5vPC6XNNy70LubO5c7NHz6X 25w7evDwebHkPTFx5NxiI3ee7Fq4Az93L+TPzyymVskji4vj2Efk++AVLD+3iB2OdXbA0xtq vIFFgfrW3HmhvGNh58L5MxtT52c2Lqby+dym85d3LJy/vDGVX1zEKmn1pDjx6TvinTPLOLPU j3nF32UX9sAWi+fO8T3RY+X8+cvnzqXOgRNvpDd/gZLOADjla4TSpgt0ZscCn5rpzaf4QG++ N49zLG7E3mp9666FTThJnp9E45AK/wNSoQOpvnpQrDVwPN2DNPgLgtR8N5CG3hWk1upJ3wKp jTNbHFLn7SHtfQdAVxGeeRuEz/gIn3kbhMNvQTjyzghHV8+NQ7o4bdRDOPYLQjj+bhBOvCuE k6snfQvCKZw5yRFO//8hnFmDMDfxsBL0K0IOnkEmW5aIiA+sfg06ay1hUIQt5D3BIjAimxbw o5G6iCXS1OISXqewlHyeWZixLmI9fX2oOWLn7dKI3TtNH1x+8bXXhNzrr06zz+ItRlIrf0ee FXpIkoySx5ewe4BEvR0CeDtMAq9fJAX8xI5X0BoXSAE7q6BV0FHQFmirM54BnenQOdA50GGs 6Qfd36HroOugB/EcxDOA+bGr4CaBjsdRmXNU5hwNNcNuNCJF7Qh/9BYq5dFWm/8Ya48M+1Ot mCt3ZsbalValzKeeYWaoJ95KqyJVQ3plixaQBaro2VZKZowKgqiUNrLXZFmrBJefC7X0cKxo hAIp9fQH/sAOvnFED6pVneVsw+nVoko6YQmOoYYBF6Err648RD5H9gIaGWe2G0PNMZxNNqks lcda7bEpNjLsfobFM+NWdCgwq0iCYcbGBhXJTle2UzoYY7NJpWQkfOx/wPYKw2Q9mSKz2K0M BKpdFDSOgsZR6MCS4gMpPnCJTGCmajvrL+FNnxpqliS5ILsxnIYDxaGoSLIk+8hxzJyxDnJ8 DVa2OVSc9laybXKc9ckDyYn1UZlRdeDGU4bJion0UGzrnaxguv3pohOelnqjelDp/S+7dG3w paDABq4J9zQzmq0b6p2GmxnT1FSmP52I0NM/M4xhSwo6xXzy6b+mqiSlKtH1089+7G5P7hIr /8B2CVWyjsyRY0ukCrkreHJXtWa5u68SF43tv0AmISiTDc5pgUyCZwDF5ccTlQDHBMtXQQrz gbAPkg6i3gHJpwCSD0dlkDZoLEuBgyc8nmCNCoPUF60sHXG74ADCAFClBVkK0SksYDfSzeWY qYXU76g0k7aTpVyvTFM5GimkM+G0JtOJzaPXN4K7d9xEGW2ml19zh7QZNnV4Tgpk+1SpV/rI e+R6yA0bkUiPJJpRlY0Ha1rSMvUYjSXbodT8B05vfY7GgmxPvzL57MYvFH3ZI9rKX9Krwjoy QrYtEQV8JzzEFB8xBYgpHmISEJMAUQIqrHnKm4CSxTAa80YvkBToVKMjwBQQgEspGolxPeOI lCvl9iiXFkx40uRJzhjEm461ucjQb+nFhlJqCnpUdevlTQGhBBVLOboVzCkWEz78lKGnLLdY ZV+OClZk280XnzcHtKCe7UuHyvaLv7Ovrcl6SnUismrWGoqYZqyntxziOsaIsvIdepkNkmHc eQ8OyXVChwQoRO9I/UiH4lLvn69iUt8+4JDt0Va5t8CFH5/Oybmk48OvHEs9Zt2R4Tb9amhD xLAkwxBOjs+ntVu23yAWjGjKMMIhJ9mvxAY333FNwlLUIMuez25IFB3NSE72N2U9vz43du/B Ym7/3OCAbfXoKUPJxJjQn7aC5XT/TO2BD88FqyH5X61Cui8TT5r3c94ocVd+QE+yFmmQxy6Q ITDWRHOuvmlfh3BVGq5H4+OgI6AjHn0R8W3gdWiHCiKBxrUjiekkptNYmgWt4c57/WUSCBeN L+M7+RYXeJpY76mPxLVF4trimQ+g1cXQNwyr/dZoC4BGIyPDgLflmQ16L3XSyvQ1N9QrQ6O7 5/oKgjxciWrUssvZSlih8VjWTX7ejeXtW3fM3/3LB47OT81HQgVXr2rhiDrwtT2Hp9VUPBTs 3Lmz8k/0t9gbpI9sIL+7RFqQ7pAn3S34vRJ6/V6v5Pk07o/6wVFX0EXQXZ/E6egVz4a0wH7L Y7+FweEraOCc023QJTwnuePhHsuDg3E4mG88VBAZz3hEO1RX1uCCxtbiBGHzrQbXi46v4taX KxW0KeKjRn/DmKoEAxodnNpVzgwMz/fVkoHo5LAhBq3HwlA9U6fNWNiRUlZAlbPK7IEt9x3b e8vcI9ZwUNMGioaul4JvvKD3aMrK4NTc5PC0nogH752d4Kdb+T79EGsDpkEyvUQceP0BDy2H W4br0NmHxvbPqhCdAYjOAGAegNvBKsjGEAeBy4QFbwYvgg88whq9wQh0x7t7rv9wcAJ4i3Fj SM8qg/LQWHVrrVJv3miFHjSkDTOHdcmMx5KuIiq2pMQHPlNN5KXGjjvKNd2JCoGdW088sHib wR6/5oa9vVUj4YRM1qcKDXrt+m3Xhe6qIbWkRFh5hX5Q2IioZN6PStIeRzxa4KJu4wJtmASH 6wSuyY8jBjA6wM2aAW548FHwlhikgCVDTWrSEBXW2LhRG5zyy+t+wJpvNcAeBj1zQc+qY8kt tCyYA5lmQIq4m1QpO2iyeP6grKYnBTFXNoq6yuT+lJuo0VeSEossLyUHDVnuzUSTVbpOFdSG aWkBJfDE7M1ZVjSjWtCsD5U2saBCaTUm4w6jK7P01xi/kgny8BJp4w5zHsdtyD+P+ga9Hpfu biQmQhfiRIQuuODbbeCuVSxLoLH9l0iFvwK+cesS9nPRymj8I+7H2k0gbkLj5oFvO8XFoAYR oLhsSLIvBZUyTEGWxtzRVmWNfRhruzEv1HIFBGS+/+Ai0qbvZ7LYP7NjMqvYAXVXNGwWQplA 0crXp8q9pf7rqmUnGNbdaP9J0YnkkhGHMd1MuOMsvOdrH5p49NaA3FQDWrwREPoo213cOekU 9txw7/079jFacIqO7i7/23hrHP8nm+P3Qk4GVr5F/1yYJuPkty+QicYSnIYIReAx8DCYmkBb f/UiMbuW0wQ+psczn+bA8WcczzjkhdPdIJbbh16M92Kc01XQ3BNx2g9ogVcPBjzbUee2o04M Hp2NwGvxwAPaxIH0bWp7FG6pUubiFYNdwIRvXe1WGAYEwsZlz6RRm8sdZulXpGa6ZgRiRtyp 9qfzAcGSU6l0MhRgNKAXc6MStdffPVHM707I0VQuqAazwdZtT4vCxPT292yWJDWvaWqlnqT2 YXpISsiaEi3EJEtZ/uoZRTyw5/St3B8xkl35G7KEKkwCkrAXnqZ2iWTgnGLArwFG82s8E++H AEIIPHO6D3Rfh+5G9RmMr+OCVILmxeGlYzU/iPf4XsUCobonPeGuwex6Gu66uzHYM4IkMyYm wql0waCMMcPqG+jpca1EpmxFBSmupVLtEPsXQVbdlKYVokHdjMkJRcklVGP5NXNDePmVyLwZ 0axk7pPlT5cQgOTjmu16fjgHm/kToQC5ObNEbOiXn/XYfixlQ11sT0p0MMnTnETnmcYzDaZt jJVA82flChjOdiXhTafaEY2fj0mzEA2unmHCKV9IfP4biE5WBQNhjO2B5PsVKdyxUpATCFUI Komo9Mf0mqDmhGKB53Q90RgISkykAXVwwlZDjK1bMKBqkpKZrEY+/2VWdrfL8kRUtBPCw7vV lKwbyawZSqrscafouoapDwbHl3/S3mv0OBKrJ8yq8/tnmKlyOaEkvvIXyBMHkSdmlgAONzVc x1ywn+b3zYWCwXjEVsVdaI1OUf+wfgL3TKQ9HJFMURhO97mWHSgXNEMbDLGzozRoZy19xHrj i6Gmrnu/L7/yTfYC24BM65klmMQAqXm/bwLWcB49P/KdR28Xepo3t4vfnYpOAo1bNQ2H64YI nFauoOGcPBr2I2Au7DWyC9cA04dR7kB24bmz81zkrLXwyhyagxaBWGdQwpvz7nBilZrvUEPN fAcAX90FaDm/W/jTsXbUz8ikmOuPVFqj3YzDu+MM7eSPWBCVveuG8ZXCXCbY88HB8XSIyqG9 InOCVqYta0gvAjG7TwqIYtKNN3WLUTMQHJ0NCuFsU9LdZHUnpTaz+vO2W9shwNWUqu4j4UKv uZlJy9+ljYwml5OlE5+U+mm5d/c6ozfrpuzE+x54QCuqqhLJybJa0E9OHwwmI8VEMqV+u3j2 dsMafP/yd/Uem1d/KcmtXKF/i3i2SQ75frro3QWvHuhe6qECSh29iNdz0PNwBMjdhISvHfRm 61yReCSS8vy2SVIezEVYbE5BVbwo36mUhUjUD/grrt21GL7b4iDCgOLD68IufZW1801HSSYO 0lK02GdQKiKET22QRGs6t35LzTEpM+QZt6eHtkRx+YfZbDFb0R7bS59Se+Sw6eRDmqYVjXNn a9cFhOvHT+7bJzsa1wlGHMTyv4m4y4a9P+4HHHkcnsFm5sCfH8Vf5NrCo3YJBP9wyTQBA+eT gfWsP62CSKCx/cDg56LzJWIBasR10DjL4h666z384GVkWIZjQRAJhnn2Q6+7pjG6/z3D9UJx Xabn+tl8PKqY9XQ8xsSNnz69cGhx+6lju/dZym3C7IbZA5XNsrhz++LjHk/ZlTL9OFuHAHEd eXAJRY6uZZSha7wS78fhBPzJaHkwwnnmdBF00Y9C+sFKv8dpFBw2wSGYWo2zTe4rTaJwXymB 8ONsfsucAnu+a1xjCxFzj67esx+dwF+i9OPF2R7nPDylH39rYC2ujbkfFrVqrBSJROKWSSPH 9h6YPbM2tmbreWytpi2Jh99zB+bvuyU5e3qSx9qjuOs4cHnCw2WcfGwJLj6AWgy/jxHgwqtm Pi5clrmkX4I/6fci00sk36H8nGUVJQmbuGhcHkYAXwPwNQAlp5ugeWIYAD3BbdBqWSjIsQv6 2EVB+FWgfIfyRaOThKz61Eme4fuBLkDrmhyBJ8lRKAmXGw+9x0UrKBrDk9FAstY3PzyQKe+a GqRaIFiZergUa1K410g0zNKqovXob7wYLOm6URzQtOCwdWb2wN5j980fmFOysipZy1cnT98b jCf06eHJuSk/7/0+/SibR4g0voRLDwAljp4EBiNofjzv9/2gq6sFHYa9HJXClobW+sj/KRfR mFejAFP0SbFQ1T+bkO1WMWqKlhjcOCoLFtsTyruFabocVbTgHz/pDhhGqBwLxZSiTh9QkwoS lgRqE4ZUvNkuMKGYCUDsKZFRk7gNdm4DKfvZacY7f8uPF7qZJg7N0w6BJ1J+sOPHOZ494uEx whs/t/LFF8fsXA1m+G34C+lthzfWBouZhKCPx824IMhROxjTmhsStYWNm0vZgF6PFRKyEM6U Q8M1J3V286G+/FC/npCDkZiU642Hsj2l9NDM1ntHa3Ujne0fMCJqXk6uH+81k26sF3XM76+8 TB9hf4oKy00+P77d5skxd5nFNXfC6TDGwuCM01HQUZ5lBTFQh6XmcugX2lodCnJYgHSFKCq3 CGq59HEgRtcWaZBzrQZ7q+7PgwWg0AWloMpyqU8MNNOj6CP+k9Kmbm8W5HBGik3qgWR9JKrE Hdc2AtJ0jL4Ar7f8dHjCcZMNc+vwsVM5FpPiCUm2mCiohb1aXlGVatWC8debSthk9oZwAVeL u02s/BU9h1hjkJzwVZDXZURYcR7ldmsxXZPNCyydOowEwkXzM6iLpNi15EWYv6I3XABWhQ5u FdAVjhuPQRwv0UJw4Nk6u9WtzcKCg32eIfhKuQYi+kGmaMwunfrDoBy2ehJ1kblMQ/bUH5Ql R3Py6Tz9YciO6Vd2Pk2n99waczIRO2rKcnC9s+6mPevnHrv2Y1pZjasB0+Z8r3wPOfY32Bhs vY5T8ai26p2KOxf/48nqBPL8iuBdILe5+CAU5aEd/bpsx8X6pmAk0WxYhnC7EAuL2mRQr5R7 ckeVgJqPD7J00Ixkq/rDl+fSZUGwjAS+THYMepeRijp1pjzyvlN0Jq5aDs7zOu7hU/ietE0m cZ7VKtUwN3nDRFst8rb4QIsPXIIZMUnLixIGOxS3gdxM8JN23CSv9nbEEAefpij/dvQyS3uo ZzAQqNJPMDctnbyVhQ3BHgw7iQBrT0hWLJPKiCwmLEwJeSb0pHOO5mpidk6NOrqZbDLHDkW0 Fy4JadtUlJqi99pnT0UqkVhaT0ifel7LBGNOSDJr0QMPhKtyIAN501e+Ta/Cl6zzvkNoc8w5 3oIHatckhPgYDtopT4Q75/eTo5g7jVo0P/O3hWhP4OoTetlIV1PRQDwcvGTEI1ZpHRWthPDq cSWF78rXhw1XjkeCHzf6jewwfcV10tLyy3Fmj2QSGYGxDDN0yho5SYqbrkjbJox+shaPhURG HRqawZl5Pea8cA3ZQf5oiTt0ssWzf014vx70Gl6vB/rSgH6gNg0PKGFUwdX4euRnjrxi0yA9 3mgTqyPQCV7d5JpWA13r0DwQ34KxN4v/W0jTe4v/jhu5S9yGpdvRKmjrYIUk4LndkwRnlZrq UL5fBMbtNw3umFfi4RKNMT9D6XpMpKfy/1Ynok8LEqo38Ugq1WvQebEnW08PRmSkp8lMyYoi XW15NaP08FtrRqLec1yo+Tmr2o54OWtcrn9BUfS0rq9NWvOfqBzbETffqZZEocj8by/Qtv29 +9FbQhP/QW3hh9ysveg+lOo+8a1Vmb2Aahr+BAGxjP8P7wiH+V8miL/6xs9WroonvZ06k94j i78amSavgf46gp2vrrzKjpMUGycJ+irR6EtEoQ8Rlz5DHDwz9CgR6OdIlL6MGtbXSRZrcnjG 2RWSp/9IcvQprHsG48+QuPfeSSLTo8jCn8J+F1a+R59aeR3v6PR5nJHg3taRK+Sn9H5msl9h PxIeEpPio+LrgSelddJz8jb5UWVBeVmdUV/Sjmsv6S39ktE2HjZ+HNxm4i9XPE6y5CsdXn2O szxkF2MeZ3wFLI5H87ic7Nu3ec+um2rXHzx555GTm48cv39g99E77upitfJLsDNv9w97el/K hmDuR8kY2Ug2k2uhGvOoum4l28h2cgM0Zie5EWnqblTb9iCfXSCL5Gayn1wmEOIIYiCttoSj BPgvq9X+xCve5lE7CREFvQB25j3d66He5fX8OYa5OLIPf07AHXV7XBtEImNz4v9VBiH/DSll th0KZW5kc3RyZWFtCmVuZG9iago1NjUgMCBvYmoKNTc5NQplbmRvYmoKNTY2IDAgb2JqCjw8 IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvQXNjZW50IDg2OCAvQ2FwSGVpZ2h0IDgyMyAvRGVz Y2VudCAtMjE4IC9GbGFncyAzMgovRm9udEJCb3ggWy01MTkgLTIyMiA5NzMgMTA5M10gL0Zv bnROYW1lIC9aWkZWU1UrTWFya2VyRmVsdC1UaGluIC9JdGFsaWNBbmdsZQowIC9TdGVtViAx MjIgL01heFdpZHRoIDExNTUgL1N0ZW1IIDEyNCAvWEhlaWdodCA1NzEgL0ZvbnRGaWxlMiA1 NjQgMCBSID4+CmVuZG9iago1NjcgMCBvYmoKWyAyNTAgMjAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMTkwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAo2MjAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NzAgMCA0ODAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgNDYwCjAgMzgwIDQzMCAzODAgMzYwIDQyMCA0NzAgMjAwIDAgNDgwIDIwMCA3 MjAgNDkwIDQxMCA0MzAgNDMwIDM4MCAzNzAgMzYwIDQxMAo0NDAgMCA0MTAgMCA0ODAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw CjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDUwIF0KZW5kb2JqCjUxNyAwIG9i ago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9aWkZWU1Ur TWFya2VyRmVsdC1UaGluIC9Gb250RGVzY3JpcHRvcgo1NjYgMCBSIC9XaWR0aHMgNTY3IDAg UiAvRmlyc3RDaGFyIDMyIC9MYXN0Q2hhciAyMjIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29k aW5nCj4+CmVuZG9iago1NjggMCBvYmoKPDwgL0xlbmd0aCA1NjkgMCBSIC9MZW5ndGgxIDE0 MDY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab17fXxUxbn/zJyXfd89+5a3 JdldliTAJmzYJWwCgRxDEt4UECImwELAgCG8BTFS0DTEGCNBxUgTkUuVWlRUKgvFENBroeAV q15blZ+17dV6q/Xaa5RaaltkN/c7ZwPSXm97/7if3+7OmTkzc2aeeZ5nnrczSyghxEy2EYGo N61b3jzm9AcFqHmNEOq46bZbfQXxa75A+ddIv13VfPO6i3fMzSVEOEuIPufmtVtW6R4+/igh pv8gJLekceXyhi/D18QIGe/DGBMbUWFaJv0M97W4H9W47tZv/anDvQj3d2A8snbDTctHtLlK CAnjnty5bvm3moXD+o8JieCW+NYvX7dy6Vfzv4t7H+79zRs23aofr9+B+0rcP9Z8y8rm9Dkj /hP3mF+QUUfx5R8zivz+H3woS3UQRCLJOr3h6+7GVNFktlhtit3hdBF3WnpGJsnyjMgmOd7L HX3+kYFRuXn5o8eMDRYUjgsVjQ9HJhRPjJaUXu7xj/NJ/7jL1z0ml02Zevmu/HLh7+RSC3ER krr+927Cbt5KyNCnX195KTmGX/9vPnoMw9P/988bmPEs0sBwOvE/QPAi6o8j7Se7kTb9D72+ ufoCuXClYQ/ZQ5bg24rvteRa1sSeIR3solBJdpJ+8jRa9pJTGP8Tsok1kxN0IR1H3sL3Xt4f nLiPNJJb2UHyCM/JVvYOaSYvkWfIY2wFm8OspI/+hh7Bk33CeradHWW1zMKMeCpOxhKiTiot iU4snhAJjy8KjSssCI4dMzo/L3dUYKTf583JHuHJysxIT3O7nA67YrNazCajQa+TJVFglBTQ eMa02sOZuqDH7/fXFQ7fZ/31fVzIVb7wx4njrzp5/rrT4RF/c5/9N/c5V+7nxIkrXh2YVskH Pkyqfxsnzjh1xQmfhTqvw0zDkFQ1NAWqVsczpzXU1+OJyoDii1efDw2DogF82GScFpi20lhY QA4bTSiaUELf5sO0eirVCqy6atJhRvSWwoK4IxhnuVU8NcXVHfUoBCqxdLQ4v24ZGDp579VN BI+lOhF000o0Lk+L67R5favj6vI42eE7XHCy+94BhayoD5obAg3Ll9TGheVA6mEi5FY11uAO MyPVN/riIubVLh7U+Koafd24593qcQ1U4qlvrEe1YVptl/+kJ+5AXhW3B+PT8eT0rR96hO6q jNU+ftvd3eWL77u+9upWP+9TV1eXUVjg664KYKLKwoKqpgpgOiPE0S3m4jezIVDVsHq5L75t RRNwg9/yezni/d1KvPpLoIly1PHUUN/E4W1CXxGZr3vHSm0992rwc4zSqkYQb/k/6tXdXcUn Xd7AQcHI0+JqjZaRmkUcZb4qoLeybrhquANaRK2lvrIO9OCzzZ5fOw2tVYHlleBTzstXauqH a1BRdbnRx+GcGVfr476bfHEyvzaAh0v4ZWUJ6b6phPM6hqGFBbPnff1UXMpVAr7uP5I4rQ8M fsoh/rpm+XCNnKv8kfDG6kB1fXd3dcBX3V3fvXxgaNuKgE8JdB+ePbu7uaoes86rjVPUn9jh iVffWxdX6hvpJNCHc0n1/Npyj9+OdaRu512+JWA7MB/YHMsBFvCbOZyBFqSm1u+bFic31NZ5 gMhaXq5BOZVzZgNzl4APhtHGcbSSLxYT8fJw0e/nHLxjQCUrCgv88W3X16bufWSF5whRQ0HQ o563nLzc4r6Bt2y73HLl8foAiHNUU87uuD7vys+mpDmrGifFadrfaV6Zao87p9UKHsY3BUrM I/CSMQhpUBZPD6I8OtgNsvw0EFeCcan2pKeszqfYISU49RYEZl+/qNZX1X2FC1I1wyvlLKf8 NPAKheSBXFLitEyDiWpCCfiaGRfSS9BYOED6CmYPEMO82sOU3l83QIc6BypJ9nFiIMKypWh+ qMDnq1pdCdbAze4CVIz1o/Rwga86RdBAna/b1z2zodtX7Wtc3gCqaTl4b2V3XQjEW1CLDcxJ GFfrPFeKK+vqJmGcPXwcPILu3XUYoWl4BORaVSiBTv9UMBucnTevFrt/WyVYoLIOxAULnQSv nQTz19Wh194rkALi1tUZwzB/FzDvHYv2R1KjLMAYGKKuu5uPiTuWB4p3d3u6sRKtJuAfoGS4 YoBofSAUBqg6r5Y3qQE/Z7mqgD/gBxx1lRj7UZDk8oYaIPv+G0pJ5VUo/d4VQPHkYwDvexpK v/9/hNL9/xuUPv6/QukTVyD9K5Q+CZif4Cg98M0oDfwdhF7BsPoNGN6WwvC2b8DwU1dhGDYK 9DwhOgKjWEAWBRsHTxARdQ8HB4ionEC1pJUFhfx1A8NDvBNTisb77X57Li4UdRe3SeQrnhMU CCO7h87THqmLmIiHZKu2rCyHaIgLTtchpYIckkODFwZJ+WB5ODS+KNclB0bmFU+YGAmnCfl5 rFiJhO0uG0Mt7ZkemThzxoSJ03sUd3RTc6FHMThMjeHqKlTPpGmRMvp0L81N/mbwzw9P4mY4 JR3JIGvFvApJU416DxF1lEqt1lAiHCoj5eXji2hENlK3QgP542g+pnUw88bWjaU0f2POxnUT b3xW6jqR/HPymUcT7yXvyL3n2R3v/cen9BiGxtiZGNuBsV18bINIPAY+tvL12M7AxCxaPMFI 8yPpOZRbWDor3d585/qJ5a1Nzd5mjD83f3MyeIba6fS+Z2k1ze3J7Xz23vc+/fefNf6rNsct ZFCcJPYDbyE1Q5J04kNGSonBoDM+JFLGqNlCH8oIhiIhpSxRFg4RlLQC8Gj3F/vtEbvf7bcz mtxIdz5NdyY3DtIHD/D8QHI9X8OcISutoXpiJTmqlRBDXHRQKouimROlNOQoDYEuEZAlvXgq jQ6Txe2SGwpHCU0zw1PmbPsiN3jjbG/DxLlrazYc0GCeTxtYJcsH01iOCj2ECSHANTi+yAlQ 5tMvklaWf5rPvQo8sYi8j7XZ+klcdgqHDCGwQWJ8UTQMXA2zwfuRGdMnRKqr36+OhCsrw5Fq bQ5p6DOWL92DOSaoDsoE4V1C4a1QBuwITjIwdL6fKUCQAIxEQpGSElIeKY90SeOCXa1nsBoa oRJ98IHkBoe05+IqDAkeXQp4VghPA550MkK1OeJmhYNlqxAOuSsMoQ8TH3IexUKuBs95Fajv RGbMiIyfUT1Ny6dX/2ZGJFxdHY7MYC+jNH06SnwefKSFUit2mpF8W53+FwPNJGm0VN+oF0W9 wSAYJVk2UIMgtDPqAo2JQZbbdcSl0xFpl2o06gyUiEyQdQ4qsBdlYnjRp9OZ7JFQVmaitBQ/ klFeVlZWXhYB+bIGhxfdNS6Dr71LKUM6U0ZjJMa5nwYEvxCgJspq72MbXz+ReDb+utD6wc+k 1osd9JHkCjaPXkxyb1mAB0PEhfAWbcDPSLJWnbXKdJuJbdFTQ+auuQ5qcxxyMIeD2ncxIWsX dRioWdLJ5onmanOdd7V3S9pWb5fOkNZq03l1IZ2g03lbzQOjHFlt9LmA8mWiTEmC4WKDMbuj VMMzgI9tHCwdX0RisTHU7g/nUGwgfrFSGrBHwvBoBJ5PxR4bR9mmZD5d/4Mfrzr38HPrzyW/ Oti5r+v3z7+0v2X67G6pJfb9Nf9al/3jrjUHmsTTySVbl7+SeDpZFVk7VW2awHmxYei8NAd7 OY0sVyuedNMDNirUCtTcY7HYegaMlBlF2kOIu+eYQAWn5Khy1OlW6zY7JLOZUB9V6TzaTPdR mTpaqe5YuvJleDAUi4RipDw2GA4Nli/TstiyGEe6W/aPHAXBRvxhyZ0XGEncLhIJS3N+lfz1 75InXqQ/pOW/opY//u588jQt+UOSVv7qWy/QWSfpeLpv0zv3Jn/24W+TPwcf7SVM2gd6WEk2 KVSzlV1UsO8iDkPGrIyF8ip5S4aU0SoPeO1t5Lkc5ctB4BfgpBjY7veJDreL6WRIpIAzAOxi ewOh+ePYXvoOzabXnlnbsKpr7l0n9Bcp6Xtiw7jv7C7puZNJm55JHj1z7xBZ3hDxusVTX/1+ TPm4vo8+uL+4Mo3jcQ+2+0uAyUSq1aBul1ekc0VqEw+JTBRNwi4i6HeZHBL2XpFxnjFuFIyC vs1oes4MhCXKgLEIZAWHUSP+LcNCQ5NhEB57hIxEnJUlzrCbLp2TWo4kF/4wOecIeJMCF0To xLwGElX9ul3NIhVFA5/P4JAkBfR5ANabSDEbNTxnvDwb5kpNdfVEgb3sk8T7zJ94/yyfY+uR RAumwByN4JEV4BEPWa9OVw2qvdK93yA+mUYPQNJ4dmF3GC09VqvC+cUossy0nmMAw5mpo5Kz yrlI16RrcUIZOi2WzDbWn+1s1R0bkaJLacgOZk8xS2mKY7ALQoMpdolRv10M+IidM0xa+tcc U45dIdxHzyXxeTy5nD5LK297+7GLX36U/Bc66U/fetKZ/AOLJ+LNtJeOoaV0X6TytZ7k2d98 lnwzKtOAtibsaWmyRq8S1S/tmmtsMzKb8ZCRQcxQvcB0DiIAWItBbtNxKvFtmoDmhHRJ7U8u Q+zgHyToGnHT2bOXPj97VrBLLRd3sPoE+DOxP0Uf2oB5BFKgjiCC4GBt8wR6UoC0fkDYJ8SF k4IkCAg5hPjCYxtvgSKAdnZi7L1nQYeLCOyBBkMdyTHaOFaSrpqMPToPKGxgbdYQlBQnpvYI BERgZIhqkmHv2bnxO5zjciMLFxdjmO+eOr5BPjG26aDGq0R4BzBJJEu1sF0SlioIrE16TgZV rhqOc95Z1nLptNTy1TX9GhykD3g7iGfN5C517hgzJWZzuyS6JLNJEk0oyzqXbCayrk1s0zGz ThRM8jJpg8QkyQiWJCZBks1mHRHbCCtiKqtnbUxizKRrMzxnwexhiI7BsL00E9qLS/MUtssc 6aWxLv24IKyMM8gztAIXkBoNaIByKlDxixOvJOfnJuecfYH+jKNOLE98yEZ8dQq0+DHWvQ+w PwvYDaRE9RoEUWzXG1x6vQEqxUH0OkEwgOImvdgm852SCPMEigOIsq5h/cnnG57s/IsHLy16 4TEBI2KmyFevA0tngCRGlgydlydL2zV9OlstftJBD5ghUQcAgujoOSZT2SnZjO4q2yz3QqHO sEpYbdC7W9MgYAcyba2ZUIHHMpQvYxBc0ApckOKnyc/UVtCu0rDwJMUTiDCDVtJDyeuSzyXP JBfTA/Ta88lX6cRPfkdLky9L25Orkq/iuwa7YTx2w54Xk29/8u/Jt2n4w/doiMO7EzuYSJsB r5NMUvOsu4xGShwWiFVHqyzVCAulFcJK6RapS4pLehDSCsHq4luCE4tLLb5lxxdhG3CbwEqD 1A7JqumpnfT5s59tfftfvvPGG7/cepe0+ef9W1+4IfGY+FJy9qY172Bu0ESESINsySMb1Mpm HU2z2d63Gl1Wq9FmTBOsVqL37srMBEDZAGiefqVUrxf0xjSbUGSlVmuglUgh6QapVRIlKSsH kOVfhgzQpUfCmujnAJYqnI24UWAFF2H7xoYBlqFb09O8sITzQsI4dhn6lHbdR5e+/Zett0zb duvMglmfTREM+VOnTb15wYoJZWXX7t5YXt0mtbz5w61HCgp2//PmsoYlkjm6at3CVYWJfeKr yekTVk+rWMPfHFBSM3ReaIQM9ZNP1XHvUPqQn+62U9YEU6bE8XMHYzlhRYm+Zocq8zN/m8vu crnsGYreENXBplNHo3CMUdbLHodtp2cZ7FvsHibqmV+Xne+Kuja7BIb+ZgNCGEetStRg5E9F jeYenYhNrkSzdJ4nPcc8gkfxZPdkOP3MJ7rstgOGAcNZg2DwtY12U3cgy9Ym1gYoWRYLDZ5R 3osNnok5SkshmLhh8nZJ7PVg+eC5kteDvGYZt1dKl0KzL4sFg3x/WFvB/su4ng9SXgshHqPw LjSXRpPestsFPIuaiZtfnKZxCL2we+eWj44devChZ1d8e8nND1PywdE3nn7s3NJWNmvJjU+t f/xfV/ymZ/H08vVli3Z/euDNtuTrq+duA0qBU0hy8Qj4VgfPyio5BB3UHmNiG9wFuAPwdGBT l3Fhyl0BiOqAuDOZ+UrSL20+8tVk8SVtjFbothD4L4uMVbPy3MXumfpX9NDcgrtH7yRttH+E 0mZ7zpNSV5zXyzTr0Q4218l+H8yGYsh/Vw6EbhQcI656JVQVfiJ5Ifn54+GqwlcWDbQeaZ48 QWq59PH39q8L7ry/YN0jTwnplz5+aU8sFr7ncQ0GMnRRX6PJ1HfV9i0CXczWMFYONwdStp0y F6XMJIhCu9nkMkPOGg3GdlFyiaIk6w36dp0MA1nebKbNhmYzM5hFwQi3QJId8G1NRiPkml7W 4SER3q5gMhdBvBh0ZrOoUB8togKliugTi0SIw5CuXMd0MEYykTJCoH2mpp/tpaXDbICSZmMr ZWUKF4valorF/sbSHja4U5kmpcEIMLgNENQRA0q6+15OvBpMRpORYOL1V2g77XiRwoi52Ck2 f/WAdPulKcLpS1NSNIYzLj0B3JjIU+qK1fBzGDUZTcQoSNrqdQYR+0FCzF6mJhMWqzfIOgKs ycCaDFQY2w2iy2AQJT0ziXyROg0xRoPATHpJNBBKxXpIXqNBhuOhC6XDadLMsQiEBRf+w+u0 p0QHdyRS69IrZfozOn4t69LKuJ7Rl3G5whfJF8uXKt73ReItVvNFMjfpvcAWJX52gfZDHS1N FLKKxIvsLfZYAq/qGIlCPsyCD+YnQRJXt8zOWpy1Juv2rB1ZktMb8LICW5ntWtsS22vZv8qW XzW9OvIr01cjRZvJNhKaVXggk2ZmjgjsbnJtdbHzLupyjbCYRkpYf8XY3YYKizO9b4TiMlWM 7KSSVLiT/oh+TgUvfZ97jUpmZn7HXGWZ0qY8qogKJHokBJfqFlA/pCQ+gskzWA4PMD2i2Sex QXvkjlAswx5pDWWAtBtjlO9yuwvs7+bWR/6w91qObR8YqStGNCM9hwl2mNvY/JEwO+3zV0+d PabFfWtH/bbWTZ880Xtf08u9i3KKLD/cGrtu5qQb2ZjkltD4DaOzlyxqq79x++h545/Y83Lr nMwFC5KZ1B7KnV1SCm+S42wLcDYA3rCQDDJFzVsptUidksCs6X2iQoi9z5g2y1XnYq4ORUd1 pyzM1mk5nsm1g5LYmHIJyhNhvBqiMZhbABSOAUEIJt9pT4kmeChb+m+7+9B7yT+9V/fSpP7Y ii0P79y0CuT7YGHyz2+8l/xLXjZrSVpHHOzazu2qOYAnAhqmkU3HiXnopGp1pUVpjssdJSq/ QDark6z2KFXTPVHY7RbVYo9aLAZ3r+C09RqULtJlYRYLUe32KHkho8pxg6NJ3iJvlyVHh/w8 fKvBmPJZMHxHKCPlz4BMQZ74B3EPN1APc8CB+NEVaRsJC5HtHT9PDl18bfrGBd233f7IMz2r 3zkaoeSdd6nRk/vj2h/cfd8TwOUiwPOIts/SSbHqq1YWKmvE20XRYrKl9wkOW58BKDWZO9kp DgvMk8EEN4e5y2KPRFJcb/ePZNr86ZkUuIO0R/Qnwj4+lrz9tT8M/cuStTfceM/3qscu3cot JsrefZXK+Yl0Nj145KH7rxvn02haM/SF0AMcumARNKgmJcdmi8qq2x2VOfbG2+xRGXGr3Tao K7cxs/c2+912ZlfE3i1wPdJuEJqsLK3D5ZJfyHZX0A7r8/AzEh8qSXiilw0psDVnYrAvRxpU lV+T3Rrzcl0F9Dncuf5x4GVZ6Els0X2//ejumsc37H5h42cvHvtFopW+obt1xYpW+sJde5uP lBR9+9y9b1LdEHln4brbbuN8CUsFzLkUut5NlqglBpbJEB1QnL0WYtPpDL0itdiJw6pC3VtV oylqtersnY5m3SHdjxAccOlcxHES8YSUTxhTACsorEAOYSdi78Eo1pQamPYqxZpNI+4AdFyg uO+f7yqdUzB6zYL9+/vvEnZH3/uF44hyy4PR/Qkzu7Af8Al4kx0UluItdy4ZT8ooU8fd5n7c w6q9q7xrygTnaKczCtvDHnWMtjujeM0fZlutLXbmtU92ilmjLAWcEGaHI1rQexvMWrMQHRj6 uTrR4YxGe7M8cl+eira8XkFBcMcQ8S7wLpp87ySZQAhH7c7JwiSvzW8ZNUaSQh0Gw6SBobfV KZhrUgdJT0t/IH1f+o/SpfT0bFvHA/59MIT85M7iB4tZccfc7J3Zj2Yfyhazs6eM6Sgi88Cz z0/ZOZXGlAsxzWtGACVFWtA3GOF+EbQVhBYkd5DvlyBYNahRPxjhwh16nGzEzoEAcyLo6ncH UiEWHbdShsOWKWGmhf+ieZRz9LBkEHjZzyMxefPfOUFvPzFx7Pz2XTdft/Kp5fkVn5x+6T8/ XjJ32qt04azGVXOuu7lxy5IWSrZ0HmCLdj1zf3TRpBk7ZqXZSnxj0nLH5lc0dOz97l3PT5w8 qWCGfRFd3VA9PbZs+oz6S7+cM+X+6deo12s81QrCdWB/OkmpGrCzA9YBK7P2QTvKYpqYB8Wm GJ0OY6fhhNvOOp3HNfMcgQ/usMbKlcEYl3MpKYdVglEm8A2qswda+295asmD0/tvur6sSeWa 6ekdSx7bl7jASlfePnVGYh2XswgD0GslD3SwjYRVv9zmBZPbHGab0GYwWDuITbH5bL+2nbdJ xKbamC20kSsR7siCFJj2qkihAP/p/UJVLRyrqkX9/ZJnamGBek1w7DXJ1kuNmGvoy2SQVmhz uUi5Osrep6SmUzxmm6KALV3Dk7oUl88lECi74emwTzJBXtgnfFrlw/82sUuXDwvtXKE6ZVyw 4pqC/oGu8lmSp7xg3FS1gAPw1Uef39SZtn4m8M1Iu+YTcR/ZQG5Ry2F2iJJ4GkY2PGUYUuy0 RFwSLA/C/iwh+i2JwIhMYF8YHIzwgItgkiR9p+G48U8mblBz35brVR6UjYAqMCu4b5sZWhaD /cBNCmnYtNDzOK1mQlCOLfbOu8nN9N0LyciL/f3C7uQUIOicsG84LkA6QRsexxDISDVd4JKn gwiK4BN+LZwHdIIqIAwNelyJKnQC61pUAQwJ2+qIcJDkkHvURVEboslup5shJi+k22iGtdbK ZllpJjM5NlvpZgO1wn8XddkVcp+rIh+RH0Ux2zI7M7ggy4DE6qS8RE+aLMZOvYnmm6jpuPdm X2rxsRi07oVgovRCkIOyLAaTwp4eicVgYXELMca9BXgN3Le+zJr2iBtKOR0p7TLHCpuOzV9V umxKf/+OzkP1Dz569w/6l9ZuZHsTDYw8vGVCRaJB2L1lxxMHzryS+ID5N20FKcGq2t6BTnEg Zu6lfTabpU8W0oQ8RD0Uh01vdxg69SdcROm0H3dq5sElbd+Ux+BCgH8pB+PrXYNNY6fRrf+0 8DvX9S9c2b7ohLC7pavunw4kvmDm+7a0JzZAsjJy7dB50S/s0WIAxeqoVWS1zMy9RHH0ymnF tkma83+DbZFbdncIL2TaOgyaTr0SquRORpiHRzWVTtKvEj2s9E2alvzt/3sj+Tua+ZOOAwe7 7n7miLAn+fvXX07+hZrO/oRa9h/svOvJp+7qOMjXj/0LeQ8oAUuaZieJLWKnKFiNSh9cHI+l j9pmOeuczNmhIEB5ilhNneQ4rI2r7aTBlI53wsWH+wao8rmLnxKG42gLLf8jtSeHXq5d095e s2Tb96/rTAaldRd++Ubyy/ykSzyd+EnwyL2LurWzWYzMADw7NHg8ZJzqMYvpfbLT0kcUwWMR YWFUuxZyq83Atfdg7IqdoYHAHbmUnTMKvDKSe2EpoVxOWYTW9m+ef2aIUCPt2HTb3EkZs5+6 2zu60irsvriLfuSj+lffSSbSmOrO9dzQet8P9emQn+CP+yBbC8EfXLp5xgrU4oC9CEWt2Gw3 ynipJ9uJpdN6XOEowRZeBm1SPhgOh/hbtBh1RzmX6jSDh7NGpfGuu25url92fW37MWH3W8q5 xn2LDmxKerFgzIU4ADuNuQLkl6q7JbMzm43IyjptMrhMJoPfZrFGKVevmWYlmqZk+vOUMf6J dKJS6q9WZjsfpUZlYOhLNc2KbvQ2E90CX25ElklUxD6/08kfrHC4ok4VAQCn092nKDoXzKcR BnSx2JzUqWZkoBXq2an6/eii6yA5D+V8P+enOWJ5DuXfjA4LhvkhptfyQCBqgfUB6odSUhb6 ciNXqNwWQQOCyFCkiPcHeQzAOi6oRVZILFrMjSquHb/B/x9+xVVz3feipfOLa+PrHr+z6/7H bi6+ZvKsa357eMf8bRVnJk4ryR9dHF6xY37T3dceXVGY65s0JvfORzb2wOWHWwscHhAXwr6a qvoodUm9CN0a9b0WZ9A22Tbbhn1tNKYzqdPpdjvhzika2eDWcahh+CEqwA2p8UV26uahAc15 AVNpznwAR9ACyX/rWLFu9R2tC7JGpu8TZDrvxf3JKY9UPD15Zlq0rpWCkppcgb3fDrI6yXi8 haB2g5gpjhEFg83pgGp2QqA4T7hNnXqujRHM4/byYHl5rIzrYn8x95ZgcPLoAfZRFDl7dVLv rBt3ze5f0Hjn4v6W8uobe3/AbIk/9GxqYw9y9Yi1y5hzC+aUyUa1AiEfR5S/iT6dihJwR/i0 KCA0IDQjyshdYyf0kiTaJBzmZHI9xWeeXC8zWRZVsIYYCkauOPul3LvnIdfyMphNf+PUU24s w4enESc7+lKyaUqy/uU/C7sv1QoHEj9J0UQ6BbjM5BN11yr6MGMTDBPM60SEth2IL0Bpmq9A aTKbhqE0Imp32mCEbWjksYzTqVhGM49lUB7J0HHfHkvgnr0tFb/AI7JeR7Qoho3bnyKh82g9 /TU9j7criLDOE+vFX4vnRYnwdyEbdJ/rhmBXa1GNjVfCGhthK25EUIPHNbRr6tWhFuvVos1/ s/zLLxG/jmnA8b0S0/AAK2LydLKpNPl58sLk5KrTv/9d1yccO6w90QYMvcnGJd7U6IeLSIAn E9mjLrkqhnElqiHCuBCojLA04hkIbVFZPp16B8qjGadT0QwBYQxKjAYbNzUItL0qzBOaub7n kQyDIF+OZGDFMDh4HAMWB8LYqffAw6vR6a8OXiCcoYUwLlsfwwEMdumTZCft+yT5fvLzj2hH svUjaocZMjlZSGcl++lb9KXkGU5/yHS+F3TkVvUaxKMQnYKjgXDNadhogkDAkjqshL8qkESd CNPJA2aWbCJITOrpPh6KmAexixiMLEg8DDPMlxFsjNQCuL2kxW+7YCJhJanXuliDBrEWbgFv vp5oeRVx771vgDsv7mJ72FuJvwC+dMj4KRp8UTVb5nBJMkCRWa/kkHspjlmAeQQwisRNNAgN zMW36+W3yDyKSCEsqD8oOBCI+PjSL+hvkuOF3QnH0+wzUBVzrKMvsEZhALS194MIiizzYwl4 AY9jBNzFuGwHr+ttbPpO7+rGXnZide93mlb34qUK19OVwm4hHX6jA9phiuq127w24pNd5qy4 y+UTEagSDYdstly/PxBIP5QdSpSGtPdneHvMTysg4gkaKzCnSkoo3FnN+758mmAqla5MD7cx CruDXRpVIIZKqiZcc31pfXKqIbe0Ynx5Tev6eVLXmIxlxVnpQvn4cGVTzbRvz/2oujBc2VzT 9OjIoMrFEGCtBaz5gJW/g1WPk6yhT9Vss8dDK5S4nCbCK6TUcEgQvJkjRjgVJfOQc/hUBY8i XT5fUZb4EKc2AC8t/vqABUJGucXDQWN+cKR4ItvRNG2COrdt3bxkJBStiJbP+XyuuCXLumZi VePCdft9edWb06SpRWXT19z4y/l52kFwSmCF0RYNvhGqxRiXuDSAUa47ZEnhjeNLs+1gPvAD KhD/gIEuXcjWzJwAv6DLu+xmi3Hk4nDlyhs+Bm3nCDtojTZePo5FQ9PaJ05EDEeMGzDu35wb gdkIaen8nw6OCDvyCxbOHrk8OmdtTfNTwKUHvLkZY6ejtFgt8jgkB/wckmGThV4Dsbl6LdTe maVkGc7IOP/ARE9nlkHslHVZWToFYj4VKVAGyxArQMyujCiDFGYKbFhEqxEr4CjXTvxciRFE UqeM0gM8ymF3Sfyl1qLXX+/fvv0nzz8Mj8Azp/xVuungQWHP3gRjyb0575/fu33m1ORbiuOS dmYE+53v+XcvdfzbMlvZH6lHz7mCvJx2B9aSyvkbS30NP0ABD4r35x/kutrkaJx9P/pVS/Ko fueVllQ7IaoeVawULBYku1kfzor3kUzxILmFniJzUJ6PfBUrJxLypdJCUKCd7JGeJg2YaS/M uT3CKbJX+pQ0SufIHhw52cvIUIfwKdkjl5M+pH1yH1kiushO8RzZBzusBnkAz7fqMRZyUWgi UYyzRWgnc9BvkXCO1GAcB+ohuUkr5m2hp4a+RH07yp1ykGzh9WITuRZ5C9IMIUjuE1x47unU MxhLhmHNnycoE2EhSWfnyDqMWYlUi3E2IM1BO8dfEb5rcaLgNXKJ5tFJtJbeSfuZg21jvxBG CfXCg8IlBOxrxK3ibvFLaax0p3RSniC/pyO6Ct1P9ZX69wx5hrsMZ41jjVtNNaYHTWfNZnO9 +dvmLywFllssJxA4KLH+wpZjq7XtV0qU/coFe5692r7X/qnD5ahw4ESBRhWVLIBXWQmgGU6R hXBWn7CD+hzUcWryKBfPEYCA3Uyqa2tmXLMoOH312rULlq/X/i4ApPHP0CqisUzq7qqrijL0 AqSlGVLEhjkQFoM0GYW4VB7JJ6PJGJzhD5ICUojZixCrCuMvMMVkIomSEjKJTAZsVaSaTCcz yEwyi8zG/wuuI3PIXMSGrifzAX0NuYEsJDeSWlKH+OZi/NcgRrrIUfIc/nlwjJzkf4LYhyN8 fUH1aP0bzW+w+tebX2fK5/TRz2jRZ4c+Y2SQFn1MlQ9p/at05yladGreqeZTgnKS1p9sPslC z5c/P/d5gRxXjjPbMe8x9vuOgPd8h8v7UUeR9wOk0x0N3l09YW9vX5n30b5DfT/qE7o6wt5O pE/ax3sPteZ4X2lr8L6M9OI/W7zvt4e97Si3toW9HW0jvM1tVGmLt51sE+a10ZxvpWVvThtx W5qnJS3r1rTMTWnNaQN6omZkr92Qlj5i7YZ0z9oNmWvWp3nWrG+7JavJxRuHsletdrlHrFrt 9qxanbmy0eVZ2di5MevhaRf9DyHtQupBug9pB9J2pC6kTqQOpHakNqRWpPDDS/Teh2J6by/S LpR7kO67Ue/dgbQdqatW7+1E6kBqx30bUivSTcv13hVI4dhivXcJUu1CvfdGpOU36L31SOHF uCxE8kTdGRPdeAPnmOC2RdzmsNsw3i0XuYWQm4xzFxTaxgato8fY8vKto3JtIwNWn9+W47Xi n0eWjMwsC/6IZMEfkiz4X5IZf08yG4wms5qDvy+ZBVHCUSVm9kzWe22T9F6hVO8lJXrvvAiN O2aT2TUVcSdFvqAiHgnOBt7mx8PB2XF53uLUYWbUxtk9OMtbExfvGWDIHNMWLa4doJn8rHOn 9m+D43iNtK3zPs9wXlcXzI434CxvvDm7Lh7mhQey6wiP0/+9Dw1qXWgwlQdRGP5806Nft6JT PINPU5HqftjAF9Awv6Ll1k2XR0B+ubwJn1vx5Z8WJEL+Cwy9UWUKZW5kc3RyZWFtCmVuZG9i ago1NjkgMCBvYmoKMTAxNTUKZW5kb2JqCjU3MCAwIG9iago8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL0FzY2VudCA5MTggL0NhcEhlaWdodCA2ODcgL0Rlc2NlbnQgLTIzMCAvRmxhZ3Mg MzIKL0ZvbnRCQm94IFstNTY4IC0yMzEgMTA3MCA5MjZdIC9Gb250TmFtZSAvRlhUSEFaK0dp bGxTYW5zIC9JdGFsaWNBbmdsZSAwIC9TdGVtVgo5OCAvTWF4V2lkdGggMTA4OCAvU3RlbUgg OTAgL1hIZWlnaHQgNDUwIC9Gb250RmlsZTIgNTY4IDAgUiA+PgplbmRvYmoKNTcxIDAgb2Jq ClsgMjc4IDI3MSAwIDAgMCAwIDAgMCAzMjMgMzIzIDAgNTg0IDIxOSAzMjMgMjE5IDI4MSAw IDAgMCAwIDAgMCAwIDAgMCAwIDIxOQowIDAgMCAwIDAgMCA2NjcgNTYzIDcwOCA3NTAgNTAw IDQ2OSA3NDAgNzI5IDI1MCAyNTAgMCA0OTAgNzgxIDc4MSA4MjMgNTEwCjAgNjA0IDQ1OCA2 MDQgNzA4IDAgMTA0MiA3MDggMCAwIDAgMCAwIDAgMCAwIDQyNyA1MDAgNDM4IDUxMCA0Nzkg MjUwIDQyNyA1MDAKMjE5IDIxOSA0NzkgMjE5IDc3MSA1MDAgNTUyIDUwMCA1MDAgMzk2IDM4 NSAzMzMgNTAwIDQzOCA3MTkgNTAwIDQzOCA0MTcgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAg MCAwIDAgMzU0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA0MjcgNDI3IDIx OSAyMTkgMCAwIDAgMCAwIDAgMCAwIDUwMCBdCmVuZG9iago5IDAgb2JqCjw8IC9UeXBlIC9G b250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0ZYVEhBWitHaWxsU2FucyAvRm9u dERlc2NyaXB0b3IKNTcwIDAgUiAvV2lkdGhzIDU3MSAwIFIgL0ZpcnN0Q2hhciAzMiAvTGFz dENoYXIgMjIyIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZwo+PgplbmRvYmoKNTcyIDAg b2JqCjw8IC9MZW5ndGggNTczIDAgUiAvTGVuZ3RoMSA5ODk2IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4Ab1aeXxU1fU/9+2ZmUxm3zKTmZfJbNn3hUQyxKyEREgQEjSaAIGw RAKGIFRoUCgQkWoViGLdDVuVIaBORCi1KLi0YmtdqLW2orVLan/9oT8FMvM7701IST/9+fOP fjpv7r3nLu/ec7/3nHO3BwQAVNAPNAQXdHf0wFkyBVPeQPfagr5e191/nPowABkEoJcv6lnc rf3op68BsAyAQrV4+dpFQ+te1AAkoNO1d3V2LPzv/mnlAGIPvl/YhQmKZD4d4/swntLV3Xvb HOCMGJfqn7l8xYKO9Df8vQDJdoyndnfc1iPcpvga47UYd93S0d3Z1L3mDox3YTy5Z8WtveRF aimS2zE+vWdVZ8+Ld96Sg/H3kL83MY3gI/1UwMEJDF0wbzxFTp7kUeMxGkMG2KvyuKvobyb5 q7KFq+jJZBwoMEGJXE3+xWNULSclACIIWtDJMT0ifBI07HHws/1gY7LACRB9H905KYxcH/2U PQ2aSHf0v+hSfGNEclSkvAxOwt2wBw5h7/ch7YebYBBeJUthhNwIR+EdkgSZONYMhGEGvEGi 0bdgETyJ5XvhJdgJh5FDP3SDEXN3EE90HcaDSM+HTdHHIQWK4XtwHEqw1h0wGt0fPYK5TXA9 HICD+P7rxE0dZvTRZ6LnQYBZWOcmzHkrOiN6CPuVDhUwE1M3wQnioc9Fu8ACpcjdQ/AIPAY/ gb+QO8jRaFe0L3o2+jugMNcOzfisJ0fJ7+hDzPeiD0X/FI0gEn5IxVbb4T54Aus/hM9JHPYq soz0kvvITipI3UEdZTaz5sgY4hCAGnxqYQVsRQRG4BT8Hb4mn1MWWkP30i9HC6L/jSNTj72U etIJffhswWcH9ukY4Ug2uZbMJOvJ/WQn+SWVSl1PtVBrqNuoT+lG+kZ6Lf1L5lZmmN3ODnLK yBfRY9HT0V+BGRxwA6yCDdi7l+AsXICLhMa67MRDSkkFuQmffrKHGiGPkRFqJjlJzlIHyG/J x+RzcoliKRVlpNKoXuo+6iD1EvVzegm9k36A/i39BTOVpdjH2E84D//ryPzItsjPo6XR30W/ Qu0VQMSRqYBGuBk6sLc9kA/fxV48jc8hHLVT8DK8Kj8fEzuMwleIAhAdsZFc0oBPI7mOLCJL yMPkBXxOyLx8SeFAUHGUljJTdqqZmk91U/3Ur6h+OpFOpafT8+hD+Jyh36Ev0ZcYltEzRqaG qYPtTDfzID5DzD5mmHmTLWGnso3sHLaf3cZupxewb7HvcBu4Hdww9zn3N97Pz+BX8NtxdF5F mf2JrAFXPIakIPe5cAssIJVkPuzC0XiMdMAAStdCshXx6gF/tI3eQNdQ2SgNJ+A7KK0PwnrY Rt8Ij0Xfow/Auygpy7HCftjLVICD3Y2jcwdkoxSNP8FAasDv83pS3Mmiy5nksCfarBazyWjQ 67SaeJVSESfwHMvQFIH0Knd1uyvkbQ8xXndtbYYUd3dgQsdVCe0hFyZVTy4TcknvdWDWpJJB LLnon0oGYyWDEyWJxlUGZRnpriq3K/SzSrcrTObNakH67kp3qys0KtMNMn2PTMcjLYr4gqvK 0lXpCpF2V1Wouq9roKq9MiOdjAQRDkVGumQ4gqCUKg7BtR3ruywYSCWqQjZ3ZVXI6kYa82hP VcfC0MxZLVWViaLYimmY1NSCbWSkLwkhn3CXaqF74V3hIMxvl6iOG1tCdEdriGqX6tKmhczu ypB53SeWf0SvUFXbr8oMUZ7qjs6B6lCw/S4EV4q2S7GO7Rirb3ZhtdTm1pYQ2TzOhMTjUuRU YrfTXSXx1b7UFYpzV7i7Bpa2I7jQ1DJsC9qq3B2VrSGY2TJsDVrlSEb6iGVDqYi9H8mYljFN CktFy4ZY+Ic7Y+m/OCmFlg2nPsKwvmkCACK15K5DPkOuBXIjbmS2WPI6i2FgQTHihL9Wgt1c gvxcG6JQZmhPiPXUdYT6m6+w0VUZY659aeVwnNUm9aG9ohXLtw9opuBIYXmN2zXwBeAQukf/ MjmlYzyF82i+AClTGugJWQmRjit0nwwM9rrL4u6SxrdPHlOMuy1VVyVgXIJG4jlkCOXWz2wR Q65WTAhDWnp9GOJmthwmZEdrmEQ3h6HSMQJxQN98E2anS6K2pBLbx0hGOiakikhlpruqsdfV kqy4BlwDdQsHXNWuLhQmxiOHmNE50JqFCDa3IE4wG1sMtiZOkJ2trVOwniypHnwFiw+0Yg1L x2vAUE7KGsNC2en1OCremS2zWkL9lYmhYGUrjgKK78mZLaGTKLmtrVgqZ4JT5Hj9Ess4z7nI c04q5ufFamnGOrCK1oEBqc7mFrcYOjkwkDgg6VssHibwzwnB8YQwSEWw41Vh0j8T38XALSZK CW7RLSJbrRKm+SjSVyQqDAXfjHDhBN/4ZhFyWygjXPxvQrjk2yA85VshXDrB6SSEy5DnUgnh a/5zCE+dhHD5NyMcnOAbmZyG3AZlhCv+TQhf+20QrvxWCFdNcDoJ4WrkuUpCuOY/h3DtJITr vhnh6RN8I5P1yO10GeEZ/yaEG74Nwo3fCuHrJjidhPBM5Pk6CeFZ/zmEmyYh3PzNCM+e4BuZ vB65nS0jPOffhPDcb4Nwy7dCuHWC00kIz0OeWyWEb/jPIXzjVQjjgrcCt4Nnce9FAw/lYWhO C4OQhZMfOkETBjiLToojTX8QBgYdIM1/AC/gGwBz0l7AWlgMs3PytKLWh66C2RG+/Hv2+MVr w0zDpSNYisCByFnSD+dwB5gRNIFbrVgoKDRms43PVywEwZqwoNOS1qi50FA2NtpY1Vn5KZQ3 jL49mpNtLiwqLMj3+twFeUYDxx+osicQqvud9r63VNdnpPJK/txra47iJhuQi2D0fcbODkIC 7qZWBs1bWFItGAsSWHsBH68rpldYipVJNQ5N3ynL26Njo1A+Wo4NXLs2mA+J8V7isXnjPKzX pLb4wQA6P0kUkNJwSJlVRj/RU+hZFXY/aBn00vBHJE/+bYQ2MJu0Gp4SXT6vNr9IJ+oKtfmU O5nSGsymPDp4e/vcDZHfRyIblpT3kYKBoduefuS+rNpn2MFPDkfeiHzw48hfPzpGSi8cItUX P/mKNF0gpZFfRX7z682vS30juHIFJon9ISTDULCxkKlm5rLLHLckrUvaRLZQQqowz7rMerv1 dvuzVhaSSQJjV1tF3m5lCLDOhIRkvaJAz7qcq8Vklfhdvti0IlntS9joLE5OqXHHALkwqvli 9DyUl42VlY9qdSVZOnMJwVBXUqJFD9pkqOyMVeXRepU6tR/iDDwCwsRrFH4iGNFDTDQaGROE o1BXTmJj507mOd6NtJirMxp4LoFwmCAaxembf3JyY37TrvUjNV7mebpiNfF/+fHa6me3zS9e aKPVlwMjRNezor6gedn6+7bXbz7Wdzby5RM/WlfTOaMwZ+7SAzIuOTjmNvZByIFTQWedqjmj M7AgY3VgdQa3y0vqhTSFJc0QT3+dYyiIx42EO2jQFmi+Gx+fk1iQwvIFOfGWXb5KbZhMDyYo ijNXUM6AayPto/Jqcq9CZfRCTFgQlAtjn2pGNRI+EjYyJIVZ2VYvxLFehyfZywHtB4YWshEO u9vpB5vH4icM4RGuLPSSxETEzIvehABpyiQJ2rgRMSNtDFWQZ0J5yZWE3p3M8QVJJC9XVoEY jPkSjLhbQwSTiNEAbmL65EWVv/r5HT969jGdR2/3mjqnrRrsPFrlZYeDtxDjr/9Wk1698ruR v3/lI+Yzd5WvHLzt/j5CHqEpV/E9y3pvq1j3aM+Zn45saspzOA/3/ywSkeSNgrroe4wWcU0E HxwMZlrZNNZvquVa2C52m3WrbdAWVy3wos9XoFBYxAINyxQknrbE81QZn5RjCJPrg8p4CCRu TCmOD9T4/4HlWMn6+qbb1mVZUPtQ/RBRCcuYFjq9VptST2idh/ImJ6T4waVN8hPaimcgXiVG 3WrRT5x69IiN8YNH5ZukhYjgRtJGYujp1QRVryBfl+fSm4ySWiZ7C2AcVKPBlEc0wrKiqo3P ecsOL3rzv/76GSlZU3HdnZHTvzhH5R5+5Dub9mzdSebtLEl6l9Td3ECo139K/JFP9/wx8vXr kWc+GCLeu0MP7zl8//anJKwewhOsVLSh0slXX9BQRIo5iidm4iM1pIVieUJRYbInaNZxHE/x Ak0ogRMUtEJBOIGipbxnWcam4gWplCIOrErVo2JfjyUtrfFCWcNYWaPmSylAoEpKsqC8vKy8 DElmS2balvUv52RLcqPPI9o8rZvg/6E/U58e/+1YwglqCnv80jxm6OK1zFOXbkD+JDsioh15 FWke8oM2wiUBTzFCHBpiuETRHpa5xFmF7TfFbPEFtAUXxq1xucRBTjYxilq3VixgXo1oX4to 2eOHLv6dVR+SZIaGpugH8olIAp51lcFvgsWp2UShUSaq7L68Ws2SuKUavkTQqeLoxFw+Jc6h UTlK06jMQOnzpVRpbqpHp+FZwe5LNtvDZCDoNjucvM+RqaQcBcoyvqzMbuADqftSbFMTA/bp Cb5i6zVTXyS7sUMjZBfIWDWgoiJWDefHTqFgIVAoYShmuhIt2rI2hC9zNHNU0lutOSZy/sIi YzIQq4cUJohgSUoUweQyiERMhiJKBJvDLGKH0ZOUlUxS1BTU0aLCa4iayObMOMnWTUWdxSMV LcpZLjYhyaLP65MCb0F+YZGeqFc13ty6S+zK7Z6f00yOTjWq7lx3d6mo2Mf+zxPH+1abPaok bWq6ty3VFFf089t3Hn9h98Cb89Lrhu412jl1vD1rMVkupFsybmyekdr8yp7a2sGx3fZkmt6s 4ircwdqlz27d+aSenJdksy/6IeNhX8LT1iToCWYO8Xvt79rpZCEhicJDYLOD5bWKJIdSafAJ NpctU5NJAqC1Ol1bxONtVwTw/HkJVdkGIqBanA9khbXoTJzCxBm8RKdAz8ibvUQfl+RFsHAS kOyZPk8rQaHTGnAiRASM7pQJFUQj13eo9Mn2M19/eW7d7NySIWrRvffe/Z0Rb81L7Etjf26Y FRmNXIhEQqXuhm3rPzux/8Pn3tp902HZNhVHz9Gj2CclOGBNMLdIXaOeq97L7E9kPYKBSnBo QHA4eL2CcpiVbKY+UxPQ6mxOpc9mTXJuEVdVjAtLTK3O45w3KonKRL9sFnucAgixKNGs29ED K+UFRaLgxW7JPcOu6f5ho40485sl7SuQRhgko/PlDx5b/9jQuq37yUBz9jVPP17+oxVHIhc/ /5Dc/Nm7r77+07OvUUX5SfWU4+LUnQtaSMbFP5G5qD+10XOMDU8U7Xj67CGq4NrdwgO2vU6a VVMJrMGo1iUYDUFV0CAEbKRe+Rx9mrxCn058T3g/7h3ne+7PzJ+5lae1p3XUjQIrpiQ8aHKk lHA8bxIddl7hMCk9/G77XvvzOP6Mx5TgsbNWhYrX4jrA4WNtvpRM3me1en1vi0OxgW8Yiw37 22PyGgAtDipVW0yrkELbIM+DsihUg5thaTyuJSzDOb1ajU6j1xg0DKfyJCemePFmwuElSY44 M+8FpVHtJfFqt03EJBY9waLwAq4iEGhpJpT1TNa11LTUjWRlG6xsawM066hRYmw2LMpTE5wA OURbq4E84vXJcyWhjr5TXKjTXP6cvWf33bOzDYf563Ka1k5rOhP5E7H8njiV/ulP376PJW6m Ztn1s5ZPf/yJl9sKa0rvzZxp1xA3nllTpCLiXV19x5EB8oFk0wie4APnYWrAC5uDpbzAq7kE s2BWmxN8gg+hq7XOUS5Wqtwehc3htiooxuwRHWZHPMcDl2j30HqFH22rNoBTIhm2BRwYBFG2 Mj0BL1h9/jCJPyLOjwkkGtjzmgujF8bGLa65DC19wyjOj1cWYpKp1+cZcSUlmRfzFSvj1spL BSMa5nwZCKQ2DQfzW1f2N6anlD3e+V5j6rFlDUsfeN4W6Fm09yiTNXhdyjXlKdVzmh+avWOs iPps2cwdQ2P3Use6c+sffnPsjGTLS3FdJTKNeCdiASvcE8wbFHZpHjA9xewThjT7TWHhjPAu 84n6jwbVFIFzWHiVQ6e08larkfIl2BLjfEarLTFM4o6Iq8alSbbM0oQfkyBZbNLBzHiV+jgc eS3lJbwZKTYeKYVB5QWiQU8wcV5Cq9GTZUPy0lD9UnQF431FG6tDKcAJHgpQFnjqo83ZM154 ateuJ/AC6HLkf34TuUx0f+B6ScLQrpvuvzx88Dx9LvIXNC1jkWdI2mU04EEWx3kbGssf4Dhr 4bqg10d744voGoZRCxpKHaeNU/kEFkdUqxBseiLZE7Dq9GFShYO3YcJKNmpw11LeUH5q7JQ0 VccWiPKISSNlMhsz0TxwODjbDhqfXMZaHJpEzdYf4HCMFO6h6BM0dWjV2KBksyui79LPMfV4 e5VFMoPfL44bZHfpHjAMGgdTOX+Kx1coVos1KTW+OSlzfYtSFnvXqtbGr1X3uXtTej293qGk fel6GtWMzWAy9WAzJprtFmOGIdOfoFwieD2FHsqTHK9g0vSWV+wOPc84Mh9MU2bxcWoNxUOW mGVzWkwWn3mq38v7/LYctdOnmQq+TGt2zvCEbUAxLZEmhbESDVKxlYk0sZaUSMMrzbqS2K6U R3kGyaC8RtxeiWqnCHFeXiR0Os7bbCpSDh2mJRosInElJIsgJqvjBZ9CJF5PnIJkMCJwAfSS tHaRWE3oySZCU4b2QfZkqbgiFNI66Mri2efNkswCTreSrvDumIkw4l7MKS0RcS+Jk7GPfC54 KvctHLzGd+v3t03r/fXI35ddSx1gvVMfWLSkyt+45qWKJe9/+PlpnjxPZs7Lnjv3hqoUtKrJ qXUbB1/cMa/rmtyaxmB1qlXvyEqvuv/7Z99/lPoax68/+jH9IdpxM+rOTcEpYcMZAxWnFwxW vdXg59bQ7/K8AKxaAVy8gkW9sfAWi9IUn6kIqJQ2GwmYrFbbL66YhQZJcSTbgPDGdKe8TAI8 tu4j8u5S2iBIE1CRbBOx11oPKbZl3/lipefoAcqdv/i+T5ozyCEma6ykKb9937wfUupLbz18 TersB5q2Ue/ZJDunRKX/E5MFaAODmRXkZULBYuiiuujF3BZmK7sX9lEC3ixSVcx09nvMNvY0 c4YV6vy3+qVVK6r5YkkP6pvWhqM9R3EScDFhcufzNN2towjFIh1M4rhuvPAlLMfQhLAUzdGA 90wKAe0jfYh6gaClJZuOkEOc1dp4wdIw9tFHY1bZFOJeoazcjEve2HaUb8hM0zSeb+BjQVr9 rLVBDxXQ0TQDAVxi4xw0qXKKoQ+hhk/UW1IyVlLyTzWzvCYN/7i+xemmbaU+juThfPABSSJp L0eWn4ysZrIuD9Jdl95ChCgwRuroz3B8Jcv4WvCWAeNWy14LzXNmrlhXq2vRLebX0Gv47YZB 2M0OGnebdpv3wT6TphbqjTXmV41MJfsKS21hh2CI7GX3mdkUP2sxmk0EvxZQKRMcgloypKZE BEbi22y0HFJ934T29O0YyghPw3kLduIf/YiJBmpjrjXLUl5WJu0PCI5GUGc0gsnUrTObLSwh 0gBYcNugWX9KDgQMSRtq6UqC3SZ5HE3xlKwY8razsGgqKUIkaFo87b1zfsVD/Q95A0lZqZrc LA07VR3pfYM4CZO1OHJv5C/PRBYd5YQn4znRItyfwjQiXHdIciX/vp56cdnNCWVfgDb22cBp 0+2JUoYcKiN1nLRCBdw/jZeXQi4QCeCnDeSrzsujynsncuT60DOwOqigStBclsAB5lYIjrsc DOvwe4GHmI9BRLoJXR+6YnS13AHYhGEpdQC2MQAVSPdjqEQnHSHl47MI3ibteCf9OPUV7aX/ xsxjXmHv4VTcJu41/oDACA/GZWNJiU8D3jvTsAx3UhR+z6DBAyDgP1Oo8HsDKZfgVwCx3nCY B7WzGqqvn55W27m8r7N3yYIOLEGhw1+0E+/h/9XPgIk0nmXpkTcTrglzoAgqoUq+358p39/P gRZohRsBP3CQzu3q0JWjK0CXljbNAv1kCO5B9yg6GpaQu2Atum3oHkDHTFD7MTZC7hpmhOAL ZC3Y8DREyThnG6xOi0Lp/EWYcEcfdr5v+fgYsUI8/I5Yh+MhbpqCPEoegYXgJE/hanUdfnXg Jw8eCSx3tmPWfuhB14+Oln1C9g8n5TpPkHTw4JmUk3ghiSHPOf+Qk+H8JCdMkWHnS74wg8FP kjAWTHCedDzs/LFjsfMEuoOxrAMBLPGcc79jufO+pDB5cNj5A2lBNey8NxasduCrzzm7A7uc C3Pk/Bm7wtTBYWcJ5s8JKp2FxaKzwHHemeULCwTjGY4ZztScnzlT8EUs5sJKPUGt0+64zzkF s5IcVb4p6I6RA2QPpJI9w57pzheQxO4eqQsU7wqT7xyp9ed4wmRdsLDWvytQ6/MEZjg9gWqf D+k5Z/hN/A38ND6XT8OLf5z4+ETeIOgEjaAWVIJCEAQ+TH40XO7kjpGDUI6wHDyCRwNoL5/B ROYYeVpOfPp5FDxKAMEQjn50VJItXE4ePIpiRQCJ5ziZ4sLkaTxrlZKeDjpRpAkwcoYGJY3I 4oYCSRGBgul4w3p3mIPNpr5yS7luqrakuvL/8trlnCu+PNX+a89CHKFdeMcXOuBoxetUJKKO 1itFcXL4f369q7FAZ4U8iRzp61m6SL4edld1tuMtceiuPryu75/vch1e2jN+9+1tn7+gS7qf 7OgM9bg7K0NL3ZWuw33ye1LyVdmLpOw+d+VhWFQ1u+XwomBn5XBfsK9KuiY/Mr9iVduktrZN tLWq4l+0VSFVtkpqa7783j+11SZlz5faapPaapPamh+cL7clQVC1pLni1l6UTrxCxitcf3Oo bta8FvxSorUyTIake+XV8L9DUc7PCmVuZHN0cmVhbQplbmRvYmoKNTczIDAgb2JqCjY2NDkK ZW5kb2JqCjU3NCAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0FzY2VudCA3NzAg L0NhcEhlaWdodCA3MjcgL0Rlc2NlbnQgLTIzMCAvRmxhZ3MgMzIKL0ZvbnRCQm94IFstOTUx IC00ODEgMTQ0NSAxMTIyXSAvRm9udE5hbWUgL0hRTUZVSitIZWx2ZXRpY2EgL0l0YWxpY0Fu Z2xlIDAKL1N0ZW1WIDk4IC9NYXhXaWR0aCAxNTAwIC9TdGVtSCA4NSAvWEhlaWdodCA1MzEg L0ZvbnRGaWxlMiA1NzIgMCBSID4+CmVuZG9iago1NzUgMCBvYmoKWyAyNzggMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDI3OCAwIDAgMCA1NTYgMCA1NTYgNTU2IDAgMCAwIDAgMCA1NTYgMCAw IDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDcyMiAwIDAgMCAwIDAgNjEx IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjU1NiA1NTYgMCA1NTYgNTU2IDAgMCAwIDAgMCAw IDAgODMzIDAgNTU2IDAgMCAzMzMgNTAwIDAgNTU2IDUwMCAwIDAgNTAwIF0KZW5kb2JqCjEx IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0hR TUZVSitIZWx2ZXRpY2EgL0ZvbnREZXNjcmlwdG9yCjU3NCAwIFIgL1dpZHRocyA1NzUgMCBS IC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyMSAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rp bmcKPj4KZW5kb2JqCjEgMCBvYmoKPDwgL0NyZWF0b3IgKEFwcGxlIEtleW5vdGUgNS4wLjIp IC9Qcm9kdWNlciAoTWFjIE9TIFggMTAuNS44IFF1YXJ0eiBQREZDb250ZXh0KQovQ3JlYXRp b25EYXRlIChEOjIwMDkxMTA0MDAzMjI3WjAwJzAwJykgL01vZERhdGUgKEQ6MjAwOTExMDQw MDMyMjdaMDAnMDAnKQo+PgplbmRvYmoKeHJlZgowIDU3NgowMDAwMDAwMDAwIDY1NTM1IGYg CjAwMDAyNTI2NzkgMDAwMDAgbiAKMDAwMDAwMDQwMCAwMDAwMCBuIAowMDAwMjI1NzEzIDAw MDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwMDM4MSAwMDAwMCBuIAowMDAwMDAw NTA1IDAwMDAwIG4gCjAwMDAwMDE1MzggMDAwMDAgbiAKMDAwMDAwMjQ4OSAwMDAwMCBuIAow MDAwMjQ1MDg3IDAwMDAwIG4gCjAwMDAyMjY3OTYgMDAwMDAgbiAKMDAwMDI1MjUwMiAwMDAw MCBuIAowMDAwMDAwNjU2IDAwMDAwIG4gCjAwMDAwMDA3MTAgMDAwMDAgbiAKMDAwMDAwMTUx OCAwMDAwMCBuIAowMDAwMDAxNTc0IDAwMDAwIG4gCjAwMDAwMDI0NjkgMDAwMDAgbiAKMDAw MDAwNDMwMSAwMDAwMCBuIAowMDAwMDAyNTI1IDAwMDAwIG4gCjAwMDAwMDQyODAgMDAwMDAg biAKMDAwMDAwNDQwOSAwMDAwMCBuIAowMDAwMDA1MDEwIDAwMDAwIG4gCjAwMDAwMDUyODMg MDAwMDAgbiAKMDAwMDAwNTMwMiAwMDAwMCBuIAowMDAwMDA1NTUwIDAwMDAwIG4gCjAwMDAw MDU4MTggMDAwMDAgbiAKMDAwMDAwNjA3MSAwMDAwMCBuIAowMDAwMDA1NTY5IDAwMDAwIG4g CjAwMDAwMDU3OTkgMDAwMDAgbiAKMDAwMDAwNjA5MCAwMDAwMCBuIAowMDAwMDA2MzUyIDAw MDAwIG4gCjAwMDAwMDQ3MzggMDAwMDAgbiAKMDAwMDAwNDk5MSAwMDAwMCBuIAowMDAwMDA2 MzcxIDAwMDAwIG4gCjAwMDAwMDY2MDEgMDAwMDAgbiAKMDAwMDAwNjYyMCAwMDAwMCBuIAow MDAwMDA2ODkzIDAwMDAwIG4gCjAwMDAwMDY5MTIgMDAwMDAgbiAKMDAwMDAwNzE2OSAwMDAw MCBuIAowMDAwMjI3MDQzIDAwMDAwIG4gCjAwMDAwMjE3NDYgMDAwMDAgbiAKMDAwMDAxMDIz OCAwMDAwMCBuIAowMDAwMDExODUyIDAwMDAwIG4gCjAwMDAwMTM2MTQgMDAwMDAgbiAKMDAw MDAxNTk2NiAwMDAwMCBuIAowMDAwMDIwMzI5IDAwMDAwIG4gCjAwMDAwMjE3MjUgMDAwMDAg biAKMDAwMDAxNTk4NyAwMDAwMCBuIAowMDAwMDE2NjQ0IDAwMDAwIG4gCjAwMDAwMTg2OTQg MDAwMDAgbiAKMDAwMDAyMDMwOCAwMDAwMCBuIAowMDAwMDE2NjY0IDAwMDAwIG4gCjAwMDAw MTg2NzMgMDAwMDAgbiAKMDAwMDAwNzE4OCAwMDAwMCBuIAowMDAwMDA3ODQ1IDAwMDAwIG4g CjAwMDAwMDc4NjUgMDAwMDAgbiAKMDAwMDAxMDIxNyAwMDAwMCBuIAowMDAwMDExODczIDAw MDAwIG4gCjAwMDAwMTM1OTMgMDAwMDAgbiAKMDAwMDAyMzcyMiAwMDAwMCBuIAowMDAwMDIx OTAzIDAwMDAwIG4gCjAwMDAwMjM3MDEgMDAwMDAgbiAKMDAwMDAyMzgzMCAwMDAwMCBuIAow MDAwMDI1NzUzIDAwMDAwIG4gCjAwMDAwMjYwNDcgMDAwMDAgbiAKMDAwMDAyNTIxMCAwMDAw MCBuIAowMDAwMDI1NDU4IDAwMDAwIG4gCjAwMDAwMjQxNjggMDAwMDAgbiAKMDAwMDAyNDQy MSAwMDAwMCBuIAowMDAwMDI0NzEyIDAwMDAwIG4gCjAwMDAwMjQ5NDIgMDAwMDAgbiAKMDAw MDAyNjM3OSAwMDAwMCBuIAowMDAwMDI2NjQxIDAwMDAwIG4gCjAwMDAwMjQ0NDAgMDAwMDAg biAKMDAwMDAyNDY5MyAwMDAwMCBuIAowMDAwMDI0OTYxIDAwMDAwIG4gCjAwMDAwMjUxOTEg MDAwMDAgbiAKMDAwMDAyNjA2NiAwMDAwMCBuIAowMDAwMDI2MzYwIDAwMDAwIG4gCjAwMDAw MjU0NzcgMDAwMDAgbiAKMDAwMDAyNTczNCAwMDAwMCBuIAowMDAwMjI2OTE5IDAwMDAwIG4g CjAwMDAwMjczMzcgMDAwMDAgbiAKMDAwMDAyODk1MSAwMDAwMCBuIAowMDAwMDM5Mjk4IDAw MDAwIG4gCjAwMDAwNDA5MTIgMDAwMDAgbiAKMDAwMDAyODk3MiAwMDAwMCBuIAowMDAwMDI5 NjI5IDAwMDAwIG4gCjAwMDAwMjY2NjAgMDAwMDAgbiAKMDAwMDAyNzMxNyAwMDAwMCBuIAow MDAwMDMxNjc5IDAwMDAwIG4gCjAwMDAwMzMwNzUgMDAwMDAgbiAKMDAwMDA0MDkzMyAwMDAw MCBuIAowMDAwMDQyNjUzIDAwMDAwIG4gCjAwMDAwMzMwOTYgMDAwMDAgbiAKMDAwMDAzNjE3 NiAwMDAwMCBuIAowMDAwMDM2MTk3IDAwMDAwIG4gCjAwMDAwMzkyNzcgMDAwMDAgbiAKMDAw MDAyOTY0OSAwMDAwMCBuIAowMDAwMDMxNjU4IDAwMDAwIG4gCjAwMDAwNDQ0NzQgMDAwMDAg biAKMDAwMDA0MjY3NCAwMDAwMCBuIAowMDAwMDQ0NDUyIDAwMDAwIG4gCjAwMDAwNDQ1ODUg MDAwMDAgbiAKMDAwMDA0NTc2NSAwMDAwMCBuIAowMDAwMDQ2MDYwIDAwMDAwIG4gCjAwMDAw NDUyMDkgMDAwMDAgbiAKMDAwMDA0NTQ2MCAwMDAwMCBuIAowMDAwMDQ1NDgwIDAwMDAwIG4g CjAwMDAwNDU3NDUgMDAwMDAgbiAKMDAwMDA0NDkzMyAwMDAwMCBuIAowMDAwMDQ1MTg5IDAw MDAwIG4gCjAwMDAwNDYwODAgMDAwMDAgbiAKMDAwMDA0NjMxMyAwMDAwMCBuIAowMDAwMDQ2 ODY2IDAwMDAwIG4gCjAwMDAwNDcxNjMgMDAwMDAgbiAKMDAwMDA0NjU4NiAwMDAwMCBuIAow MDAwMDQ2ODQ2IDAwMDAwIG4gCjAwMDAwNDcxODMgMDAwMDAgbiAKMDAwMDA0NzQzOSAwMDAw MCBuIAowMDAwMDQ2MzMzIDAwMDAwIG4gCjAwMDAwNDY1NjYgMDAwMDAgbiAKMDAwMDIyNzIw OSAwMDAwMCBuIAowMDAwMDU0MTk2IDAwMDAwIG4gCjAwMDAwNTU4MTIgMDAwMDAgbiAKMDAw MDA1NzU3OCAwMDAwMCBuIAowMDAwMDU4OTc2IDAwMDAwIG4gCjAwMDAwNTIxNjMgMDAwMDAg biAKMDAwMDA1NDE3NCAwMDAwMCBuIAowMDAwMDQ5MDk3IDAwMDAwIG4gCjAwMDAwNTIxNDEg MDAwMDAgbiAKMDAwMDA2Mjc4NiAwMDAwMCBuIAowMDAwMDYzNDQ1IDAwMDAwIG4gCjAwMDAw NTg5OTggMDAwMDAgbiAKMDAwMDA1OTY2MSAwMDAwMCBuIAowMDAwMDU1ODM0IDAwMDAwIG4g CjAwMDAwNTc1NTYgMDAwMDAgbiAKMDAwMDA1OTY4MiAwMDAwMCBuIAowMDAwMDYyNzY0IDAw MDAwIG4gCjAwMDAwNDc0NTkgMDAwMDAgbiAKMDAwMDA0OTA3NSAwMDAwMCBuIAowMDAwMDYz ODcxIDAwMDAwIG4gCjAwMDAwNjM0NjYgMDAwMDAgbiAKMDAwMDA2Mzg1MCAwMDAwMCBuIAow MDAwMDYzOTgyIDAwMDAwIG4gCjAwMDAyMjY5NTkgMDAwMDAgbiAKMDAwMDA2NDY3NiAwMDAw MCBuIAowMDAwMDY0MTM1IDAwMDAwIG4gCjAwMDAwNjQ2NTUgMDAwMDAgbiAKMDAwMDA2NDc4 NyAwMDAwMCBuIAowMDAwMDY1NTIzIDAwMDAwIG4gCjAwMDAwNjQ5NDAgMDAwMDAgbiAKMDAw MDA2NTUwMiAwMDAwMCBuIAowMDAwMDY1NjM0IDAwMDAwIG4gCjAwMDAwNjY0MzEgMDAwMDAg biAKMDAwMDA2NTc4NyAwMDAwMCBuIAowMDAwMDY2NDEwIDAwMDAwIG4gCjAwMDAwNjY1NDIg MDAwMDAgbiAKMDAwMDA2ODQ1NiAwMDAwMCBuIAowMDAwMjI1ODQyIDAwMDAwIG4gCjAwMDAw NjY2OTUgMDAwMDAgbiAKMDAwMDA2ODQzNCAwMDAwMCBuIAowMDAwMDY4NTY5IDAwMDAwIG4g CjAwMDAwNzAyNTAgMDAwMDAgbiAKMDAwMDA3MDU0NSAwMDAwMCBuIAowMDAwMDY5NDczIDAw MDAwIG4gCjAwMDAwNjk3MjQgMDAwMDAgbiAKMDAwMDA2ODkxNyAwMDAwMCBuIAowMDAwMDY5 MTgyIDAwMDAwIG4gCjAwMDAwNzA1NjUgMDAwMDAgbiAKMDAwMDA3MDgyMSAwMDAwMCBuIAow MDAwMDY5NzQ0IDAwMDAwIG4gCjAwMDAwNjk5NzcgMDAwMDAgbiAKMDAwMDA3MDg0MSAwMDAw MCBuIAowMDAwMDcxMTM4IDAwMDAwIG4gCjAwMDAwNjkyMDIgMDAwMDAgbiAKMDAwMDA2OTQ1 MyAwMDAwMCBuIAowMDAwMDcxMTU4IDAwMDAwIG4gCjAwMDAwNzE0MTQgMDAwMDAgbiAKMDAw MDA2OTk5NyAwMDAwMCBuIAowMDAwMDcwMjMwIDAwMDAwIG4gCjAwMDAyMjY2MjggMDAwMDAg biAKMDAwMDA3MzA3MiAwMDAwMCBuIAowMDAwMDc1MDgzIDAwMDAwIG4gCjAwMDAwNzUxMDUg MDAwMDAgbiAKMDAwMDA3NjYwNyAwMDAwMCBuIAowMDAwMDgxMDU5IDAwMDAwIG4gCjAwMDAw ODI0NTcgMDAwMDAgbiAKMDAwMDA3NjYyOSAwMDAwMCBuIAowMDAwMDc3Mjg4IDAwMDAwIG4g CjAwMDAwNzczMDkgMDAwMDAgbiAKMDAwMDA3Nzk3MiAwMDAwMCBuIAowMDAwMDc3OTkzIDAw MDAwIG4gCjAwMDAwODEwMzcgMDAwMDAgbiAKMDAwMDA4MjQ3OSAwMDAwMCBuIAowMDAwMDg0 MDk1IDAwMDAwIG4gCjAwMDAwODQxMTcgMDAwMDAgbiAKMDAwMDA4NzE5OSAwMDAwMCBuIAow MDAwMDcxNDM0IDAwMDAwIG4gCjAwMDAwNzMwNTAgMDAwMDAgbiAKMDAwMDA4Nzc3NyAwMDAw MCBuIAowMDAwMDg3MjIxIDAwMDAwIG4gCjAwMDAwODc3NTYgMDAwMDAgbiAKMDAwMDA4Nzg5 MCAwMDAwMCBuIAowMDAwMjI3MTY3IDAwMDAwIG4gCjAwMDAwODg0MjMgMDAwMDAgbiAKMDAw MDA4ODA0MyAwMDAwMCBuIAowMDAwMDg4NDAyIDAwMDAwIG4gCjAwMDAwODg1MzYgMDAwMDAg biAKMDAwMDIyNzA4MyAwMDAwMCBuIAowMDAwMDg5MTYyIDAwMDAwIG4gCjAwMDAwODg2ODkg MDAwMDAgbiAKMDAwMDA4OTE0MSAwMDAwMCBuIAowMDAwMDg5Mjc1IDAwMDAwIG4gCjAwMDAw ODk5ODQgMDAwMDAgbiAKMDAwMDA4OTQyOCAwMDAwMCBuIAowMDAwMDg5OTYzIDAwMDAwIG4g CjAwMDAwOTAwOTcgMDAwMDAgbiAKMDAwMDA5MDg3MSAwMDAwMCBuIAowMDAwMDkwMjUwIDAw MDAwIG4gCjAwMDAwOTA4NTAgMDAwMDAgbiAKMDAwMDA5MDk4NCAwMDAwMCBuIAowMDAwMDkx ODIxIDAwMDAwIG4gCjAwMDAwOTExMzcgMDAwMDAgbiAKMDAwMDA5MTgwMCAwMDAwMCBuIAow MDAwMDkxOTM0IDAwMDAwIG4gCjAwMDAwOTI4NjYgMDAwMDAgbiAKMDAwMDA5MjA4NyAwMDAw MCBuIAowMDAwMDkyODQ1IDAwMDAwIG4gCjAwMDAwOTI5NzkgMDAwMDAgbiAKMDAwMDA5NDky NCAwMDAwMCBuIAowMDAwMjI1OTc3IDAwMDAwIG4gCjAwMDAwOTMxMzIgMDAwMDAgbiAKMDAw MDA5NDkwMiAwMDAwMCBuIAowMDAwMDk1MDM3IDAwMDAwIG4gCjAwMDAwOTY3NDYgMDAwMDAg biAKMDAwMDA5NzAyMiAwMDAwMCBuIAowMDAwMDk2NDc1IDAwMDAwIG4gCjAwMDAwOTY3MjYg MDAwMDAgbiAKMDAwMDA5NTM4NSAwMDAwMCBuIAowMDAwMDk1NjQxIDAwMDAwIG4gCjAwMDAw OTc2MTggMDAwMDAgbiAKMDAwMDA5Nzg1MSAwMDAwMCBuIAowMDAwMDk1OTM3IDAwMDAwIG4g CjAwMDAwOTYyMDIgMDAwMDAgbiAKMDAwMDA5NTY2MSAwMDAwMCBuIAowMDAwMDk1OTE3IDAw MDAwIG4gCjAwMDAwOTYyMjIgMDAwMDAgbiAKMDAwMDA5NjQ1NSAwMDAwMCBuIAowMDAwMDk3 MzIyIDAwMDAwIG4gCjAwMDAwOTc1OTggMDAwMDAgbiAKMDAwMDA5NzA0MiAwMDAwMCBuIAow MDAwMDk3MzAyIDAwMDAwIG4gCjAwMDAyMjY4MzUgMDAwMDAgbiAKMDAwMDEwMzY0MiAwMDAw MCBuIAowMDAwMTA1MjU4IDAwMDAwIG4gCjAwMDAwOTc4NzEgMDAwMDAgbiAKMDAwMDA5OTQ4 NyAwMDAwMCBuIAowMDAwMTAxNjA5IDAwMDAwIG4gCjAwMDAxMDM2MjAgMDAwMDAgbiAKMDAw MDExMTc3NiAwMDAwMCBuIAowMDAwMTEyNDM1IDAwMDAwIG4gCjAwMDAxMDAxODkgMDAwMDAg biAKMDAwMDEwMTU4NyAwMDAwMCBuIAowMDAwMTA1MjgwIDAwMDAwIG4gCjAwMDAxMDc2MzQg MDAwMDAgbiAKMDAwMDEwNzY1NiAwMDAwMCBuIAowMDAwMTA5Mzc4IDAwMDAwIG4gCjAwMDAx MDk0MDAgMDAwMDAgbiAKMDAwMDExMTc1NCAwMDAwMCBuIAowMDAwMDk5NTA5IDAwMDAwIG4g CjAwMDAxMDAxNjggMDAwMDAgbiAKMDAwMDExNDI4NCAwMDAwMCBuIAowMDAwMTEyNDU2IDAw MDAwIG4gCjAwMDAxMTQyNjIgMDAwMDAgbiAKMDAwMDExNDM5NyAwMDAwMCBuIAowMDAwMTE1 ODA3IDAwMDAwIG4gCjAwMDAxMTYwODcgMDAwMDAgbiAKMDAwMDExNTI4MyAwMDAwMCBuIAow MDAwMTE1NTM0IDAwMDAwIG4gCjAwMDAxMTY0MDcgMDAwMDAgbiAKMDAwMDExNjY2MyAwMDAw MCBuIAowMDAwMTE0NzQ1IDAwMDAwIG4gCjAwMDAxMTQ5NzggMDAwMDAgbiAKMDAwMDExNDk5 OCAwMDAwMCBuIAowMDAwMTE1MjYzIDAwMDAwIG4gCjAwMDAxMTY2ODMgMDAwMDAgbiAKMDAw MDExNjkzOSAwMDAwMCBuIAowMDAwMTE1NTU0IDAwMDAwIG4gCjAwMDAxMTU3ODcgMDAwMDAg biAKMDAwMDExNjEwNyAwMDAwMCBuIAowMDAwMTE2Mzg3IDAwMDAwIG4gCjAwMDAxMTY5NTkg MDAwMDAgbiAKMDAwMDExNzIxOSAwMDAwMCBuIAowMDAwMjI3MTI1IDAwMDAwIG4gCjAwMDAx MjY0OTYgMDAwMDAgbiAKMDAwMDEyNzE1NSAwMDAwMCBuIAowMDAwMTIzMDU2IDAwMDAwIG4g CjAwMDAxMjUwNjcgMDAwMDAgbiAKMDAwMDEyNTA4OSAwMDAwMCBuIAowMDAwMTI2NDc0IDAw MDAwIG4gCjAwMDAxMjk3MTcgMDAwMDAgbiAKMDAwMDEzMDM3NiAwMDAwMCBuIAowMDAwMTIw NTE1IDAwMDAwIG4gCjAwMDAxMjMwMzQgMDAwMDAgbiAKMDAwMDEyNzE3NiAwMDAwMCBuIAow MDAwMTI5Njk1IDAwMDAwIG4gCjAwMDAxMTg4NzcgMDAwMDAgbiAKMDAwMDEyMDQ5MyAwMDAw MCBuIAowMDAwMTE3MjM5IDAwMDAwIG4gCjAwMDAxMTg4NTUgMDAwMDAgbiAKMDAwMDEzMDM5 NyAwMDAwMCBuIAowMDAwMTMyMTAwIDAwMDAwIG4gCjAwMDAxMzM4NDcgMDAwMDAgbiAKMDAw MDEzMjEyMiAwMDAwMCBuIAowMDAwMTMzODI1IDAwMDAwIG4gCjAwMDAxMzM5NjAgMDAwMDAg biAKMDAwMDEzNTMzNyAwMDAwMCBuIAowMDAwMTM1NjE1IDAwMDAwIG4gCjAwMDAxMzQ1NjUg MDAwMDAgbiAKMDAwMDEzNDgxNiAwMDAwMCBuIAowMDAwMTM1NjM1IDAwMDAwIG4gCjAwMDAx MzU4OTEgMDAwMDAgbiAKMDAwMDEzNDgzNiAwMDAwMCBuIAowMDAwMTM1MDY0IDAwMDAwIG4g CjAwMDAxMzQyODAgMDAwMDAgbiAKMDAwMDEzNDU0NSAwMDAwMCBuIAowMDAwMTM1OTExIDAw MDAwIG4gCjAwMDAxMzYxNjcgMDAwMDAgbiAKMDAwMDEzNTA4NCAwMDAwMCBuIAowMDAwMTM1 MzE3IDAwMDAwIG4gCjAwMDAyMjY3MTIgMDAwMDAgbiAKMDAwMDEzOTI0NSAwMDAwMCBuIAow MDAwMTQxMjU2IDAwMDAwIG4gCjAwMDAxMzc4MjUgMDAwMDAgbiAKMDAwMDEzOTIyMyAwMDAw MCBuIAowMDAwMTQxMjc4IDAwMDAwIG4gCjAwMDAxNDE5MzYgMDAwMDAgbiAKMDAwMDE0MzU5 NSAwMDAwMCBuIAowMDAwMTQ0MjU0IDAwMDAwIG4gCjAwMDAxNDQyNzUgMDAwMDAgbiAKMDAw MDE0NjY4NiAwMDAwMCBuIAowMDAwMTM2MTg3IDAwMDAwIG4gCjAwMDAxMzc4MDMgMDAwMDAg biAKMDAwMDE0MTk1NyAwMDAwMCBuIAowMDAwMTQzNTczIDAwMDAwIG4gCjAwMDAxNDcwOTUg MDAwMDAgbiAKMDAwMDE0NjcwOCAwMDAwMCBuIAowMDAwMTQ3MDc0IDAwMDAwIG4gCjAwMDAx NDcyMDggMDAwMDAgbiAKMDAwMDIyNjU0NCAwMDAwMCBuIAowMDAwMTQ3ODY5IDAwMDAwIG4g CjAwMDAxNDczNjEgMDAwMDAgbiAKMDAwMDE0Nzg0OCAwMDAwMCBuIAowMDAwMTQ3OTgyIDAw MDAwIG4gCjAwMDAxNDg3MTUgMDAwMDAgbiAKMDAwMDE0ODEzNSAwMDAwMCBuIAowMDAwMTQ4 Njk0IDAwMDAwIG4gCjAwMDAxNDg4MjggMDAwMDAgbiAKMDAwMDE0OTY2NSAwMDAwMCBuIAow MDAwMTQ4OTgxIDAwMDAwIG4gCjAwMDAxNDk2NDQgMDAwMDAgbiAKMDAwMDE0OTc3OCAwMDAw MCBuIAowMDAwMTUwMzQ3IDAwMDAwIG4gCjAwMDAxNDk5MzEgMDAwMDAgbiAKMDAwMDE1MDMy NiAwMDAwMCBuIAowMDAwMTUwNDYwIDAwMDAwIG4gCjAwMDAyMjcwMDEgMDAwMDAgbiAKMDAw MDE1MTE0OSAwMDAwMCBuIAowMDAwMjI2MTEyIDAwMDAwIG4gCjAwMDAxNTA2MTMgMDAwMDAg biAKMDAwMDE1MTEyOCAwMDAwMCBuIAowMDAwMTUxMjYyIDAwMDAwIG4gCjAwMDAxNTIwODYg MDAwMDAgbiAKMDAwMDE1MTQxNSAwMDAwMCBuIAowMDAwMTUyMDY1IDAwMDAwIG4gCjAwMDAx NTIxOTkgMDAwMDAgbiAKMDAwMDE1Mjc4MiAwMDAwMCBuIAowMDAwMTUyMzUyIDAwMDAwIG4g CjAwMDAxNTI3NjEgMDAwMDAgbiAKMDAwMDE1Mjg5NSAwMDAwMCBuIAowMDAwMjI2ODc3IDAw MDAwIG4gCjAwMDAxNTM1NjIgMDAwMDAgbiAKMDAwMDE1MzA0OCAwMDAwMCBuIAowMDAwMTUz NTQxIDAwMDAwIG4gCjAwMDAxNTM2NzUgMDAwMDAgbiAKMDAwMDE1NDQzOSAwMDAwMCBuIAow MDAwMTUzODI4IDAwMDAwIG4gCjAwMDAxNTQ0MTggMDAwMDAgbiAKMDAwMDE1NDU1MiAwMDAw MCBuIAowMDAwMTU1MzU1IDAwMDAwIG4gCjAwMDAxNTQ3MDUgMDAwMDAgbiAKMDAwMDE1NTMz NCAwMDAwMCBuIAowMDAwMTU1NDY4IDAwMDAwIG4gCjAwMDAxNTYzNzEgMDAwMDAgbiAKMDAw MDE1NTYyMSAwMDAwMCBuIAowMDAwMTU2MzUwIDAwMDAwIG4gCjAwMDAxNTY0ODQgMDAwMDAg biAKMDAwMDE1OTA0OSAwMDAwMCBuIAowMDAwMTU2NjM3IDAwMDAwIG4gCjAwMDAxNTkwMjcg MDAwMDAgbiAKMDAwMDE1OTE2MiAwMDAwMCBuIAowMDAwMTYxNjk0IDAwMDAwIG4gCjAwMDAx NjE5NzIgMDAwMDAgbiAKMDAwMDE2MDYxNCAwMDAwMCBuIAowMDAwMTYwODY1IDAwMDAwIG4g CjAwMDAxNjA4ODUgMDAwMDAgbiAKMDAwMDE2MTE0MSAwMDAwMCBuIAowMDAwMTYxOTkyIDAw MDAwIG4gCjAwMDAxNjIyMjAgMDAwMDAgbiAKMDAwMDE2MTE2MSAwMDAwMCBuIAowMDAwMTYx NDI2IDAwMDAwIG4gCjAwMDAxNTk4MTQgMDAwMDAgbiAKMDAwMDE2MDA3MCAwMDAwMCBuIAow MDAwMTYyMjQwIDAwMDAwIG4gCjAwMDAxNjI0NzMgMDAwMDAgbiAKMDAwMDE1OTUzOCAwMDAw MCBuIAowMDAwMTU5Nzk0IDAwMDAwIG4gCjAwMDAxNjAwOTAgMDAwMDAgbiAKMDAwMDE2MDMx OCAwMDAwMCBuIAowMDAwMTYwMzM4IDAwMDAwIG4gCjAwMDAxNjA1OTQgMDAwMDAgbiAKMDAw MDE2MTQ0NiAwMDAwMCBuIAowMDAwMTYxNjc0IDAwMDAwIG4gCjAwMDAyMjY1ODYgMDAwMDAg biAKMDAwMDE3MjA1NSAwMDAwMCBuIAowMDAwMTczNjcxIDAwMDAwIG4gCjAwMDAxNzUzMzEg MDAwMDAgbiAKMDAwMDE3Njk0NyAwMDAwMCBuIAowMDAwMTc2OTY5IDAwMDAwIG4gCjAwMDAx Nzc2MjcgMDAwMDAgbiAKMDAwMDE2MjQ5MyAwMDAwMCBuIAowMDAwMTY0MTA5IDAwMDAwIG4g CjAwMDAxNjQxMzEgMDAwMDAgbiAKMDAwMDE2NTUyOSAwMDAwMCBuIAowMDAwMTczNjkzIDAw MDAwIG4gCjAwMDAxNzUzMDkgMDAwMDAgbiAKMDAwMDE2NjIzMCAwMDAwMCBuIAowMDAwMTY4 MjQxIDAwMDAwIG4gCjAwMDAxNjU1NTEgMDAwMDAgbiAKMDAwMDE2NjIwOSAwMDAwMCBuIAow MDAwMTY4MjYzIDAwMDAwIG4gCjAwMDAxNzA2NzQgMDAwMDAgbiAKMDAwMDE3MDY5NiAwMDAw MCBuIAowMDAwMTcxMzU0IDAwMDAwIG4gCjAwMDAxNzEzNzUgMDAwMDAgbiAKMDAwMDE3MjAz NCAwMDAwMCBuIAowMDAwMTc4MDM2IDAwMDAwIG4gCjAwMDAyMjYyNDcgMDAwMDAgbiAKMDAw MDE3NzY0OCAwMDAwMCBuIAowMDAwMTc4MDE1IDAwMDAwIG4gCjAwMDAxNzgxNDkgMDAwMDAg biAKMDAwMDIyNjY3MCAwMDAwMCBuIAowMDAwMTc4Nzg0IDAwMDAwIG4gCjAwMDAxNzgzMDIg MDAwMDAgbiAKMDAwMDE3ODc2MyAwMDAwMCBuIAowMDAwMTc4ODk3IDAwMDAwIG4gCjAwMDAx Nzk2MzEgMDAwMDAgbiAKMDAwMDE3OTA1MCAwMDAwMCBuIAowMDAwMTc5NjEwIDAwMDAwIG4g CjAwMDAxNzk3NDQgMDAwMDAgbiAKMDAwMDE4MDU1NCAwMDAwMCBuIAowMDAwMTc5ODk3IDAw MDAwIG4gCjAwMDAxODA1MzMgMDAwMDAgbiAKMDAwMDE4MDY2NyAwMDAwMCBuIAowMDAwMTg1 NjczIDAwMDAwIG4gCjAwMDAxODA4MjAgMDAwMDAgbiAKMDAwMDE4NTY1MSAwMDAwMCBuIAow MDAwMTg1Nzg2IDAwMDAwIG4gCjAwMDAxODkwNDIgMDAwMDAgbiAKMDAwMDE4OTMyMCAwMDAw MCBuIAowMDAwMTkyNDA5IDAwMDAwIG4gCjAwMDAxOTI2NjAgMDAwMDAgbiAKMDAwMDE4Nzk3 MSAwMDAwMCBuIAowMDAwMTg4MjI3IDAwMDAwIG4gCjAwMDAxODg3OTQgMDAwMDAgbiAKMDAw MDE4OTAyMiAwMDAwMCBuIAowMDAwMTkxMjA5IDAwMDAwIG4gCjAwMDAxOTE0NzQgMDAwMDAg biAKMDAwMDE5MjkyOCAwMDAwMCBuIAowMDAwMTkzMTg0IDAwMDAwIG4gCjAwMDAxODkzNDAg MDAwMDAgbiAKMDAwMDE4OTU3MyAwMDAwMCBuIAowMDAwMTg4NTE4IDAwMDAwIG4gCjAwMDAx ODg3NzQgMDAwMDAgbiAKMDAwMDE5MjY4MCAwMDAwMCBuIAowMDAwMTkyOTA4IDAwMDAwIG4g CjAwMDAxOTA5MzMgMDAwMDAgbiAKMDAwMDE5MTE4OSAwMDAwMCBuIAowMDAwMTg3NzE4IDAw MDAwIG4gCjAwMDAxODc5NTEgMDAwMDAgbiAKMDAwMDE4NzQyMCAwMDAwMCBuIAowMDAwMTg3 Njk4IDAwMDAwIG4gCjAwMDAxODgyNDcgMDAwMDAgbiAKMDAwMDE4ODQ5OCAwMDAwMCBuIAow MDAwMTkwMTQ1IDAwMDAwIG4gCjAwMDAxOTA0MTIgMDAwMDAgbiAKMDAwMDE4OTU5MyAwMDAw MCBuIAowMDAwMTg5ODQ5IDAwMDAwIG4gCjAwMDAxOTA0MzIgMDAwMDAgbiAKMDAwMDE5MDY2 MCAwMDAwMCBuIAowMDAwMTkzMjA0IDAwMDAwIG4gCjAwMDAxOTM0NjAgMDAwMDAgbiAKMDAw MDE5MDY4MCAwMDAwMCBuIAowMDAwMTkwOTEzIDAwMDAwIG4gCjAwMDAxODk4NjkgMDAwMDAg biAKMDAwMDE5MDEyNSAwMDAwMCBuIAowMDAwMTkxNDk0IDAwMDAwIG4gCjAwMDAxOTE3MjIg MDAwMDAgbiAKMDAwMDE5MTc0MiAwMDAwMCBuIAowMDAwMTkyMzg4IDAwMDAwIG4gCjAwMDAx ODYzMjggMDAwMDAgbiAKMDAwMDE4NzEzMyAwMDAwMCBuIAowMDAwMTg3MTU0IDAwMDAwIG4g CjAwMDAyMjY3NTQgMDAwMDAgbiAKMDAwMDIyNDcxNSAwMDAwMCBuIAowMDAwMTg3Mjg0IDAw MDAwIG4gCjAwMDAyMzM4NjYgMDAwMDAgbiAKMDAwMDIyNDg3MyAwMDAwMCBuIAowMDAwMTk3 NDM2IDAwMDAwIG4gCjAwMDAxOTk4NDcgMDAwMDAgbiAKMDAwMDIxMDE1OCAwMDAwMCBuIAow MDAwMjEwODE3IDAwMDAwIG4gCjAwMDAyMDQ3ODMgMDAwMDAgbiAKMDAwMDIwNjM5OSAwMDAw MCBuIAowMDAwMjA2NDIxIDAwMDAwIG4gCjAwMDAyMDc4MTkgMDAwMDAgbiAKMDAwMDE5OTg2 OSAwMDAwMCBuIAowMDAwMjAxNDg1IDAwMDAwIG4gCjAwMDAyMjMzNTcgMDAwMDAgbiAKMDAw MDIyNDAxNSAwMDAwMCBuIAowMDAwMjE0OTcxIDAwMDAwIG4gCjAwMDAyMTczODIgMDAwMDAg biAKMDAwMDIxMjg3MSAwMDAwMCBuIAowMDAwMjEzNTMwIDAwMDAwIG4gCjAwMDAyMDc4NDEg MDAwMDAgbiAKMDAwMDIwOTQ1NyAwMDAwMCBuIAowMDAwMjAxNTA3IDAwMDAwIG4gCjAwMDAy MDMxMjMgMDAwMDAgbiAKMDAwMDIxNzQwNCAwMDAwMCBuIAowMDAwMjE5NDkzIDAwMDAwIG4g CjAwMDAyMjI2NzggMDAwMDAgbiAKMDAwMDIyMzMzNiAwMDAwMCBuIAowMDAwMTk2NzU2IDAw MDAwIG4gCjAwMDAxOTc0MTUgMDAwMDAgbiAKMDAwMDIwMzE0NSAwMDAwMCBuIAowMDAwMjA0 NzYxIDAwMDAwIG4gCjAwMDAyMTA4MzggMDAwMDAgbiAKMDAwMDIxMjg0OSAwMDAwMCBuIAow MDAwMjA5NDc5IDAwMDAwIG4gCjAwMDAyMTAxMzcgMDAwMDAgbiAKMDAwMDIxOTUxNSAwMDAw MCBuIAowMDAwMjIyNjU2IDAwMDAwIG4gCjAwMDAyMTM1NTEgMDAwMDAgbiAKMDAwMDIxNDk0 OSAwMDAwMCBuIAowMDAwMjI0MDM2IDAwMDAwIG4gCjAwMDAyMjQ2OTQgMDAwMDAgbiAKMDAw MDE5MzQ4MCAwMDAwMCBuIAowMDAwMTk1MDk2IDAwMDAwIG4gCjAwMDAxOTUxMTggMDAwMDAg biAKMDAwMDE5NjczNCAwMDAwMCBuIAowMDAwMjI1NjkyIDAwMDAwIG4gCjAwMDAyMjYzNTgg MDAwMDAgbiAKMDAwMDIyNjQ3NyAwMDAwMCBuIAowMDAwMjI3MjUxIDAwMDAwIG4gCjAwMDAy MzMxMzggMDAwMDAgbiAKMDAwMDIzMzE2MCAwMDAwMCBuIAowMDAwMjMzNDA1IDAwMDAwIG4g CjAwMDAyMzQwNTAgMDAwMDAgbiAKMDAwMDI0NDI5OCAwMDAwMCBuIAowMDAwMjQ0MzIxIDAw MDAwIG4gCjAwMDAyNDQ1NTcgMDAwMDAgbiAKMDAwMDI0NTI2MiAwMDAwMCBuIAowMDAwMjUy MDAzIDAwMDAwIG4gCjAwMDAyNTIwMjUgMDAwMDAgbiAKMDAwMDI1MjI2MyAwMDAwMCBuIAp0 cmFpbGVyCjw8IC9TaXplIDU3NiAvUm9vdCA1NjMgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDwz Zjk3ZmUzYjA0MmNjMWUzMmVlYWJkYjA4NGQ2OWI3Zj4KPDNmOTdmZTNiMDQyY2MxZTMyZWVh YmRiMDg0ZDY5YjdmPiBdID4+CnN0YXJ0eHJlZgoyNTI4NTIKJSVFT0YK --------------040106090402000909020509-- From rbarnes@bbn.com Mon Dec 21 19:27:57 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028323A6822 for ; Mon, 21 Dec 2009 19:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbFLPnNrThXg for ; Mon, 21 Dec 2009 19:27:55 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9D0063A6966 for ; Mon, 21 Dec 2009 19:27:55 -0800 (PST) Received: from [128.89.254.130] (helo=[192.168.1.45]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NMvPN-0002HU-CL; Mon, 21 Dec 2009 22:27:38 -0500 Message-Id: From: "Richard L. Barnes" To: =JeffH In-Reply-To: <4B301195.4050808@KingsMountain.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 21 Dec 2009 22:27:37 -0500 References: <4B301195.4050808@KingsMountain.com> X-Mailer: Apple Mail (2.936) Cc: IETF oauth WG Subject: Re: [OAUTH-WG] fyi: Cross-Origin Resource Sharing (CORS) [W3C] X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 03:27:57 -0000 Hey Jeff, Thanks for sending out this slide deck. Here's a pointer to the latest draft spec: I reviewed this document a while back, and was actually surprised that it was being proposed as a competitor to OAuth. Looking back at the document, I realized why: None of the authorization system that's laid out in the slide deck is actually in the document. And I don't see a deliverable on the relevant working group's page that would indicate that the group is actually planning on developing something like this: Obviously, to have an interoperable solution, a specification would be a good thing to have; in that regard, OAuth is ahead :) Technically speaking, I think the proposals are actually mutually beneficial. For example, the OAuth work flow could be used to establish an authorization for Site B to send cross-origin requests to Site A. In more detail: Consider the Client/Server/RO interactions in two parts (I'll use the draft-hammer-oauth terminology), (1) Establishment of authorization, and (2) cross-origin data access. In terms of establishing authorization, there's essentially no difference between OAuth and Maciej's proposal (Slide 18), except that OAuth fills in the details of (1) how the user knows what to tell the server to indicate "user picked Site B" and (2) how the user gets back to Site B from Site A. Here's a cartoon of how the two overlay: User SiteA SiteB (RO) (Client) (Server) | | | |---------Request-------->| |<--------Redirect--------| | | | |--Auth-B--->| | ** Maciej Proposal |<-Redirect--| | ** (2nd round-trip) | | | |---------Request-------->| |<--------Response--------| | | | OAuth offers more flexibility in the data access step than Maciej's proposal: In his proposal, the Server authenticates the request based on the identities of the user/RO (via the Cookie) and the Client (via the Origin); in OAuth, the Server uses a token that is bound to RO and Client identities, but can have additional semantics if the RO and Server agree on them. So OAuth can provide more fine-grained permissions than CORS. This property doesn't necessarily depend on the communications model -- in principle, an OAuth token could be passed in a cross-domain XHR as an authorization. There is also a security benefit of server-to-server communications, since it can be used to support situations where the RO that establishes the authorization is different from the users that benefit from it. For example, consider a payroll-processing company that gets a client comany's data and generates paychecks. The client company is the RO that will set up the authorization, and the users that ultimately access the paychecks will not be authorized to access the raw financial data. (You can imagine a similar example with an on- demand photo printing service that provides printing to my friends but not the full-resolution photos themselves.) For these situations, the server-to-server model is nice because the two services (payroll and financial data, printing and photos) can authenticate each other directly and communicate privately, not exposing data to some intermediate user. (Do you know why "no server-to-server" was a requirement here? It seems like there are a lot of other practical/non-security benefits: Synchronizing without user involvement, faster service at client interaction time, lower client-facing bandwidth requirements (e.g., for mobile users), etc.) That's a pretty detailed response, but I hope it helps clarify some of the relationships between these ideas. It would likely be a good idea to have more interaction between these two groups. --Richard On Dec 21, 2009, at 7:23 PM, =JeffH wrote: > Hi, > > At the oauth unofficial un-bar bof in Hiroshima (ietf-76 Nov-2009), > I mentioned some work in the W3C WebApps WG called "Cross-Origin > Resource Sharing (CORS)" which will essentially facilitate > interactions between web sites on a user's behalf, and thus has > similar user-visible functionality as OAuth. > > At the W3C technical plenary (in Santa Clara) the week prior to > IETF-76, during the webapps working group session(s), Maciej > Stachowiak presented a slide deck background/overview of CORS > (attached below). Of possible interest to this group, at the end of > the slides (slide 37) he contrasts CORS to OAuth. > > StPeter asked me to send a pointer to the slides to this list, this > message is to satisfy that action item. > > A way to think about the apparent duplication of effort between > OAuth and CORS is that OAuth is a means to do sharing between one's > websites today, with today's deployed browsers, while CORS is > ostensibly a way to do it in the not-to-distant future, with the aid > of the latest generation of browsers (and thus an at-first-small(er)- > user-population, but one which will grow as new browser generations > are released and deployed). > > Also, CORS isn't (AFAICT) vying to become an HTTP authentication > method. > > That all said, being aware of the CORS is of possible interest to > y'all. > > HTH, > > =JeffH > ------ > > Cross-Origin Resource Sharing > Editor's Draft 5 October 2009 > http://dev.w3.org/2006/waf/access-control/ > > CORS Background slides (Maciej Stachowiak) > http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ > 0468.html > > public-webapps@w3.org Mail Archives > http://lists.w3.org/Archives/Public/public-webapps/ > > W3C Web Applications (WebApps) Working Group > http://www.w3.org/2008/webapps/ > Background > -2009-11-03.pdf>_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Tue Dec 22 09:15:49 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00AD63A6A2C for ; Tue, 22 Dec 2009 09:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz7nwqOP32qa for ; Tue, 22 Dec 2009 09:15:48 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DC2ED3A6A36 for ; Tue, 22 Dec 2009 09:15:47 -0800 (PST) Received: from leavealone.cisco.com (rtp-isp-nat1.cisco.com [64.102.254.33]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4396340D11 for ; Tue, 22 Dec 2009 10:15:20 -0700 (MST) Message-ID: <4B30FE9B.3080706@stpeter.im> Date: Tue, 22 Dec 2009 10:15:07 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: OAuth WG X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070907040106000207000804" Subject: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 17:15:49 -0000 This is a cryptographically signed message in MIME format. --------------ms070907040106000207000804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit IETF 77 will be held in Anaheim, California, USA on March 21-26, 2010. The OAuth WG will meet at IETF 77, so mark your calendars! http://www.ietf.org/meeting/77/ Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms070907040106000207000804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIyMjE3MTUwN1owIwYJKoZIhvcNAQkEMRYEFB9qExNjbpO56Lvnoyd4 y19BAZx2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEASRJX2dNmukASULZPiH3kZ2ZMB18ITwZDEF4xO8j0 GB9T2B2JnIGSRGV7XQlUhWTM4B6HO5havjBr6nTv3q6mi9J82MMoWtP9waje5W9c27WOVViO IMil4t+gJpBXIEMhJHN8qzXNvJWVNbtwKnmK+IK6iXhlDAZVRuoRt2Yfi8+T1P+0cuqsP5G/ gtAyyIZpHulc6KqXqWzd2fUqyf/FKlBE6PB4SOy5E0nqgZGiTWyxIdCyKuuaKbv0GU86F0B2 xqLPeWsB4RCft6GNAx+Y4YpNaxK3KHiDAwFp3x/pNPkRE1wjHBazUmWYZewwcZI6woH2y6UN Shts98bQLbJgWAAAAAAAAA== --------------ms070907040106000207000804-- From rbarnes@bbn.com Tue Dec 22 12:49:40 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3C93A6A5E for ; Tue, 22 Dec 2009 12:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2IpukSntX2V for ; Tue, 22 Dec 2009 12:49:39 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 9B1B93A67DD for ; Tue, 22 Dec 2009 12:49:39 -0800 (PST) Received: from [128.89.254.154] (helo=[10.0.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NNBfV-0004aR-BU; Tue, 22 Dec 2009 15:49:21 -0500 Message-Id: <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> From: "Richard L. Barnes" To: Peter Saint-Andre In-Reply-To: <4B30FE9B.3080706@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Dec 2009 15:49:21 -0500 References: <4B30FE9B.3080706@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: OAuth WG Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 20:49:40 -0000 I hope you're going to request an OAuth meeting this time? :) --Richard On Dec 22, 2009, at 12:15 PM, Peter Saint-Andre wrote: > IETF 77 will be held in Anaheim, California, USA on March 21-26, 2010. > The OAuth WG will meet at IETF 77, so mark your calendars! > > http://www.ietf.org/meeting/77/ > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From recordond@gmail.com Tue Dec 22 13:03:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B963A6A50 for ; Tue, 22 Dec 2009 13:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANuxAaX44PQ7 for ; Tue, 22 Dec 2009 13:03:55 -0800 (PST) Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 662683A67DD for ; Tue, 22 Dec 2009 13:03:55 -0800 (PST) Received: by iwn33 with SMTP id 33so4640573iwn.29 for ; Tue, 22 Dec 2009 13:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=OxkRpoBbCHlvwOop2AQwZZw08c7fypKPH/1ezcfds4Y=; b=j1gYfprjgs76/kCKHeovhyjJ/MBTEQdP1zpzqZSHDtYQxqT47NDYgzUPkl5O25Zvcs rV1r05tpQnvfYgV8DqeFltH4vFA0mLE2pJOVowikJgMB2o1hkFXOq8aY1N7n9yNe3q1T PY4eShMfc23rDtH02GMHo3XddmBWz9s5Izd/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=o+6wWuwScM2z53wGuCzF/1vX4zt+22k6Ih31LOJdTiCTjCChpNUf3HGJQnOAr8Ajc3 ZO6apMHhILEk7z1ZTLIAZG+7qj3LAV7Xt4R9Si9p1Y8hTwlm5cuwn44gExWXY06TZIY/ L2i8rSxmV5/x7kIHoiiITtgLl+mHTW0AaaBvo= MIME-Version: 1.0 Received: by 10.231.125.19 with SMTP id w19mr876905ibr.8.1261515815020; Tue, 22 Dec 2009 13:03:35 -0800 (PST) In-Reply-To: <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> References: <4B30FE9B.3080706@stpeter.im> <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> Date: Tue, 22 Dec 2009 13:03:34 -0800 Message-ID: From: David Recordon To: Peter Saint-Andre , OAuth WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 21:03:56 -0000 I know that it might be taboo, but what would people think about having a meeting in January to talk about OAuth 2.0 and WRAP? I'd really rather see these become the same thing and fear that waiting until late March might be too long. (We should also have a meeting in March.) --David On Tue, Dec 22, 2009 at 12:49 PM, Richard L. Barnes wrote= : > I hope you're going to request an OAuth meeting this time? =A0:) > --Richard > > On Dec 22, 2009, at 12:15 PM, Peter Saint-Andre wrote: > >> IETF 77 will be held in Anaheim, California, USA on March 21-26, 2010. >> The OAuth WG will meet at IETF 77, so mark your calendars! >> >> http://www.ietf.org/meeting/77/ >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From stpeter@stpeter.im Tue Dec 22 13:08:02 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C8F28B23E for ; Tue, 22 Dec 2009 13:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLmPHy9VP4ww for ; Tue, 22 Dec 2009 13:08:01 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B20143A6A5E for ; Tue, 22 Dec 2009 13:08:01 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E19840D40; Tue, 22 Dec 2009 14:07:44 -0700 (MST) Message-ID: <4B313520.9060902@stpeter.im> Date: Tue, 22 Dec 2009 14:07:44 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Richard L. Barnes" References: <4B30FE9B.3080706@stpeter.im> <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> In-Reply-To: <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010407080108030902090507" Cc: OAuth WG Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 21:08:02 -0000 This is a cryptographically signed message in MIME format. --------------ms010407080108030902090507 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I think that's what I meant by "the OAuth WG will meet at IETF 77". If you found that statement ambiguous, let me know. :) On 12/22/09 1:49 PM, Richard L. Barnes wrote: > I hope you're going to request an OAuth meeting this time? :) > --Richard > > On Dec 22, 2009, at 12:15 PM, Peter Saint-Andre wrote: > >> IETF 77 will be held in Anaheim, California, USA on March 21-26, 2010. >> The OAuth WG will meet at IETF 77, so mark your calendars! >> >> http://www.ietf.org/meeting/77/ >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> --------------ms010407080108030902090507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIyMjIxMDc0NFowIwYJKoZIhvcNAQkEMRYEFDW0dV2OaXTYVwyxkKCl s7ba6vx0MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAMTfI5k5Gw1NwpqpGHgn0Yd+w7kqJtOdpQHJxUct7 werGOgb0v9bdEypgBsUwIp7rFvekLMVaVIQGmYg/yGe4U4RgElNRTyDfJ74skwxGBWmkpErG xcfj6adKFudjsCpR0VMLkUnby8heXrB9LIuhpCAn9sLbCqSLDqEoWtqilP1HW15zUQWLPwND efEkdG4UvnuhHJ2BlGgtNbnP5FfpK8ZlSc1nrsRK3oeISoVwaRmlBXcqxJIHUhnDPFvlSRW6 tOZr/ex9COQyCWVblVQoERc0v9tvXgk7m27yx5aUVOmPm2PeKxlw4DOIE/w3nLF8sKhopRe6 s2VYe9kSGJsmEQAAAAAAAA== --------------ms010407080108030902090507-- From eran@hueniverse.com Tue Dec 22 13:14:20 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2412A3A6A49 for ; Tue, 22 Dec 2009 13:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpjZdSXHCAZp for ; Tue, 22 Dec 2009 13:14:13 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5D7DE3A6A71 for ; Tue, 22 Dec 2009 13:14:13 -0800 (PST) Received: (qmail 4563 invoked from network); 22 Dec 2009 21:13:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 22 Dec 2009 21:13:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 22 Dec 2009 14:13:46 -0700 From: Eran Hammer-Lahav To: David Recordon , Peter Saint-Andre , OAuth WG Date: Tue, 22 Dec 2009 14:13:53 -0700 Thread-Topic: [OAUTH-WG] meeting at IETF 77 Thread-Index: AcqDSj8biAY3lrbJQJ+cWyRtLnNXDAAAN5kQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343787DCFBB8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4B30FE9B.3080706@stpeter.im> <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 21:14:20 -0000 We should use the time until the meeting to decide what 2.0 includes and co= me to some consensus around that. We should use the meeting to decide if th= is is the new direction the WG should take. It doesn't mean we need to wait= until April (when a new charter is likely) to get work done. Arranging for an IETF meeting earlier is not likely, but we can have meetin= gs to prepare proposals for the WG to consider. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of David Recordon > Sent: Tuesday, December 22, 2009 1:04 PM > To: Peter Saint-Andre; OAuth WG > Subject: Re: [OAUTH-WG] meeting at IETF 77 >=20 > I know that it might be taboo, but what would people think about having a > meeting in January to talk about OAuth 2.0 and WRAP? I'd really rather s= ee > these become the same thing and fear that waiting until late March might = be > too long. (We should also have a meeting in > March.) >=20 > --David >=20 > On Tue, Dec 22, 2009 at 12:49 PM, Richard L. Barnes > wrote: > > I hope you're going to request an OAuth meeting this time? =A0:) > > --Richard > > > > On Dec 22, 2009, at 12:15 PM, Peter Saint-Andre wrote: > > > >> IETF 77 will be held in Anaheim, California, USA on March 21-26, 2010. > >> The OAuth WG will meet at IETF 77, so mark your calendars! > >> > >> http://www.ietf.org/meeting/77/ > >> > >> Peter > >> > >> -- > >> Peter Saint-Andre > >> https://stpeter.im/ > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From faynberg@alcatel-lucent.com Tue Dec 22 13:19:39 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D223A68F6 for ; Tue, 22 Dec 2009 13:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEdVLYxBlbxx for ; Tue, 22 Dec 2009 13:19:37 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 8D2933A68E7 for ; Tue, 22 Dec 2009 13:19:37 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id nBMLJKMS028284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 15:19:20 -0600 (CST) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id nBMLJJLa014673; Tue, 22 Dec 2009 15:19:19 -0600 (CST) Message-ID: <4B3137D7.5020402@alcatel-lucent.com> Date: Tue, 22 Dec 2009 16:19:19 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: David Recordon References: <4B30FE9B.3080706@stpeter.im> <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 21:19:39 -0000 David, I am (and have been) all for meetings, but a January meeting may be problematic (at least for me) because of it is too short a fuse for those who have extensive travel. I would definitely support this being item for the mail list discussion. Igor David Recordon wrote: > I know that it might be taboo, but what would people think about > having a meeting in January to talk about OAuth 2.0 and WRAP? I'd > really rather see these become the same thing and fear that waiting > until late March might be too long. (We should also have a meeting in > March.) > > --David > > On Tue, Dec 22, 2009 at 12:49 PM, Richard L. Barnes wrote: > >> I hope you're going to request an OAuth meeting this time? :) >> --Richard >> >> On Dec 22, 2009, at 12:15 PM, Peter Saint-Andre wrote: >> >> >>> IETF 77 will be held in Anaheim, California, USA on March 21-26, 2010. >>> The OAuth WG will meet at IETF 77, so mark your calendars! >>> >>> http://www.ietf.org/meeting/77/ >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From stpeter@stpeter.im Tue Dec 22 13:19:43 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD793A68E7 for ; Tue, 22 Dec 2009 13:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 476E8Lejvn1J for ; Tue, 22 Dec 2009 13:19:42 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6E3923A6A73 for ; Tue, 22 Dec 2009 13:19:42 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A98BC40D40; Tue, 22 Dec 2009 14:19:25 -0700 (MST) Message-ID: <4B3137DD.2050409@stpeter.im> Date: Tue, 22 Dec 2009 14:19:25 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: David Recordon References: <4B30FE9B.3080706@stpeter.im> <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090602090703050303040809" Cc: OAuth WG Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 21:19:43 -0000 This is a cryptographically signed message in MIME format. --------------ms090602090703050303040809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Interim meetings are far from taboo, and I think would be a good idea for us, even if only in the chatroom we have on jabber.ietf.org or via conference call. BTW, I've been gathering input from a bunch of folks who have been involved in the WRAP work and will post to the list very soon with some further thoughts about the road ahead for our WG. Peter On 12/22/09 2:03 PM, David Recordon wrote: > I know that it might be taboo, but what would people think about > having a meeting in January to talk about OAuth 2.0 and WRAP? I'd > really rather see these become the same thing and fear that waiting > until late March might be too long. (We should also have a meeting in > March.) > > --David > > On Tue, Dec 22, 2009 at 12:49 PM, Richard L. Barnes wrote: >> I hope you're going to request an OAuth meeting this time? :) >> --Richard >> >> On Dec 22, 2009, at 12:15 PM, Peter Saint-Andre wrote: >> >>> IETF 77 will be held in Anaheim, California, USA on March 21-26, 2010. >>> The OAuth WG will meet at IETF 77, so mark your calendars! >>> >>> http://www.ietf.org/meeting/77/ >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ --------------ms090602090703050303040809 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIyMjIxMTkyNVowIwYJKoZIhvcNAQkEMRYEFMkuf65tKARyG0a8GiQq kAW7cBuVMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAVbxQPUQiMBjbZps94/ddJfEZh7fgb/nJtgNQBZpK 3kL3Fjk+FMgpVM4rBZ/0nknzuROxXVqRqURnEIjwWVqWMhefMPYcgGA02EjkNDs48RFlhkW7 iVPbvR5926Svhfb0caO+09Lq6W06ZsLsXRjfDjAFHxRJH+b3c83IlXGzuWhlwYO/Zfw+SQGK o9OhhWl0tzfzHJzLKLEsWxep/tyqNkjiWK94ZENSWZRp+z/VFIKvkz1XhNQBImkJ07h/KLeJ XQaTeehXbBlZGRGbGXA4cNQpCtcS4M9kLaUE8htNAEODwzkMGAfgaPqDZeJTqUb/hVGrY074 b5dlqBpGQiX0EwAAAAAAAA== --------------ms090602090703050303040809-- From rbarnes@bbn.com Tue Dec 22 14:24:12 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078243A68AD for ; Tue, 22 Dec 2009 14:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inW3JWRAAqII for ; Tue, 22 Dec 2009 14:24:11 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1A06E3A67AE for ; Tue, 22 Dec 2009 14:24:11 -0800 (PST) Received: from [128.89.254.71] (helo=[10.0.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NND8z-0006fc-Bu; Tue, 22 Dec 2009 17:23:53 -0500 Message-Id: <8C6A58CC-7699-4795-B1D3-E26DC64597F4@bbn.com> From: "Richard L. Barnes" To: Peter Saint-Andre In-Reply-To: <4B3137DD.2050409@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Dec 2009 17:23:53 -0500 References: <4B30FE9B.3080706@stpeter.im> <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> <4B3137DD.2050409@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: OAuth WG Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 22:24:12 -0000 +1 We've had a lot of success with "virtual interim" meetings (predominantly via Webex) in ECRIT and GEOPRIV. IIRC, they require around a 2-week advance warning and generally aren't held within a few weeks of the IETF, so we would be looking at mid- to late-January. --Richard On Dec 22, 2009, at 4:19 PM, Peter Saint-Andre wrote: > Interim meetings are far from taboo, and I think would be a good idea > for us, even if only in the chatroom we have on jabber.ietf.org or via > conference call. > > BTW, I've been gathering input from a bunch of folks who have been > involved in the WRAP work and will post to the list very soon with > some > further thoughts about the road ahead for our WG. > > Peter > > On 12/22/09 2:03 PM, David Recordon wrote: >> I know that it might be taboo, but what would people think about >> having a meeting in January to talk about OAuth 2.0 and WRAP? I'd >> really rather see these become the same thing and fear that waiting >> until late March might be too long. (We should also have a meeting >> in >> March.) >> >> --David >> >> On Tue, Dec 22, 2009 at 12:49 PM, Richard L. Barnes >> wrote: >>> I hope you're going to request an OAuth meeting this time? :) >>> --Richard >>> >>> On Dec 22, 2009, at 12:15 PM, Peter Saint-Andre wrote: >>> >>>> IETF 77 will be held in Anaheim, California, USA on March 21-26, >>>> 2010. >>>> The OAuth WG will meet at IETF 77, so mark your calendars! >>>> >>>> http://www.ietf.org/meeting/77/ >>>> >>>> Peter >>>> >>>> -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From stpeter@stpeter.im Wed Dec 23 11:20:32 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B81D3A6A07 for ; Wed, 23 Dec 2009 11:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbfNM9gZ6s4x for ; Wed, 23 Dec 2009 11:20:31 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6730D3A686E for ; Wed, 23 Dec 2009 11:20:19 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8628140D3E; Wed, 23 Dec 2009 12:19:58 -0700 (MST) Message-ID: <4B326D5D.1040406@stpeter.im> Date: Wed, 23 Dec 2009 12:19:57 -0700 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Richard L. Barnes" References: <4B30FE9B.3080706@stpeter.im> <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> <4B3137DD.2050409@stpeter.im> <8C6A58CC-7699-4795-B1D3-E26DC64597F4@bbn.com> In-Reply-To: <8C6A58CC-7699-4795-B1D3-E26DC64597F4@bbn.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050109080500010602040804" Cc: OAuth WG Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 19:20:32 -0000 This is a cryptographically signed message in MIME format. --------------ms050109080500010602040804 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/22/09 3:23 PM, Richard L. Barnes wrote: > +1 > > We've had a lot of success with "virtual interim" meetings > (predominantly via Webex) in ECRIT and GEOPRIV. IIRC, they require > around a 2-week advance warning and generally aren't held within a few > weeks of the IETF, so we would be looking at mid- to late-January. Yes, I think that's an excellent idea and I plan to make heavy use of it in early 2010 so that we can make quick progress. --------------ms050109080500010602040804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA5MTIyMzE5MTk1N1owIwYJKoZIhvcNAQkEMRYEFHkPxmqy9yS0V6DwTmwu IlSdp0o+MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAM909pDcx5je33HKvf8gES7wiIsGDeRWz3QcRCj5L lI0LgFND5dl5JwIugIw9krNaIsZM6PEoUMCkU1o0/YhA+urSqrYmy+Q0NUgakoMx8wklpSB3 Vy6o/+TUHzBu3JqYrH5EvkKpA9fqgtEbTwZ9Gj4jRQ83QnEwrHSmRAOMLSIoT3orwroCWmc9 IewO60V0OW1kfBStfdVZ+noB4+ZL5Su/1x23dPUNyLtMIftamXJL0Xf2C4AfATDRLezgiFrU boMcEwu+txzqahNh/H8dSci6w72J/Cv6OC953HLsuHPSFtVBGTKOAFOZV2KL9wTOdIQr69RZ N9F02yMQLX2CCgAAAAAAAA== --------------ms050109080500010602040804-- From Dick.Hardt@microsoft.com Wed Dec 23 11:41:06 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8993A689A for ; Wed, 23 Dec 2009 11:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjiYlzawsKyN for ; Wed, 23 Dec 2009 11:41:05 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 709CC3A67FB for ; Wed, 23 Dec 2009 11:41:05 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 23 Dec 2009 11:40:46 -0800 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.226]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Wed, 23 Dec 2009 11:40:47 -0800 From: Dick Hardt To: "Richard L. Barnes" , Peter Saint-Andre Thread-Topic: [OAUTH-WG] meeting at IETF 77 Thread-Index: AQHKgyp2HyP/RTMXo0GzvfD/TVN84pFyEECAgAAD+QCAAARtgIAAEgOAgADenvA= Date: Wed, 23 Dec 2009 19:40:44 +0000 Message-ID: <2E704320B9494649A53EFAC64BF2C07E0490E0A9@TK5EX14MBXC101.redmond.corp.microsoft.com> References: <4B30FE9B.3080706@stpeter.im> <7C8C1AB2-AAC4-49D2-A6CF-7681513A4ABD@bbn.com> <4B3137DD.2050409@stpeter.im> <8C6A58CC-7699-4795-B1D3-E26DC64597F4@bbn.com> In-Reply-To: <8C6A58CC-7699-4795-B1D3-E26DC64597F4@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] meeting at IETF 77 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 19:42:10 -0000 +1 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Richard L. Barnes > Sent: Tuesday, December 22, 2009 2:24 PM > To: Peter Saint-Andre > Cc: OAuth WG > Subject: Re: [OAUTH-WG] meeting at IETF 77 >=20 > +1 >=20 > We've had a lot of success with "virtual interim" meetings > (predominantly via Webex) in ECRIT and GEOPRIV. IIRC, they require > around a 2-week advance warning and generally aren't held within a few > weeks of the IETF, so we would be looking at mid- to late-January. >=20 > --Richard >=20 >=20 >=20 > On Dec 22, 2009, at 4:19 PM, Peter Saint-Andre wrote: >=20 > > Interim meetings are far from taboo, and I think would be a good idea > > for us, even if only in the chatroom we have on jabber.ietf.org or > via > > conference call. > > > > BTW, I've been gathering input from a bunch of folks who have been > > involved in the WRAP work and will post to the list very soon with > > some > > further thoughts about the road ahead for our WG. > > > > Peter > > > > On 12/22/09 2:03 PM, David Recordon wrote: > >> I know that it might be taboo, but what would people think about > >> having a meeting in January to talk about OAuth 2.0 and WRAP? I'd > >> really rather see these become the same thing and fear that waiting > >> until late March might be too long. (We should also have a meeting > >> in > >> March.) > >> > >> --David > >> > >> On Tue, Dec 22, 2009 at 12:49 PM, Richard L. Barnes > >> wrote: > >>> I hope you're going to request an OAuth meeting this time? :) > >>> --Richard > >>> > >>> On Dec 22, 2009, at 12:15 PM, Peter Saint-Andre wrote: > >>> > >>>> IETF 77 will be held in Anaheim, California, USA on March 21-26, > >>>> 2010. > >>>> The OAuth WG will meet at IETF 77, so mark your calendars! > >>>> > >>>> http://www.ietf.org/meeting/77/ > >>>> > >>>> Peter > >>>> > >>>> -- > >>>> Peter Saint-Andre > >>>> https://stpeter.im/ > > _______________________________________________ > > 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 From y.oiwa@aist.go.jp Mon Dec 28 22:50:56 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91C683A67AA; Mon, 28 Dec 2009 22:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.542 X-Spam-Level: X-Spam-Status: No, score=0.542 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T73ITA7Tsi+6; Mon, 28 Dec 2009 22:50:55 -0800 (PST) Received: from mx1s.aist.go.jp (mx1s.aist.go.jp [150.29.246.134]) by core3.amsl.com (Postfix) with ESMTP id E95FC3A6939; Mon, 28 Dec 2009 22:50:54 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1s.aist.go.jp with ESMTP id nBT6oUal005971; Tue, 29 Dec 2009 15:50:30 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1262069433; bh=jpTtCVrvzJBSn4Lx28ThHqIQYybvAqEE9ohAw9hgBKI=; h=From:Date:Message-ID; b=WewKi9GeesK9Ph/be4WDJkmUWRCPVBO2uSbA6kiYAHOAp4OQqfFwAVHa8t51bqc8r Baq6iEsdQQ7qpHzbpzrD9S4Ry1fLcfKR4IivnOvzU65msYFqv4UniZF1c4CGguAemw K0zwWlZPJdEdj91ikK0LLkiRwqGB0qM4jTrzrj04= Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id nBT6oUNX028544; Tue, 29 Dec 2009 15:50:30 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp4.aist.go.jp with ESMTP id nBT6oSKI001072; Tue, 29 Dec 2009 15:50:28 +0900 (JST) env-from (y.oiwa@aist.go.jp) From: Yutaka OIWA To: =JeffH References: <4B394BD4.3020104@KingsMountain.com> Date: Tue, 29 Dec 2009 15:50:28 +0900 Message-ID: <874onal1e3.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-http-auth@osafoundation.org, public-web-security@w3.org, oauth@ietf.org, apps-discuss@ietf.org, ietf-http-wg@w3.org Subject: Re: [OAUTH-WG] HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 06:50:56 -0000 Dear Jeff, [ Sorry again for one more cross-posting response for an important comment, And please edit the reply addresses whenever appropriate ] (for people in OAuth ML: this is a reply to http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0356.html) =JeffH writes: >Thanks for sending out this announcement regarding your on-going work. Having a >meetup of one form or another to discuss HTTP authentication will be useful. > > In regards of the working-group context though, I note that the feedback given > on your presentation at IETF-74 in SF was that it was likely that the > appropriate place to discuss this work would be the to-be-formed OAuth WG... (cut) > Indeed, the OAuth WG has now formed > and its charter has > this note down towards the end.. > > > The Working Group will also define a generally applicable > > HTTP authentication mechanism (i.e., browser-based "2-leg" > > scenerio). > > > So I respectfully suggest re-sending your message to and > taking discussion there -- and for those interested folks to subscribe to > . Thank you very much for the important comment. Yes, we were once suggested at San Francisco that we will be better redirected to OAuth WG, and I also attended for OAuth WG there. However, after that I felt getting lost between two WGs, because most of discussions in OAuth ML and WG meeting are focused on the OAuth related protocol only. Moreover, most of discussions on HTTP authentications (except OAuth) were still going on in httpbis ML. I wanted to talk people at IETF meetings for this, because I was not sure whether the redirection was accepted by the OAuth WG. But as there were no OAuth/httpbis WGs at Stockholm, we couldn't plan going there. Then I talked personally at Apparea meeting at Hiroshima in Japan (where we can go there easily and inexpensively :-)) and there I have been suggested to first introduce our proposal to apps-discuss ML. Coincidently, there comes a new mailing list well-suited for discussing a general HTTP security matters at a very good opportunity. These are the reasons why I sent the previous mail to these two MLs. I also included http and http-auth MLs to the Cc list, because I had sent our proposal previously to these, and because I thought that there might be people interested in generic HTTP authentication issues. I am still feeling unclear whether there is a consensus in the people's mind whether the scope of OAuth WG really includes "generic" HTTP authentication issues "unrelated to OAuth", because all contents in the WG charter (except one sentence Jeff has mentioned) seems to me only considering OAuth-related things. These are mostly unchanged from an older charter draft which had stated "generic HTTP auth is out of scope". In other words, I did read that sentence in the charter as "to define OAuth-based 2-leg auth scheme generally applicable to HTTP", considering other parts of the charter and other resources. That's why I have hesitated to break in on OAuth WG with our proposal without prior consent, and I will be happy if there will be a clear statement on that. Anyway, I will now forward my previous mail to the IETF OAuth ML, which should have been included in the CC list. I'll keep reading any MLs I have mentioned, including OAuth. # Please forgive me of late mail replies, as I am almost being drowned # to surging waves of English mails (especially in httpbis MLs)... I will of course attend all HTTP-related WGs at Anaheim, and I'm looking forward to talking to people there. Thanks again, -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From y.oiwa@aist.go.jp Mon Dec 28 22:57:59 2009 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 415E83A6921 for ; Mon, 28 Dec 2009 22:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.134 X-Spam-Level: X-Spam-Status: No, score=-1.134 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf9iwvm5oa3P for ; Mon, 28 Dec 2009 22:57:58 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by core3.amsl.com (Postfix) with ESMTP id C4D553A685B for ; Mon, 28 Dec 2009 22:57:57 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id nBT6v791022441 for ; Tue, 29 Dec 2009 15:57:14 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1262069858; bh=TexXAwsaoZRKwREtjYiRGBY8ayv+Sh5qpT5Dw1cic8U=; h=From:Date:Message-ID; b=qYIHkvfPzvdil6XIYldLxzmf3YGULnuu+uUGlcIqGT3YF9lG/QQWVniW/VHo7iENv mnpMCwA5JQeTUGJcrmsDJpc6wcjzitDdOT4hBfdTU42qhDDMLldHmgQYN17c8Usa7n gph2bzxjHIW5rrcdIpUkDUh5nMc/3C4fBzRSNfXI= Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id nBT6v7xF029450 for ; Tue, 29 Dec 2009 15:57:07 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id nBT6v6Dh006149 for ; Tue, 29 Dec 2009 15:57:06 +0900 (JST) env-from (y.oiwa@aist.go.jp) From: Yutaka OIWA To: oauth@ietf.org Date: Tue, 29 Dec 2009 15:57:06 +0900 Message-ID: <87zl52jmil.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [OAUTH-WG] Fw: HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 06:57:59 -0000 --=-=-= Dear all at OAuth mailing list, As I have suggested in another mailing list (http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0356.html), I will repost an introduction for our proposal on secure generic HTTP authentication and call-for-meet-up to the IETF OAuth WG mailing list. (If you feel this as out-of-topic, please kindly read my previous mail for a background.) I hope we can meet and discuss on our proposal and other HTTP authentication related topics in Anaheim. Have a good new year, -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] --=-=-= Content-Type: message/rfc822 Content-Disposition: inline From: Yutaka OIWA To: apps-discuss@ietf.org, public-web-security@w3.org Cc: ietf-http-wg@w3.org, ietf-http-auth@osafoundation.org Subject: HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim? X-Draft-From: ("nnml:inbox") Reply-to: public-web-security@w3.org, y.oiwa@aist.go.jp Date: Thu, 24 Dec 2009 20:28:46 +0900 Message-ID: <87skb0lifl.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Lines: 54 Xref: bluewind.rcis.aist.go.jp record:3230 MIME-Version: 1.0 Dear people on IETF apps-discuss/public-web-security mailing lists and other related lists, I would like to introduce our proposal on HTTP mutual authentication. (I directed the Reply-to: header to the newly-created public-web-security mailing list, but I also welcome private replies or those to other lists.) Our proposal brings a strong, password-based mutual authentication to the HTTP authentication protocol. Our aims are to overcome several deficiencies (both for security and usability) on current HTTP authentication mechanisms, and to replace weak form-based authentication, which are used in most current Web apps, with stronger HTTP protocol-supported authentications. We designed the protocol so that (a) it removes any threats related to password/secret stealing like phishing or other attacks, (b) it will be extremely easy-to-use, and (c) it can accept many Web applications which were not well-supported with current HTTP authentication architecture (in RFC 2617). We believe that this is a correct direction for the future of the Web application authentication. Our proposed draft spec is available from . We put a preprint paper on our concept at ArXiv , and a presentation in a past httpbis WG is also available from , I appreciate your reading and comments on those documents. Furthermore, we have published a running code of the protocol implementation for Mozilla Firefox, available from . A pre-compiled binary, server-side implementations and running demonstration are available in our website . I noticed that the registration for IETF 77 at Anaheim is now open. I would like to have a meet-up of people related to general HTTP authentication issues/proposals at Anaheim. I have been told from Lisa that there will be several HTTP-related WGs and BoFs expected in Anaheim, and I think there will be a good opportunity for us to meet up. If you have any good ideas, please let me know. Have nice holidays, register for IETF 77 and see you in Anaheim! -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] --=-=-=--