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

"Kemp, David P." <> Mon, 29 March 2010 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 730F73A6A1A; Mon, 29 Mar 2010 06:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.633
X-Spam-Status: No, score=-4.633 tagged_above=-999 required=5 tests=[AWL=0.836, 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 ntgf4tJpjp-G; Mon, 29 Mar 2010 06:54:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3E4473A6A67; Mon, 29 Mar 2010 06:54:07 -0700 (PDT)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 29 Mar 2010 09:54:33 -0400
Message-ID: <>
In-Reply-To: <17FD76C1ECD0AB49817637E21809ABF907FAA70D24@IMCMBX2.MITRE.ORG>
Thread-Topic: [pkix] Possible revocation delay issue with TLS stapling
References: <op.u95kjftmkvaitl@lessa-ii><17FD76C1ECD0AB49817637E21809ABF907FAA70D19@IMCMBX2.MITRE.ORG><op.u9610i13kvaitl@lessa-ii> <17FD76C1ECD0AB49817637E21809ABF907FAA70D24@IMCMBX2.MITRE.ORG>
From: "Kemp, David P." <>
To: <>, <>
X-OriginalArrivalTime: 29 Mar 2010 13:55:33.0875 (UTC) FILETIME=[807C7C30:01CACF47]
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: Mon, 29 Mar 2010 13:54:29 -0000

That only gets you halfway there, since the nonce only ensures freshness
back to the OCSP responder, not the revocation authority.  The responder
itself can get revocation updates using any of the strategies you
mentioned (on every query - e.g. database backend, only after CRL
nextUpdate, somewhere in between, only after somewhere beyond

If you *really, really* care, insist on CRLs.  But that would require
reasonable-sized CRLs (10Kb) with reasonably short nextUpdate (24h),
neither of which DoD currently produces.

It would also help to have a low-overhead (UDP-based with DTLS symmetric
integrity) CRL query protocol with an "I have this one, send me a newer
one if it exists" semantics.


-----Original Message-----
From: Miller, Timothy J

Which throws us back on "If you *really* care, insist on nonces."