[pkix] Optimizing OCSP - Time for some spec work ?
"Dr. Pala" <madwolf@openca.org> Thu, 24 October 2019 14:54 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 E12511209DE for <pkix@ietfa.amsl.com>; Thu, 24 Oct 2019 07:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, 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 fOp5D5K9EbYQ for <pkix@ietfa.amsl.com>; Thu, 24 Oct 2019 07:54:01 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0BC120DD2 for <pkix@ietf.org>; Thu, 24 Oct 2019 07:54:01 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id BF4DE374137D for <pkix@ietf.org>; Thu, 24 Oct 2019 14:54:00 +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 XL2xinovfBCb for <pkix@ietf.org>; Thu, 24 Oct 2019 10:53:59 -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 C0999374107C for <pkix@ietf.org>; Thu, 24 Oct 2019 10:53:59 -0400 (EDT)
To: PKIX <pkix@ietf.org>
From: "Dr. Pala" <madwolf@openca.org>
Message-ID: <31256d2d-dcfb-85f7-3850-accb2b2d6b89@openca.org>
Date: Thu, 24 Oct 2019 08:53:59 -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
Content-Type: multipart/alternative; boundary="------------1EFB2081F6EF8A0B8FCE1CC9"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/eGE53uJIYKSzu7pObiUGWNXDH3M>
Subject: [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 14:54:04 -0000
Hi PKIX Gurus, I am working on trying to optimize the OCSP protocol to better fit some of the use-cases we have. In particular, for very large PKIs (i.e., few hundreds million certificates valid at any given time), the OCSP protocol does not scale well. In fact, taking into consideration how we operate OCSP responders today, the larger the PKI is, the higher the costs of providing a good revocation infrastructure. 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 * Providing Full Chain responses. Although single OCSP responders can be authoritative for their own CA only, they can attach the responses for the full chain as additional data. If we add this possibility, then a single OCSP request can provide the client/server with the full chain of certificates up to the Root. This might be tricky in complex scenarios where cross-certification is used, but it would definitely work for the Web PKI and IoT use cases. Given these considerations - and the fact that large PKIs are being deployed, today, for the IoT case - we would like to discuss the current status of OCSP and our proposal for moving forward with a more efficient protocol at the meeting in Singapore (IETF 106) - LAMPS WG. If you are interested in the topic and/or would like to contribute, we will be presenting there - come and join the discussion! Cheers, Max -- 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