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