Re: [TLS] the use cases for GSS-based TLS and the plea for

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 20 July 2007 18:21 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx6U-0008Hd-GA; Fri, 20 Jul 2007 14:21:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx6T-0008G0-Jy for tls@ietf.org; Fri, 20 Jul 2007 14:21:25 -0400
Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBx6S-0004h3-JH for tls@ietf.org; Fri, 20 Jul 2007 14:21:25 -0400
Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6KILNAS003182 for <tls@ietf.org>; Fri, 20 Jul 2007 18:21:23 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6KILN46023103 for <tls@ietf.org>; Fri, 20 Jul 2007 12:21:23 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6KILNFZ026906; Fri, 20 Jul 2007 13:21:23 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6KILNxG026905; Fri, 20 Jul 2007 13:21:23 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 20 Jul 2007 13:21:22 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Martin Rex <Martin.Rex@sap.com>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
Message-ID: <20070720182122.GM26603@Sun.COM>
References: <20070720175053.GL26603@Sun.COM> <200707201819.l6KIJOFW010809@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200707201819.l6KIJOFW010809@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

On Fri, Jul 20, 2007 at 08:19:24PM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > On Fri, Jul 20, 2007 at 07:40:34PM +0200, Martin Rex wrote:
> > > What I meant (and forgot to add) was "certificate-based credential
> > > (self-signed when no PKI is used) as a mandatory to implement
> > > feature for interoperability".
> > > 
> > > If support of cert-based credentials is a mere MAY, then I am sure
> > > there will be servers/services where installing or using a PKI
> > > credential is impossible/defective/unusable, and you cannot complain
> > > to the vendor because not-supporting it is fully compliant with the spec.
> > 
> > I don't think this spec aims to change TLS 1.1 to make any current
> > cipher suites that are REQUIRED to implement no longer REQUIRED to
> > implement.  Nor would I support that, for interop reasons, of course.
> 
> This isn't about what the TLS implementation supports, but what
> subset of the TLS implementations features a server/service
> is able to use.

See Jeff's point about implementation versus deployment.

We could require the use of a self-signed cert if no PKI is available,
but, why?  (I gave an answer, of course, related to
draft-johansson-http-tls-cb).

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls