IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 26 October 2019 11:07 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6269120048 for <pkix@ietfa.amsl.com>; Sat, 26 Oct 2019 04:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq8TKpIYHQZK for <pkix@ietfa.amsl.com>; Sat, 26 Oct 2019 04:07:21 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1291E12002F for <pkix@ietf.org>; Sat, 26 Oct 2019 04:07:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1572088042; x=1603624042; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=V0dKGsdrt9UzC0dQ6Y1ki20TlLv7CReH7lvmOrpLK0U=; b=eC+UpAsSFFmVHBKjNTJQClMQZoOHsGgQpwi9QbuF45Nyqjkw5XIHQCjc AtwUKSxh7VihSY/elCgaQdfnKzfxCW8FFhONAK9FfvnGsCOxgLgVuFfGr LjgiZviRGw15rSiYMJCA+nUPFaajFsVQJFN5x5JzzE/mu0FdRSQEIoO7M wbInur7gwIo1YS18Uo+LvI/xHsE2Z0AT8NIMDEdRDX8zDHV7UN8Nf24sI slN4wDKIzRQNjtVPdifMveDXYodXhP2u5ioe+ehABvlPKPETKBEvNx03x lV8WbWbE19KKeY5OU3hn9FmwHUPostSM+WgamR5TEyBqbBwcGYT6InaSI g==;
X-IronPort-AV: E=Sophos;i="5.68,232,1569240000"; d="scan'208";a="96225091"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing
Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Oct 2019 00:07:17 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 27 Oct 2019 00:07:15 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sun, 27 Oct 2019 00:07:15 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Niklas Matthies <pkix@nmhq.net>, "pkix@ietf.org" <pkix@ietf.org>
Thread-Topic: [pkix] Optimizing OCSP - Time for some spec work ?
Thread-Index: AQHVinrq4I5nEcgfh0O9xU1lviUJBKdqnCAD///+JoCAAAZCgIACJUto
Date: Sat, 26 Oct 2019 11:07:15 +0000
Message-ID: <1572088035404.16022@cs.auckland.ac.nz>
References: <31256d2d-dcfb-85f7-3850-accb2b2d6b89@openca.org> <1571969278256.43657@cs.auckland.ac.nz> <a87cd195-8b26-6bbd-8e37-473478e1a956@openca.org>, <20191025152019.pevdicon45ql6zml@nmhq.net>
In-Reply-To: <20191025152019.pevdicon45ql6zml@nmhq.net>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/h0ZW-Wkq-VRVfbBVlMewMfa8bpY>
Subject: Re: [pkix] Optimizing OCSP - Time for some spec work ?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Oct 2019 11:07:24 -0000

Niklas Matthies <pkix@nmhq.net> writes:

>To make the additional responses optional (controlled by the client), a
>corresponding request extension could be defined. Hence that aspect could be
>covered by specifying a profile of the current OCSP protocol.

You could also do a simpler version where the responder includes an extension
that says "I've checked the entire chain from the cert you requested all the
way up to the root.  You're welcome".  It'd be fully compatible with current
deployments, and if clients are able to process the extension they get extra
value from it.

>OCSP responses are allowed to include additional single responses that
>weren't explicitly requested by the client, see RFC 6960 section 4.2.2.3 last
>paragraph.

At one point this was tested and the it was found that the number of
responders/clients who could handle more than one entry per OCSP query and who
hadn't been set up explicitly to work with the Indentrus trust model, which
requires multiple entries, was approximately zero.  So possibly the "I've
verified all the certs up to the root" extension would be easier to get
deployed.

Peter.

v2.23.0 | Report a Bug | By Email