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

Denis <> Thu, 24 October 2019 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A94C9120908 for <>; Thu, 24 Oct 2019 08:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kcUKuxuzLKk5 for <>; Thu, 24 Oct 2019 08:19:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D106F1208DC for <>; Thu, 24 Oct 2019 08:19:37 -0700 (PDT)
Received: from [] ([]) by mwinf5d65 with ME id HTKY2100e0gNo7u03TKZ9n; Thu, 24 Oct 2019 17:19:35 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 24 Oct 2019 17:19:35 +0200
References: <>
From: Denis <>
Message-ID: <>
Date: Thu, 24 Oct 2019 17:19:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------3D358858FA97085731E6D2A6"
Content-Language: en-US
Archived-At: <>
Subject: Re: [pkix] Optimizing OCSP - Time for some spec work ?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Oct 2019 15:19:42 -0000

Hello Max,

What you are proposing is not an optimization of OCSP but something 
different, so please don't call it "optimizing OCSP".

    "Optimizing for the common case (non-revoked certificate)" by
    pre-computing responses has implications about the timeliness of the
    revocation date and time.
    As Kurt just mentioned, I don't see either how this can work given
    the fact that certificate serial numbers should be random.

    "Providing Full chain responses" seems to be close to RFC 5055:
    Server-Based Certificate Validation Protocol (SCVP).
    When you take a look at the complexity of this protocol, the key
    question that comes to my mind is what kind of
    differences/simplifications you would be expecting.

As you know, the best way to continue the discussion would be to propose 
a title, an introduction and possibly an overview.
RFC 5055 (as well as OCSP) would need to be positioned in the Introduction.


> 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 mailing list