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

Niklas Matthies <> Sun, 27 October 2019 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1656D1200DE for <>; Sun, 27 Oct 2019 15:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l2F2VY1H7LwV for <>; Sun, 27 Oct 2019 15:12:33 -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 474271200D5 for <>; Sun, 27 Oct 2019 15:12:33 -0700 (PDT)
Received: from matthies by with local (Exim 4.89) (envelope-from <>) id 1iOqly-0002pf-NG for; Sun, 27 Oct 2019 23:12:30 +0100
Date: Sun, 27 Oct 2019 23:12:30 +0100
From: Niklas Matthies <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
X-Editor: VIM - Vi IMproved 8.0
X-Operating-System: Linux 4.4.112 x86_64
User-Agent: NeoMutt/20170113 (1.7.2)
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: Sun, 27 Oct 2019 22:12:35 -0000

On Fri 2019-10-25 at 23:49h, Niklas Matthies wrote on pkix:
>it would really be simpler and more flexible to just have a linear 
>sequence of regular basic responses. This could be achieved via a new 
>response type (responseType in ResponseBytes) for which the response 
>bytes consist of a sequence of basic responses instead of just one 
>basic response.

Here is an alternative idea, which, although being quite hackish, 
would be compatible with existing clients, would not require a new 
response type, while retaining the same flexibility: In the certs 
field of BasicOCSPResponse, add a dummy certificate carrying an 
extension containing the additional basic responses. That is, the 
certificate's sole purpose would be to serve as a container for the 
additional responses. The extension would have an ID identifying that 
particular purpose.

Note that both proposals have the benefit that they can be implemented 
on top of an existing OCSP responder (i.e. by a filter or proxy), as 
they don't change the data signed by the responder.