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

"Miller, Timothy J." <> Fri, 26 March 2010 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C50423A67A6; Fri, 26 Mar 2010 06:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.469
X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oV3RINs7fdBL; Fri, 26 Mar 2010 06:02:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 844533A6782; Fri, 26 Mar 2010 06:02:06 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.1/8.13.1) with ESMTP id o2QD2TMY012362; Fri, 26 Mar 2010 09:02:29 -0400
Received: from imchub1.MITRE.ORG ( []) by (8.13.1/8.13.1) with ESMTP id o2QD2Tes012354; Fri, 26 Mar 2010 09:02:29 -0400
Received: from IMCMBX2.MITRE.ORG ([]) by imchub1.MITRE.ORG ([]) with mapi; Fri, 26 Mar 2010 09:02:29 -0400
From: "Miller, Timothy J." <>
To: "'Jean-Marc Desperrier'" <>, "" <>, "" <>
Date: Fri, 26 Mar 2010 09:02:28 -0400
Thread-Topic: [pkix] Possible revocation delay issue with TLS stapling
Thread-Index: AcrMyGyPIaq3Dy28QGCMd5Uv0+IDhQAHAwgQ
Message-ID: <17FD76C1ECD0AB49817637E21809ABF907FAA70D1B@IMCMBX2.MITRE.ORG>
References: <op.u95kjftmkvaitl@lessa-ii> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Mar 2010 13:02:07 -0000

Clients concerned with OCSP response freshness can always insist on nonces, and fall back on CRLs if the OCSP service won't support them.

-- Tim

>-----Original Message-----
>From: [] On Behalf Of
>Jean-Marc Desperrier
>Sent: Friday, March 26, 2010 4:40 AM
>Subject: Re: [pkix] Possible revocation delay issue with TLS stapling
>Sean Leonard wrote:
>> 2.(a) Your suggestion says that "servers" must include this extension
>> requests. How does the OCSP responder verify that the requester is a
>> "server"? It cannot. So, if the CA is concerned about the staleness
>> problem, why not just update OCSP information for all OCSP requests on
>> shorter interval?
>The operational cost of the short interval is higher.
>So with that extension the server is saying : I'm highly sensitive *and*
>I'll optimize your network load, therefore trying to optimize your costs
>by giving me a long lived response is not the optimal strategy. Please
>give me a truer response of when you'll really be able to have fresher
>What you write in details later is true, this is just an optimization,
>different strategy could be used to not need it, and it will work only
>if the client checks this extension.
>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.
>So this is a specific case where the CA could make sure the staple OCSP
>request always hits the very latest CRL, whereas there's an interval
>where standard OCSP request are not yet updated to it, and using a still
>trustworthy (earlier than next update) CRL but not actually the very
>latest produced CRL.
>So the question is just, is this sufficiently useful to deserve being
>added to the standard ?
>Just one more thing, I'm thinking now that one strategy for the server
>can be to guarantee a 20 ms response delay on standard requests, but
>have a 1 or 2 seconds delay for a staple ready answer. It's then up to
>the client to decide if he wants slow but best, or fast but maybe less
>pkix mailing list