Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare)

Nick Sullivan <> Wed, 20 November 2019 05:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71A9A120A8E for <>; Tue, 19 Nov 2019 21:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AWPjVmK4FKEU for <>; Tue, 19 Nov 2019 21:08:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4FDA1120840 for <>; Tue, 19 Nov 2019 21:08:06 -0800 (PST)
Received: by with SMTP id x21so15988513vsp.6 for <>; Tue, 19 Nov 2019 21:08:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f+S4nbEgxNrqD4+Ld/z2ike+T8WepUOA7o9ydQtOaJQ=; b=pqMiHxl6CmKZ8lgnDPFzTscJwuZPixwDC2xq4k8gGL9cJ3dlXTbfGPs43SLQIMCjkK Dv9acoPBQH6M9Iw4KV1Bf4GmqsdnbOA+7f5qW8HrVHqgjkZJy8Da9LaDFc7TVJIJkzEh 8lsUeyISMATtWO6VL4CZFCTBx/4sxqu56AtaI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f+S4nbEgxNrqD4+Ld/z2ike+T8WepUOA7o9ydQtOaJQ=; b=KTy6bUUk41gOmo3lsUgfK0G2tRDEdafaBjKrKQ2T/OAnR7nFrn3DRb7DJgdeJ4QFoS w0wlMoxodFriVXDCTpd21PNL9c2MQp+IJLcLoUzRdxLQ55JEnUeUjwcQ2dYfCQpV9QZE dXUoTmYe6khYSyaaSHNYaGeI013tsghdrR83Z3Pk/LBCw2+eD+fqSxNpu6iCY0klqXwT 9Qyk0KUJJrIvtzAMDL913GqdRJXEAa87Q8++YLFomhCwUqBk8lH+RtMVQODY3dSXi2vj scCtYl5+VNEhph3lIiubwifXAYkZAG8paqbsbdJchp7136f3wg23cTkgg2SmuOXak3jg yyMw==
X-Gm-Message-State: APjAAAWTO4umqyLgkzgbuTohBfPqc7Bvi3dXqwXKFEHwFiz9nce1lWIu HcQubQrV29D5avPbgCDcCwszsuJjKlV01nJL8xJn1Q==
X-Google-Smtp-Source: APXvYqy7baKdti40rAZWDbVfNheltYSCG5XORLXZmXVZPmU95NzXjwlFKAUhnN5kgh0tePP78ltdsqyoSj2eDTXO5SM=
X-Received: by 2002:a67:5d02:: with SMTP id r2mr425906vsb.212.1574226484978; Tue, 19 Nov 2019 21:08:04 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Nick Sullivan <>
Date: Wed, 20 Nov 2019 13:07:48 +0800
Message-ID: <>
To: "Dr. Pala" <>
Cc: IETF SecDispatch <>, Tim Hollebeek <>
Content-Type: multipart/related; boundary="0000000000006fcc220597c02a02"
Archived-At: <>
Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Nov 2019 05:08:11 -0000

Hi Max,

Thanks for your clarification. I now understand the work is aimed at
optimizing the number of signatures by the CA's OCSP responder and the
number of bytes of unique OCSP data.

Currently, the number of OCSP signatures the CA needs to do is linear in
the number of active certificates. This proposal changes this so that the
number of signatures is linear in the number of revocations of active
certificates. It's conceptually similar to NSEC in that way: it's a cover
proposal in which the artifacts are constant size, but require a linear
number signatures in the size of the revocation set. Contrast this with
CRLs, which require a constant number of signatures, but are linear in the
size of the revocation set. So maybe the goals could be better phrased in
terms of *lowering the cost of generating compared to OCSP
and distributing compared to CRLs*.

This proposal implies a middle-ground PKI deployment that has enough
revocations for CRL to be inefficient but not enough to cause the negative
space of the serial number to be of the same order as the number of
certificates. It would be great to see examples of PKIs that motivate this
optimization, which is why I suggested that data could help.

I should also note that while this proposal reduces the number of OCSP
signatures (which can be on the order of 104 signatures for 2-year certs),
the impact is less dramatic for CAs that issue shorter-lived certs. For
example, Let's Encrypt only signs around 13 OCSP responses for each of
their 3-month certificates.


On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <> wrote:

> Hi Nick, all,
> at the end of the second presentation on lowering the costs of revocation,
> if I am not mistaken, your question/comment (Nick) was about the fact that
> Cloudflare hosts / serve most of the cached OCSP responses and that the
> system does not have issues.
> I am not sure if this comment is pertinent to what we are trying to solve
> here... let me elaborate a bit more.
> The work we have been doing around the proposed topic of work is aimed at *lowering
> the cost of generating and distributing these large volumes of signed data*
> when there is actually no need for that. By optimizing the protocol to
> provide range responses (or other methods, if we decide to go with a
> different approaches), we can reduce the number of signatures needed from a
> CA and their distribution - very expensive operations.
> In other words, the proposal is *not aimed at fixing any caching issues*
> because, as you noticed in your comment, that works just fine. The proposal
> at hand, instead, is about fixing a problem that CAs are facing today -
> high costs of deploying and running such systems.
> On the other hand, your comment made me think about the caching service
> you mentioned and its associated costs.
> Is it a service for which your company charge CAs ? If so, would you be
> able to share what are currently the costs incurred by CAs to leverage your
> service ? (I totally understand if you are not willing to - after all, this
> is usually the secret sauce :D)
> Last but not least, I also would like to point out that optimizing the
> revocation can also help open-source communities, small companies,
> universities, non-profit, etc. by enabling them to deploy cost-efficient
> systems that can provide good quality of service using less resources
> (computational, storage, network).
> Please let me know,
> Cheers,
> Max
> P.S.: If we could combine this idea with OCSP over DNS, we could really
> provide access to revocation technology for everybody, not just who can
> afford the price. Unfortunately we know how that discussion went, and I
> still think it is a very evident mistake not doing it  (I am still working
> on this in my spare time - I think it is of enormous value for emerging
> countries to have access to cheap secure technologies and, in my opinion,
> IETF is dropping / has dropped the ball on this for not-so-honorable
> reasons, I suspect...). I hope We can fix it in the open-source community.
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> [image: OpenCA Logo]