Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session

<home_pw@msn.com> Mon, 15 January 2007 20:35 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6YYb-0005bs-Vq; Mon, 15 Jan 2007 15:35:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6YYZ-0005bm-Uw for tls@ietf.org; Mon, 15 Jan 2007 15:35:51 -0500
Received: from bay0-omc1-s34.bay0.hotmail.com ([65.54.246.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6YYX-0006aZ-BM for tls@ietf.org; Mon, 15 Jan 2007 15:35:51 -0500
Received: from hotmail.com ([65.55.131.13]) by bay0-omc1-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 15 Jan 2007 12:35:48 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Jan 2007 12:35:48 -0800
Message-ID: <BAY126-DAV3B8ACC71590B02DEB861792B50@phx.gbl>
Received: from 70.142.20.165 by BAY126-DAV3.phx.gbl with DAV; Mon, 15 Jan 2007 20:35:46 +0000
X-Originating-IP: [70.142.20.165]
X-Originating-Email: [home_pw@msn.com]
X-Sender: home_pw@msn.com
From: home_pw@msn.com
References: <200701151803.TAA01170@uw1048.wdf.sap.corp><BAY126-DAV3FB5F2BEE682A4281A02A92B50@phx.gbl><86tzys9kln.fsf@raman.networkresonance.com> <BAY126-DAV9C5D63E9834DF129DE58E92B50@phx.gbl>
Subject: Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session
Date: Mon, 15 Jan 2007 12:35:44 -0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223
X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223
X-OriginalArrivalTime: 15 Jan 2007 20:35:48.0462 (UTC) FILETIME=[BD65E8E0:01C738E4]
X-Spam-Score: 0.2 (/)
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

OpenSSL, following the SHOULD recommendation

Out of interest, in resumption procedures does OpenSSL (a) 
maintain the earliest expiry date of the certs in the 
partys' cert chains in the connection state(s), or (b) 
revalidate cert chains?

If a server receives a client nonce that is later than the 
expiry data of the client cert INDICATED, is this a fatal 
alert case - even before handing the cert chain to the 
application? I assume not, under the "certs are opaque 
objects to SSL protocol machine" rule

While invalidated sessionIds and expired/invalid certs DO 
NOT require either party to drop an ongoing TLS Connection, 
these same conditions CLEARLY control active session 
duplication, session resumption, and full handshakes.



>   If either party suspects that the session may have been
>   compromised, or that certificates may have expired or 
> been revoked,
>   it should force a full handshake. "
 


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