Re: [TLS] New Cached info draft

"Brian Smith" <brian@briansmith.org> Tue, 30 March 2010 16:47 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CE93A6836 for <tls@core3.amsl.com>; Tue, 30 Mar 2010 09:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.038
X-Spam-Level: *
X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 KD9vvKVo69fc for <tls@core3.amsl.com>; Tue, 30 Mar 2010 09:47:59 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 071733A67B2 for <tls@ietf.org>; Tue, 30 Mar 2010 09:47:59 -0700 (PDT)
Received: from T60 (unknown [70.134.204.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A966A509DA; Tue, 30 Mar 2010 12:48:27 -0400 (EDT)
From: Brian Smith <brian@briansmith.org>
To: 'Adam Langley' <agl@imperialviolet.org>, tls@ietf.org
References: <877houyzek.fsf@mocca.josefsson.org> <C7D79BB3.9B56%stefan@aaa-sec.com> <396556a21003300824j342ef9f1yd4fdb10902baabab@mail.gmail.com>
In-Reply-To: <396556a21003300824j342ef9f1yd4fdb10902baabab@mail.gmail.com>
Date: Tue, 30 Mar 2010 11:48:26 -0500
Message-ID: <002201cad028$d20eb950$762c2bf0$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQEfpeSCvJRvs2rVB5QorNdV0l2lBQEk6grRAhMSYHkBuhd+1g==
Content-Language: en-us
Subject: Re: [TLS] New Cached info draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2010 16:47:59 -0000

Adam Langley wrote:
> One last point, I think I'd like to see the ability to cache the
CertificateStatus:

Optimally, the client only really wants a certificate status update when a
previously-cached one has expired and/or the server's certificate has
changed. Server certificates very rarely change. Consequently, the client
should be able to get by with sending the certificate status request
extension only when it doesn't have a non-expired certificate status for
that server, right? AFAICT, this would work equally well for servers that do
and don't support the cached-info extension.

Please let me know if I am overlooking something.

Regards,
Brian