Re: [pkix] Optimizing OCSP - Time for some spec work ?
"Dr. Pala" <madwolf@openca.org> Fri, 25 October 2019 18:51 UTC
Return-Path: <madwolf@openca.org>
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 22692120113 for <pkix@ietfa.amsl.com>; Fri, 25 Oct 2019 11:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 VsD2uEzXQadz for <pkix@ietfa.amsl.com>; Fri, 25 Oct 2019 11:51:40 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05412004D for <pkix@ietf.org>; Fri, 25 Oct 2019 11:51:40 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 0D9623741074 for <pkix@ietf.org>; Fri, 25 Oct 2019 18:51:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t2hnwJmA99a4 for <pkix@ietf.org>; Fri, 25 Oct 2019 14:51:38 -0400 (EDT)
Received: from Maxs-MBP-2.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id D3D273741035 for <pkix@ietf.org>; Fri, 25 Oct 2019 14:51:37 -0400 (EDT)
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>
From: "Dr. Pala" <madwolf@openca.org>
Message-ID: <4378c2a4-dc0e-4bc4-e43a-fa612cfc65dc@openca.org>
Date: Fri, 25 Oct 2019 12:51:37 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191025152019.pevdicon45ql6zml@nmhq.net>
Content-Type: multipart/alternative; boundary="------------DE69F948501C982FDCE802F1"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/boktUXyWI25uCK_omxpDQn5qAnQ>
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 18:51:43 -0000
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 ? If the inclusion of the additional responses would encapsulate their authentication information, then we could trust those additional responses... otherwise, if not locally configured, the responder is not authoritative for other CAs. If your OCSP responder supports multiple CAs and could be authoritative for all of them... which certificate will your responder use to sign the response (i.e., shall it use the certificate that makes it authoritative for the requested certificate or the one that makes it authoritative for the issuing CA status ?) Therefore, although it is technically possible, I think the way it is specified now it is not really usable. Do you know of implementation that use this feature? If so, do you know how they solved the Trust issue here ? Ultimately, coming to using extensions in the requests - that is an interesting option (what about attaching the responses of the upper links in the chain as an extension in the basic response ?), however this complicates the implementation server-side ==> In general, whenever you add the possibility for the client to influence the content of the response, responses need to be generated according to the client-provided parameters, and, therefore, they cannot be pre-computed (which I think can be easily implemented if the number of target responses is sufficiently limited - i.e., your revoked certificates population is small enough that live responders calculate, cache, and update all responses 'live' with great performance and that do not require lots of resources). Thanks again for the feedback! Also, would you like to contribute to the effort shall we (IETF) decide to tackle this problem ? Cheers, Max On 10/25/19 9:20 AM, Niklas Matthies wrote: > 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 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo
- [pkix] Optimizing OCSP - Time for some spec work ? Dr. Pala
- Re: [pkix] Optimizing OCSP - Time for some spec w… Kurt Roeckx
- Re: [pkix] Optimizing OCSP - Time for some spec w… Denis
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann
- Re: [pkix] Optimizing OCSP - Time for some spec w… Todd E. Johnson
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann
- Re: [pkix] Optimizing OCSP - Time for some spec w… Todd E. Johnson
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann
- Re: [pkix] Optimizing OCSP - Time for some spec w… Dr. Pala
- Re: [pkix] Optimizing OCSP - Time for some spec w… Niklas Matthies
- Re: [pkix] Optimizing OCSP - Time for some spec w… Dr. Pala
- Re: [pkix] Optimizing OCSP - Time for some spec w… Dr. Pala
- Re: [pkix] Optimizing OCSP - Time for some spec w… Russ Housley
- Re: [pkix] Optimizing OCSP - Time for some spec w… Niklas Matthies
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann
- Re: [pkix] Optimizing OCSP - Time for some spec w… Niklas Matthies
- Re: [pkix] Optimizing OCSP - Time for some spec w… Niklas Matthies
- Re: [pkix] Optimizing OCSP - Time for some spec w… David A. Cooper
- Re: [pkix] Optimizing OCSP - Time for some spec w… David A. Cooper
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann
- Re: [pkix] Optimizing OCSP - Time for some spec w… Peter Gutmann