Re: [OAUTH-WG] why are we signing?

Peter Saint-Andre <stpeter@stpeter.im> Thu, 03 December 2009 23:02 UTC

Return-Path: <stpeter@stpeter.im>
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 <oauth@core3.amsl.com>; 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 <oauth@core3.amsl.com>; 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 <oauth@ietf.org>; 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 <stpeter@stpeter.im>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <daf5b9570911082102u215dcf22gf0aeb2f3578e5ea0@mail.gmail.com> <cb5f7a380911120745w2f576d1ej300723581e50f03f@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343785102E58@P3PW5EX1MB01.EX1.SECURESERVER.NET> <cb5f7a380911130837q40d07388y1ae9b472be0ae57a@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E72343785102F1F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <A4E79C63-7B5C-4FBA-9DDA-5FEB35B9584D@microsoft.com> <3D3C75174CB95F42AD6BCC56E5555B4501F19743@FIESEXC015.nsn-intra.net> <90C41DD21FB7C64BB94121FBBC2E72343785209BBB@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4B15D7C2.2070901@stpeter.im> <90C41DD21FB7C64BB94121FBBC2E72343785209F78@P3PW5EX1MB01.EX1.SECURESERVER.NET> <daf5b9570912011946j600f8cbcl918af16fbbbc3206@mail.gmail.com> <EDFFBBF1-7FBB-4F4E-A0D8-B92C9036B33C@microsoft.com> <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" <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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2009 23:02:24 -0000

On 12/3/09 3:21 PM, Stephen Farrell wrote:
> 
> 
> On 3 Dec 2009, at 21:40, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> 
>> <hat type='chair'/>
>>
>> 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/