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

Niklas Matthies <pkix@nmhq.net> Fri, 25 October 2019 15:20 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 841FD120105 for <pkix@ietfa.amsl.com>; Fri, 25 Oct 2019 08:20:25 -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 iyQJ-QhxtHe8 for <pkix@ietfa.amsl.com>; Fri, 25 Oct 2019 08:20:23 -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 CA274120123 for <pkix@ietf.org>; Fri, 25 Oct 2019 08:20:22 -0700 (PDT)
Received: from matthies by mail.nmhq.net with local (Exim 4.89) (envelope-from <pkix@nmhq.net>) id 1iO1Nz-0000Xo-7b for pkix@ietf.org; Fri, 25 Oct 2019 17:20:19 +0200
Date: Fri, 25 Oct 2019 17:20:19 +0200
From: Niklas Matthies <pkix@nmhq.net>
To: pkix@ietf.org
Message-ID: <20191025152019.pevdicon45ql6zml@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <a87cd195-8b26-6bbd-8e37-473478e1a956@openca.org>
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: <https://mailarchive.ietf.org/arch/msg/pkix/2IJMcsXySTaNTRFtSdY3He7uCFs>
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: Fri, 25 Oct 2019 15:20:25 -0000

Hi Max,

Just to chime in regarding the first reason: 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.
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.

Cheers,
Niklas


On Fri 2019-10-25 at 08:57h, Dr. Pala wrote on pkix:
>Hi Peter,
>
>That is a great point. I would like to explore it with you.
>
>Yes, it is possible. However, I think that did not work for two 
>reasons. If I am not mistaken (please correct me if I am wrong), the 
>first reason is that the client has to explicitly request the 
>responses for the certificates in the chain (i.e., multiple requests). 
>The second reason, I think, is related to the trust model: the 
>responder have to sign responses from different CAs instead of just 
>one - so how can I trust the response from an intermediate CA to 
>guarantee me that all CAs above me (me included) are not revoked ? It 
>might work if you use a RootCA to sign the responses... but it is not 
>common to use the RootCA keys directly... In addition to that, each 
>certificate carries the indication where its revInfo can be retrieved, 
>therefore clients tend to make single requests to the different OCSP 
>responders one by one (it might be the same, but it might be 
>different). In addition to this, there might be implications about 
>pre-computed responses
>
>As far as I know, as you say, it is possible, but I have not seen 
>clients actually querying for multiple certificates - have you ?
>
>A different model would be for the OCSP responder to be able to 
>retrieve (maybe if requested by the client w/ an extension) the 
>additional responses (as the client do today) at regular intervals and 
>attach them together with the response for the request from the 
>client. This allows to have different validity period of the responses 
>and no real trust-related dependencies (i.e., the OCSP responder will 
>re-fetch the responses that are expired and maybe cache them for the 
>validity period or part of it).
>
>From a developer point of view, maybe this approach can provide easier 
>(for the developer) query mechanism (i.e., "What is the Revocation 
>Status of Certificate X ? Can you include the responses for the full 
>chain ?" instead of ""What is the Revocation Status of Certificate X, 
>Y, and Z ?" - not being sure if this is the right responder for all of 
>them)).
>
>Does that make sense ?
>
>Cheers,
>Max
>
>
>On 10/24/19 8:07 PM, Peter Gutmann wrote:
>>Dr. Pala <madwolf@openca.org>; writes:
>>
>>>Providing Full Chain responses.
>>OCSP already does this, and has done since day 1.  That was the Identrus
>>value proposition, they would do all the checking for you and return
>>everything in a single response.  It proved... less than wildly popular.
>>
>>Peter.
>-- 
>Best Regards,
>Massimiliano Pala, Ph.D.
>OpenCA Labs Director
>OpenCA Logo

>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix