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

"David A. Cooper" <> Mon, 28 October 2019 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6432A1208B1 for <>; Mon, 28 Oct 2019 08:17:34 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kZQAuhca2QqX for <>; Mon, 28 Oct 2019 08:17:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F17D120890 for <>; Mon, 28 Oct 2019 08:17:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=l4KfVHk6HDgsoFkk/DRlSM1usKnDOkx/256gvUgxin+zrbXSSIfekv6oU5WsGkrHJl0VP9MDimfa5liwm8kzDB8wi+O9bJowqIll/9S2EMWOO5xDCRlQSHKOXszjkQ5HaqZf8JDnBnWBsjLIGv6pEIXQPGd9LSVO8jnqPYxeJfTNTMRUgiNLvXVhfI5KaJuY/GHeFq13kgfubQn1KZEtWxPBEkLUSrQ6fNkz+rUFgYXR3QXLXYHt0VNSZQ71PhfgQ/F1xu5m3JbVKPXaNWg9EZDB+bTlAUCEp/ddl/PBexNJWPhLtDhr+jU06p26NJ1BpYvfVT33OwJC6h2AaXRyYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AmCWg4agnU10NsJk/O3FM6SJCCs5cim3DEApQOOZz4k=; b=dnY71ik63wzKZtqqPsOiV5MRvnOV4eJEYRuZWcoLZIA6bHQbMLvItVtrUuefbgzKsi/d+vihMVOLOfq9kcP3VFfid0c4pQhCf0SsrM0rp4lIIstCFDk/6zy6lpRYSrhB/SSa8Ca0TDySd2+7KyQMnSErvBnYCA/JOoBE/ME0hlWuucPRY0gPAnxhMqThdGnCCIykYaS+9Fuf95j0EWlfY7nwMm8S8Z+MZHXB8TD6G856kRZDBSO5/apA/zbe7O62sUjZ669EyFRsDfBZRTqQSVFAF4JTPdjy3tfIDebQqaBIwtmYwJ4HfNZTKYPjr2YdqTUdIXdigePrldk29lDovA==
ARC-Authentication-Results: i=1; 1; spf=pass (sender ip is; dmarc=pass (p=reject sp=reject pct=100) action=none; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AmCWg4agnU10NsJk/O3FM6SJCCs5cim3DEApQOOZz4k=; b=Ftu2gpPv4l9waEzq7QmpLuYzYcqhcozF+FHJJ82OUDgZQZ4CnwtP46BVf9GvBZIWPZxvqHMY4obq5IAE5hpxxBH2BfciFRW4IEyzlfZcbeRsWxXm4FFxTJoEqT8bKytWQpVT2If7oIrXFagiJ7ucyQlP2A9A8zavxmDafYznLP8=
Received: from (2603:10b6:404:dc::34) by (2603:10b6:5:32::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Mon, 28 Oct 2019 15:17:31 +0000
Received: from (2a01:111:f400:7d02::201) by (2603:10b6:404:dc::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2387.22 via Frontend Transport; Mon, 28 Oct 2019 15:17:30 +0000
Authentication-Results: spf=pass (sender IP is;; dkim=none (message not signed) header.d=none;; dmarc=pass action=none;
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2387.20 via Frontend Transport; Mon, 28 Oct 2019 15:17:30 +0000
Received: from [] ([]) by with Microsoft SMTPSVC(10.0.14393.2608); Mon, 28 Oct 2019 11:17:29 -0400
To: "Dr. Pala" <>,
References: <> <> <> <> <>
From: "David A. Cooper" <>
Message-ID: <>
Date: Mon, 28 Oct 2019 11:17:33 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/html; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 28 Oct 2019 15:17:29.0069 (UTC) FILETIME=[CFF891D0:01D58DA2]
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(136003)(346002)(376002)(396003)(199004)(189003)(2906002)(31686004)(21086003)(5660300002)(23846002)(11346002)(446003)(956004)(2616005)(2870700001)(8936002)(356004)(58126008)(106002)(229853002)(6666004)(6246003)(81156014)(81166006)(316002)(31696002)(54896002)(36906005)(8676002)(86362001)(26005)(186003)(65956001)(65806001)(53546011)(2486003)(36756003)(6706004)(5024004)(14444005)(426003)(336012)(40036005)(70586007)(126002)(476003)(50466002)(486006)(70206006)(478600001)(23676004)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB3132;; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: fe2c37ca-9f21-4026-4190-08d75bb9f345
X-MS-TrafficTypeDiagnostic: DM6PR09MB3132:
X-Microsoft-Antispam-PRVS: <>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 0204F0BDE2
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 7rBf2Na7uJvMFEnKwxlIhgBB1wDr2Eayik42dB/dxf8f6shOJNJi2BLQ9sPlfJce8j3xq5NKWQQhaSMOT/TMKYkm7m6qbJLQ+BU0VSUVT6+q4Cm3dBI2uewECpbUvHztLLqy6KeMtbR/OARtbImlJzH5VTLpQbNln2wh3Q1o6lrMmRiCuDzuClumX6jYXImOSPINHiXx39Bb4bt+SxEoUGvRsP3hT8sr510vSi5Gb2LnU9N7q/e9cXGzIvJEGb19JSTR3IQ0fMtWPvZbrxHYnsCRfCKCbWf+rKxJicTmmwU2NfkQS5QprwsCVfJbxUbyUgRxJSevF+HzrCYMhGT3nawbyYtAGGpjQUvUWEWyFch7DrFeAYsmSfVW0PRZaQeOGX7J36EU+wtptGnm2y+VRcpdxP1G+tBQQO6VjUAkFK8SCRxcN53kiAPUUY/MAPen
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2019 15:17:30.3433 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: fe2c37ca-9f21-4026-4190-08d75bb9f345
X-MS-Exchange-CrossTenant-Id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=2ab5d82f-d8fa-4797-a93e-054655c61dec; Ip=[]; Helo=[]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB3132
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: Mon, 28 Oct 2019 15:17:34 -0000

Actually, this the is widely used, but not in the way you are suggesting. The use case for the text below is included in the quoted text: "to improve response pre-generation performance or cache efficiency."

Take as an example the CA that issued my PIV Authentication certificate. If I query the CA's OCSP responder about the status of my certificate I get back an OCSP response that includes status information for 20 certificates issued by that CA: my certificate and 19 others. According to the  "Produced At" time in the response, the response was generated about 45 minutes before I sent my request.

This suggests that the OCSP responder is serving pre-generated responses, and in order to speed up the pre-generation of responses, it is generating one response for every 20 certificates rather than one for every certificate.

The extra OCSP responses are not providing information about other certificates that I want to know the status of, they are providing information about other certificates that I most likely don't care about. My client just needs to know that the OCSP response may contain additional SingleResponse elements so that it knows to ignore them and to check every SingleResponse element to see if any of them covers the certificate that was asked about.

On 10/25/19 2:51 PM, Dr. Pala wrote:

Hi Niklas,

thanks for pointing that out - that paragraph is quite difficult to interpret correctly (I guess that is why nobody is attaching extra OCSP responses). In fact the text reads:

The response SHOULD NOT include any additional
   SingleResponse elements, but, for example, OCSP responders that
   pre-generate status responses might include additional SingleResponse
   elements if necessary to improve response pre-generation performance
   or cache efficiency (according to [RFC5019], Section 2.2.1).

and it starts with a SHOULD NOT :D I guess this was an attempt to provide some capability here, but did not provide the use-case for it. - therefore support for "extra" responses is quite interesting. When reading this paragraph, my first reaction as a developer is NOT to implement that feature.

Also, if you think about it, there is a Trust problem - why shall I trust this CA's responder to provide responses up in the chain ?