Re: [lamps] The Status of OCSP and its future
"Dr. Pala" <madwolf@openca.org> Fri, 25 October 2019 14:41 UTC
Return-Path: <madwolf@openca.org>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940AE120072 for <spasm@ietfa.amsl.com>; Fri, 25 Oct 2019 07:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level:
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 cYbr4XfIaolQ for <spasm@ietfa.amsl.com>; Fri, 25 Oct 2019 07:41:24 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id D4F0E120118 for <spasm@ietf.org>; Fri, 25 Oct 2019 07:41:24 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 915B4374137D; Fri, 25 Oct 2019 14:41:24 +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 GmY6BlVn_7DF; Fri, 25 Oct 2019 10:41:23 -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 C05173741035; Fri, 25 Oct 2019 10:41:23 -0400 (EDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: LAMPS WG <spasm@ietf.org>
References: <8c84cf2c-c192-c13b-17e5-7ae09b748530@openca.org> <5837.1571944259@localhost>
From: "Dr. Pala" <madwolf@openca.org>
Message-ID: <944cc3f3-8df5-740b-a7e9-6083dd834b72@openca.org>
Date: Fri, 25 Oct 2019 08:41:23 -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: <5837.1571944259@localhost>
Content-Type: multipart/alternative; boundary="------------07638E383EAB31F334BDEBAF"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/q5GTb51NM-u9Q7EmDUJm65WLdz4>
Subject: Re: [lamps] The Status of OCSP and its future
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2019 14:41:25 -0000
Hi Michael, On 10/24/19 1:10 PM, Michael Richardson wrote: > Dr. Pala <madwolf@openca.org> wrote: > > Specifically, for very large PKIs (i.e., few hundreds million > [...] > > providing a good revocation infrastructure is. > > Why not just spread your load across multiple OCSP endpoints by putting > different AuthorityInfoAccess values in? thanks for the comment - yes, I think that is an option. However, that does add complexity to the issuing system that might need to be tweaked as the infrastructure grows... and that does not lower my operational costs that can be significant for large PKI environments. The proposal here is to optimize for the average case (and maybe simplify the messages in the process) - in particular providing responses for ranges of certificates (serial) where there is no revocation information available. Although this is quite relevant for the Industry I work in (Cable), optimizing revocation information distribution might lower the operational cost for every PKI that implements revocation - the WebPKI included. In particular, if such a solution existed, then we could see OCSP responses for the WebPKI that have shorter validity periods, I think and hope: hours instead of days or months. Thanks again for the feedback! Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo
- [lamps] The Status of OCSP and its future Dr. Pala
- Re: [lamps] The Status of OCSP and its future Ryan Sleevi
- Re: [lamps] The Status of OCSP and its future Phillip Hallam-Baker
- Re: [lamps] The Status of OCSP and its future Michael Richardson
- Re: [lamps] The Status of OCSP and its future Tomas Gustavsson
- Re: [lamps] The Status of OCSP and its future Dmitry Belyavsky
- Re: [lamps] The Status of OCSP and its future Tomas Gustavsson
- Re: [lamps] The Status of OCSP and its future Dr. Pala
- Re: [lamps] The Status of OCSP and its future Dr. Pala
- Re: [lamps] The Status of OCSP and its future Phillip Hallam-Baker
- Re: [lamps] The Status of OCSP and its future Dr. Pala
- Re: [lamps] The Status of OCSP and its future Dr. Pala
- Re: [lamps] The Status of OCSP and its future Ryan Sleevi
- Re: [lamps] The Status of OCSP and its future Phillip Hallam-Baker
- Re: [lamps] The Status of OCSP and its future Tomas Gustavsson