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

Peter Gutmann <> Thu, 31 October 2019 02:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5E001201A3 for <>; Wed, 30 Oct 2019 19:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 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, URIBL_BLOCKED=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 CZ6RWX304Fi6 for <>; Wed, 30 Oct 2019 19:38:10 -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 14A8A12011F for <>; Wed, 30 Oct 2019 19:38:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1572489491; x=1604025491; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=s/HQyo9wkyCUBs5jEDL3t2qLdOq+6XN2V4oNdQKtAEw=; b=q7n2yMMorHHPSvDXIjqXgf9EAC81XUoofMhjjlARw/EQapuAklU6hX24 8BQzRVr8x1CyDL/vDhSNthhxG7ToXaFCjcHmuo7q3oX1Q4Aksh4M4y5bG OVJuSzeYNW5EJ1GBCNHDpWDZpWw2G0DR2c4sNisC4o3DqcXku6NF1ijo7 mj7VgSgDeQW3Y+MIb404yjFLdqXt9yzIOt6ULniR8EGbQOprV1Lgy7ZYB N4qTxYLwVm9Jvt/F47XQGYqMw1kzymdvOMl2QLtCFtfzk/P7hlwhjjbhz ZEidGt2XUzQwT4a0qKnjXd0dJWyn8u3FLrQe2XZwf6ATHSuFrKITOK6an Q==;
X-IronPort-AV: E=Sophos;i="5.68,249,1569240000"; d="scan'208";a="97230597"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 31 Oct 2019 15:38:07 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 31 Oct 2019 15:38:06 +1300
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 31 Oct 2019 15:38:06 +1300
From: Peter Gutmann <>
To: Niklas Matthies <>, "" <>
Thread-Topic: [pkix] Optimizing OCSP - Time for some spec work ?
Thread-Index: AQHVinrq4I5nEcgfh0O9xU1lviUJBKdqnCAD///+JoCAAAZCgIACJUtogAFyqQCABdrKLw==
Date: Thu, 31 Oct 2019 02:38:05 +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: Thu, 31 Oct 2019 02:38:13 -0000

Niklas Matthies <> writes:

>In my opinion that's highly dubious, as it reverses the chain of trust. Even
>if you trust the responder to have performed that check correctly, you first
>have to validate the responder's signature before you can trust the (signed)
>extension to be authentic, [...]

Given that the current near-universal use [0] is to trust a replayed, stale
response, typically applying only to the leaf cert, and frequently not even
from the OCSP responder but from an unrelated third party (RFC 6066), this is
a considerable improvement on the current state of practice.

>Suppose that the responder has been compromised (and that it has the ocsp-
>nocheck extension): Then if the CA certificate is revoked due to that
>compromise, a client trusting the extension won't notice, as the compromised
>responder will happily (and falsely) assert that it has successfully checked
>the CA chain.

That's not any worse than the current situation, where the CA cert isn't
checked at all (unless the third-party server implements RFC 6961 and replays
stale responses for the CA certs as well as stale responses for its own cert)
[0 again].  And that's the worst-case situation, for anything other than
worst-case it's an improvement.


[0] By this I mean use in HTTPS, and I realise I'm now making the same flawed
    case that I've pointed out numerous times on the TLS WG list, assuming
    that the entire world is the web, but for OCSP this is the near-universal