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

Peter Saint-Andre <stpeter@stpeter.im> Thu, 03 December 2009 21:40 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 1A1BE28C1CF for <oauth@core3.amsl.com>; 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 <oauth@core3.amsl.com>; 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 <oauth@ietf.org>; 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 <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>
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" <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 21:40:19 -0000

<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

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/