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

Niklas Matthies <pkix@nmhq.net> Sun, 27 October 2019 22:13 UTC

Return-Path: <pkix@nmhq.net>
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 48F0D120169 for <pkix@ietfa.amsl.com>; Sun, 27 Oct 2019 15:13:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 cp-1mVce67HM for <pkix@ietfa.amsl.com>; Sun, 27 Oct 2019 15:13:00 -0700 (PDT)
Received: from mail.nmhq.net (mail.nmhq.net [95.129.49.110]) (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 03508120170 for <pkix@ietf.org>; Sun, 27 Oct 2019 15:13:00 -0700 (PDT)
Received: from matthies by mail.nmhq.net with local (Exim 4.89) (envelope-from <pkix@nmhq.net>) id 1iOqmQ-0002qP-Jd for pkix@ietf.org; Sun, 27 Oct 2019 23:12:58 +0100
Date: Sun, 27 Oct 2019 23:12:58 +0100
From: Niklas Matthies <pkix@nmhq.net>
To: pkix@ietf.org
Message-ID: <20191027221258.ldl2f5a3anu7qyfy@nmhq.net>
Mail-Followup-To: pkix@ietf.org
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> <1572088035404.16022@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <1572088035404.16022@cs.auckland.ac.nz>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/CwDmB2WldKayZxH3qddjJ0fUIf4>
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: Sun, 27 Oct 2019 22:13:06 -0000

On Sat 2019-10-26 at 11:07h, Peter Gutmann wrote on pkix:
>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.

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, and for that you 
have to validate the responder's certificate chain, which includes the 
CA that issued the certificate being revocation-checked, and hence 
whose validity the extension is supposed to confirm. This effetively 
creates a cyclic dependency of trust.

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.

>>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. 

Having implemented such a client myself, I have to concur. :)

Niklas