Re: [TLS] New Cached info draft

Stefan Santesson <stefan@aaa-sec.com> Tue, 30 March 2010 23:32 UTC

Return-Path: <stefan@aaa-sec.com>
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 ABEF53A68E4 for <tls@core3.amsl.com>; Tue, 30 Mar 2010 16:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 wQCTSsw9Mbta for <tls@core3.amsl.com>; Tue, 30 Mar 2010 16:32:29 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id C5AF23A6B99 for <tls@ietf.org>; Tue, 30 Mar 2010 16:32:28 -0700 (PDT)
Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A72CA35A320 for <tls@ietf.org>; Wed, 31 Mar 2010 01:33:06 +0200 (CEST)
Received: (qmail 4024 invoked from network); 30 Mar 2010 23:32:57 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.16]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <brian@briansmith.org>; 30 Mar 2010 23:32:57 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Wed, 31 Mar 2010 01:32:54 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Brian Smith <brian@briansmith.org>, 'Adam Langley' <agl@imperialviolet.org>, tls@ietf.org
Message-ID: <C7D856C6.9C21%stefan@aaa-sec.com>
Thread-Topic: [TLS] New Cached info draft
Thread-Index: AQEfpeSCvJRvs2rVB5QorNdV0l2lBQEk6grRAhMSYHkBuhd+1pM55jtL
In-Reply-To: <002201cad028$d20eb950$762c2bf0$@briansmith.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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 23:32:29 -0000

I'm thinking along the same line here.

This and the fact that it mixes the use of two extensions makes me feel a
bit uncomfortable with this.

Is there a compelling use case?

/Stefan


On 10-03-30 5:48 PM, "Brian Smith" <brian@briansmith.org> wrote:

> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls