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