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

Martin Rex <Martin.Rex@sap.com> Fri, 27 July 2007 18:03 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 1IEU9V-0007U3-7W; Fri, 27 Jul 2007 14:03:01 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEU9U-0007Tw-0u for tls@ietf.org; Fri, 27 Jul 2007 14:03:00 -0400
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEU9T-00036x-GW for tls@ietf.org; Fri, 27 Jul 2007 14:02:59 -0400
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA26041; Fri, 27 Jul 2007 20:02:54 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200707271802.l6RI2t8G027843@fs4113.wdf.sap.corp>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for integrating
To: ynir@checkpoint.com
Date: Fri, 27 Jul 2007 20:02:55 +0200
In-Reply-To: <BAA1438E-7831-419C-9E6F-73F4D833F71F@checkpoint.com> from "Yoav Nir" at Jul 26, 7 06:14:39 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.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>
Errors-To: tls-bounces@lists.ietf.org

Yoav Nir wrote:
> 
> I disagree with that characterization of certificate-based  
> authentication.
> 
> You may not need to communicate with an identity provider, but you do  
> need to validate the certificate. This necessarily implies checking  
> for revocation. Now this could be done using CRL fetching, or OCSP or  
> SCVP, but it usually means external communications.

Nope, certificate validation does NOT imply certificate revocation
checking.  A CA may want to assert policies to do so, but that
is an entirely different can of worms.

A software architecture that performs certificate revoction checks
by synchronously communicating with third parties over the network
is likely to cause serious problem for the performance and
availability of a service.

I certainly don't mean to imply that certification checking is entirely
useless.  But my idea about a reasonable implementation of
certificate revocation checking precludes synchronous communication
with third parties, and therefore (accessing an) OCSP(-server).
But even then, I would NOT do this within the TLS handshake itself.


-Martin

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