Re: [pkix] Optimizing OCSP - Time for some spec work ?

Peter Gutmann <> Fri, 25 October 2019 02:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02D2712003F for <>; Thu, 24 Oct 2019 19:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8EV_qmB-eEyn for <>; Thu, 24 Oct 2019 19:00:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 48C81120018 for <>; Thu, 24 Oct 2019 19:00:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1571968841; x=1603504841; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=K5aaEuSc0dQVi+lAdU3dv958AoPDsDd9ES77l+84M9c=; b=fi77trFuuQ9Go/oMIRrcJfLH1HGEF4ZSZbTd0/dFUz50Yphevk98Htgj 1X1IlZvqsU8GlyzNGvOw7GZN0xeiatrigjfI7/stPAXp2L+g73pUTqGi9 Q+oGRlenSIPpSth+wXL5pmCWa+6KGQYTsR6Ghlhhh992kAvs/vaGCaCVZ dLd+BFmps6DrFKsOS0VaV0lK3Wk6hFFSJXARavB9zPVcXRLKKoPuCWWCy /KW+LNzqJ8zesV2AEJ9KJ9DFT/QuDf3bOn+iBijnqbBLzurW6NgpKK5zP X7RfR2Hx/aKHk0x8Zra42NvntFOXy6RSJY6HfqpsrrYMR55Dt0vEmKO9s A==;
X-IronPort-AV: E=Sophos;i="5.68,226,1569240000"; d="scan'208";a="95974539"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 25 Oct 2019 15:00:37 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 25 Oct 2019 15:00:36 +1300
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Fri, 25 Oct 2019 15:00:35 +1300
From: Peter Gutmann <>
To: Denis <>, "" <>
Thread-Topic: [pkix] Optimizing OCSP - Time for some spec work ?
Thread-Index: AQHVinrq4I5nEcgfh0O9xU1lviUJBKdpDfqAgAGMs/4=
Date: Fri, 25 Oct 2019 02:00:35 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [pkix] Optimizing OCSP - Time for some spec work ?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Oct 2019 02:00:43 -0000

Denis <> writes:

>What you are proposing is not an optimization of OCSP but something 

It is very definitely an optimisation of OCSP, and in particular one that's 
far better than the current "optimisation" of droppping the nonce and 
accepting replayed responses as current as a hack to deal with OCSP's 

The only concern I'd have is that it'd need to have some data on how
effective it'll actually be in practice.  Let's say you have x% loading due
to revocations, so x% of all certs are revoked, and also y% loading of cert
statuses, so y% of certs are actively queried via OCSP.  At what point does
x get high enough that the fragmentation of the serial number ranges negates
any specific benefit from pre-generating responses for a subrange, and how 
much mitigation do different y values provide for the fragmentation issue?

So it'd need a research publication to demonstrate there's a benefit, and
under what conditions, after which it'd certainly be a better bugfix for
OCSP than the accept-replayed-responses kludge.