IETF Logo Mail Archive

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

Jeffrey Altman <jaltman@secure-endpoints.com> Fri, 20 July 2007 18:45 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 1IBxTb-0001zy-HT; Fri, 20 Jul 2007 14:45:19 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxTa-0001zl-3S for tls@ietf.org; Fri, 20 Jul 2007 14:45:18 -0400
Received: from ms-smtp-02.rdc-nyc.rr.com ([24.29.109.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBxTZ-0007WH-Pi for tls@ietf.org; Fri, 20 Jul 2007 14:45:18 -0400
Received: from www.secure-endpoints.com (cpe-24-193-47-99.nyc.res.rr.com [24.193.47.99]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id l6KIjEcE013488 for <tls@ietf.org>; Fri, 20 Jul 2007 14:45:14 -0400 (EDT)
Received: from [128.237.242.180] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.6.0) with ESMTP id md50000058347.msg for <tls@ietf.org>; Fri, 20 Jul 2007 14:46:23 -0400
Message-ID: <46A102E1.9060108@secure-endpoints.com>
Date: Fri, 20 Jul 2007 14:45:53 -0400
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Organization: Secure Endpoints Inc.
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: martin.rex@sap.com
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
References: <200707201828.l6KISQgI011525@fs4113.wdf.sap.corp>
In-Reply-To: <200707201828.l6KISQgI011525@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.95.2
OpenPGP: url=http://pgp.mit.edu
X-Authenticated-Sender: jaltman@secure-endpoints.com
X-Spam-Processed: www.secure-endpoints.com, Fri, 20 Jul 2007 14:46:23 -0400 (not processed: message from valid local sender)
X-MDRemoteIP: 128.237.242.180
X-Return-Path: jaltman@secure-endpoints.com
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: tls@ietf.org
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: tls@ietf.org, Nicolas.Williams@sun.com
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jaltman@secure-endpoints.com
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>
Content-Type: multipart/mixed; boundary="===============0004836914=="
Errors-To: tls-bounces@lists.ietf.org

Martin Rex wrote:
> I have _never_ disputed this motivation.  And I certainly do not
> want to take this freedom away from the customer.  However, I clearly
> want to deny the vendor a compliance tag for not providing a fully
> functional option to the customer.
Martin:

That is exactly what mandatory to implement means.  The vendor must
implement it to be considered in compliance.

However, you can't mandate in an IETF standard what is deployed by the
users of the implementation. 

My requirement is that TLS be deployable without certificates if an
alternative mechanism for managing keys distribution is available.   I
have that today with RFC 2712.  

Jeffrey Altman


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

v2.29.0 | Report a Bug | By Email | System Status