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

Kurt Roeckx <kurt@roeckx.be> Thu, 24 October 2019 15:14 UTC

Return-Path: <kurt@roeckx.be>
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 6EB3E12080C for <pkix@ietfa.amsl.com>; Thu, 24 Oct 2019 08:14:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 6Ne3djb_9t0M for <pkix@ietfa.amsl.com>; Thu, 24 Oct 2019 08:14:02 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 6F729120154 for <pkix@ietf.org>; Thu, 24 Oct 2019 08:14:02 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 7C1E4A8A03BE; Thu, 24 Oct 2019 15:14:00 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 068EA1FE0C37; Thu, 24 Oct 2019 17:13:59 +0200 (CEST)
Date: Thu, 24 Oct 2019 17:13:59 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: "Dr. Pala" <madwolf@openca.org>
Cc: PKIX <pkix@ietf.org>
Message-ID: <20191024151359.GE6530@roeckx.be>
References: <31256d2d-dcfb-85f7-3850-accb2b2d6b89@openca.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <31256d2d-dcfb-85f7-3850-accb2b2d6b89@openca.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/PVGdj6RRaPQI3PKSVSMK8tVC284>
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: Thu, 24 Oct 2019 15:14:04 -0000

On Thu, Oct 24, 2019 at 08:53:59AM -0600, Dr. Pala wrote:
> Our work is focusing on two considerations:
> 
>  * Optimizing for the common case (non-revoked certificate). In
>    particular, for certificates that have no revocation information, we
>    do not have to provide specific responses for each individual
>    certificate (as we do in the revoked case), but we can provide
>    responses for ranges of certificates where the status is not
>    revoked. In a PKI with a population of 100M certificate and a
>    revocation rate of 5%, using "range" response types reduces the need
>    for calculating OCSP responses from 100M to 1M (i.e. 2N + 1 where N
>    is the population of revoked certificates). This allows to
>    pre-generate responses more quickly, allows for lower costs of
>    running the revocation infrastructure, and it is better for the
>    planet :D

I don't see how that can work if you're not allowed to return good
for a non-issued certificate and that the serial numbers should
be random.


Kurt