Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling

"Kemp, David P." <DPKemp@missi.ncsc.mil> Fri, 26 March 2010 13:39 UTC

Return-Path: <DPKemp@missi.ncsc.mil>
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 673823A681A; Fri, 26 Mar 2010 06:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.215
X-Spam-Level:
X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
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 Ojm-9ikDY0rX; Fri, 26 Mar 2010 06:39:02 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by core3.amsl.com (Postfix) with ESMTP id 418C53A6B0F; Fri, 26 Mar 2010 06:38:51 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Mar 2010 09:38:06 -0400
Message-ID: <201003261339.o2QDd0SF024038@stingray.missi.ncsc.mil>
In-Reply-To: <4BAC80FD.4060603@free.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [pkix] Possible revocation delay issue with TLS stapling
Thread-Index: AcrMyHqeKDRxzsoGSJO7c3zXF/Y8WgAHGlDA
References: <op.u95kjftmkvaitl@lessa-ii> <4BAC5C33.8020509@seantek.com> <4BAC80FD.4060603@free.fr>
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: <pkix@ietf.org>, <tls@ietf.org>
X-OriginalArrivalTime: 26 Mar 2010 13:39:57.0828 (UTC) FILETIME=[D351CC40:01CACCE9]
Cc: dev+ietf@seantek.com
Subject: Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling
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: Fri, 26 Mar 2010 13:39:03 -0000

Another proof that the law of unintended consequences is operating in
full force.  Some time ago, guidance for how CRL nextUpdate should be
populated was discussed here.  One camp suggested that nextUpdate should
actually say when the next CRL would be issued; the other camp suggested
that because some applications treat nextUpdate as an expiration, CRL
issuers should, for example, put nextUpdate 7 days in the future for
CRLs that are actually issued every 24 hours, thereby treating scheduled
CRLs as unscheduled.

Rather than defining a new "suggested expiration" CRL extension for
applications to use as a default, the WG by inaction ratified the
treatment of nextUpdate as a de-facto expiration date.  The resulting
confusing consequences were predictable.

Dave


-----Original Message-----
From: Jean-Marc Desperrier

One thing I can confirm is that, as often the next CRL is generated 
earlier that the next update in the CRL, I've seen one actual CA case 
where the policy is such that getting the latest CRL *could* get you a 
fresher info than getting an OCSP token.