Re: [pkix] Optimizing OCSP - Time for some spec work ?
"Dr. Pala" <madwolf@openca.org> Fri, 25 October 2019 14:58 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 B082812097F for <pkix@ietfa.amsl.com>; Fri, 25 Oct 2019 07:58:11 -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 EHi6ix0drTz0 for <pkix@ietfa.amsl.com>; Fri, 25 Oct 2019 07:58:06 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEEB12090B for <pkix@ietf.org>; Fri, 25 Oct 2019 07:57:57 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 307DD3743628; Fri, 25 Oct 2019 14:57:57 +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 H933r0Q1mPRJ; Fri, 25 Oct 2019 10:57:56 -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 4B3F53742E1A; Fri, 25 Oct 2019 10:57:56 -0400 (EDT)
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, PKIX <pkix@ietf.org>
References: <31256d2d-dcfb-85f7-3850-accb2b2d6b89@openca.org> <1571969278256.43657@cs.auckland.ac.nz>
From: "Dr. Pala" <madwolf@openca.org>
Message-ID: <a87cd195-8b26-6bbd-8e37-473478e1a956@openca.org>
Date: Fri, 25 Oct 2019 08:57:55 -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: <1571969278256.43657@cs.auckland.ac.nz>
Content-Type: multipart/alternative; boundary="------------69311B1415D32AE54E276C51"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/5cB1PZ9AZXveoS9BYN5g8rmFYqw>
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 14:58:15 -0000
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] 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