Re: [lamps] The Status of OCSP and its future

[Tomas Gustavsson <[e-mail]>]

On 2019-10-24 17:01, Dr. Pala wrote:
> Hi All,
> 
> I just wanted to start the conversation around the status of revocation
> infrastructures and possible work we can be doing to address some of new
> issues deriving from the deployment of large PKIs. In particular, we are
> working on the optimization of the OCSP protocol to better serve some of
> the use-cases we have.
> 
> Specifically, 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 is.

As there are many PKIs today with 100M+ entities, some with and some
without revocation infrastructure, I think it's a bit too broad claim
for all use cases.
It is certainly true of all operations, the larger the scale the larger
infrastructure costs usually are, where OCSP I'd say is generally a very
minor part.
It differs from use case to use case though, I think it would be good
for the discussion to provide more details on your problematic use case,
architecture, use pattern etc. Many things are use case and
implementation choice specific.

> 
> Our approach stem from two practical considerations: the occasion to
> provide optimized responses for the non-revoked case, and the
> possibility to reduce the number of round trips required to retrieve the
> revocation status for the full chain of certificates. In particular:
> 
>   * /*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

What could a "range" of certificates be based on?
(I consider sequential serialnumbers to be dead by now)

> 
>   * /*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.

If extra round-tripping is needed it is certainly a concern. This is
also valid and discussed in the Web PKI case.

> 
> Given these considerations - and the fact that large PKIs are being
> deployed, today, for the IoT case - we would like to start the
> discussion around the current status of OCSP and possibly work on a
> proposal for moving forward with a more efficient protocol.

We do se working use cases with OCSP for huge number of devices, but in
IoT it's all use case dependent so I'm interested in more on your use case.

> 
> What do you think ? Anybody would like to tackle this problem together ?
> 
> Cheers,
> Max
> 
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo
> 
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>