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

["Dr. Pala" <[e-mail]>]

Hi Peter,

On 10/24/19 8:00 PM, Peter Gutmann wrote:
> Denis <[e-mail]> writes:
>
>> What you are proposing is not an optimization of OCSP but something
>> different
> It is very definitely an optimisation of OCSP, and in particular one that's
> far better than the current "optimisation" of droppping the nonce and
> accepting replayed responses as current as a hack to deal with OCSP's
> non-scalability.
>
> The only concern I'd have is that it'd need to have some data on how
> effective it'll actually be in practice.  Let's say you have x% loading due
> to revocations, so x% of all certs are revoked, and also y% loading of cert
> statuses, so y% of certs are actively queried via OCSP.  At what point does
> x get high enough that the fragmentation of the serial number ranges negates
> any specific benefit from pre-generating responses for a subrange, and how
> much mitigation do different y values provide for the fragmentation issue?
>
> So it'd need a research publication to demonstrate there's a benefit, and
> under what conditions, after which it'd certainly be a better bugfix for
> OCSP than the accept-replayed-responses kludge.

Yes, that is the right thing to do. I am trying to work on a quick 
implementation so that I would collect some practical data around it. 
However, I think there might be some theoretical approach we can also 
use to quantify benefits based on, at a minimum, projected size of the 
PKI and the number of revoked certificates: the lower the revocation 
ratio is (revoked certificates / total valid population), the lower the 
costs of pre-computation for the whole population is.

It is interesting to notice that this solution makes the costs 
associated with the revocation infrastructure to be directly correlated 
to the number of revoked certificates, instead of the number of issued 
certificates, thus shifting the paradigm quite a bit (thus with good 
architecture for your PKI that minimizes revocation events, this 
solution can provide very economic revocation information distribution.)

FYI, I started the conversation also in the LAMPS WG and will present 
(hopefully we will get the slot) on this issue at the Singapore's 
meeting - there we are trying to raise interest in working on this topic 
- so that we can understand what are the chances there to make the world 
a better place :D After that, depending on how much interest we get, we 
might go with SecDispatch or IESG individual submission (we need some 
standardization for our industry at least).

Last but not least, I am now thinking about demonstrating the benefits 
related to this idea and one of the aspects to consider is about CRLs 
vs. OCSP. Also in that case, the benefits of deploying OCSP is only when 
CRLs grow beyond a certain size - the problem here is that, although we 
can come up with a threshold figure there, clients would never know, 
beforehand, which path is the optimal one ... (CRLs, OCSP v1, or OCSP v2 
?) ... at any given time (i.e., that changes with the changes in the 
trust infrastructure)

In case there is interest, would you like to participate in the effort ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo