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

[Ryan Sleevi <[e-mail]>]

On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala <[e-mail]> 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.
>
> 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.
>
Don't CRLs address this use case?

That is, it's not clear "Why OCSP" vs "Why not something else" in your
overall message here.

> 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
>
> On a conceptual level, how is the concept of "Signed status information
for a range of certificates" functionally or conceptually different than a
CRL, potentially sharded (e.g. by varying the issuerDistributionPoint
extension within the CRL and the crlDistributionPoint within the range of
certificates).

As best I can tell, the only difference is that it allows the CA to
rebalance the ranges post-issuance, but it's unclear if that's either good
or desirable from a validator perspective.


>
>    - *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.
>
> Similarly, this is unclear the set of problems you're trying to solve. Did
you mean to provide status information about the full chain? Or did you
actually meant the full chain?

Clients already presumably have the full chain, as they're using OCSP in
the context of RFC 5280 path validation. If the goal is to be able to use
this within protocols that make OCSP available (e.g. TLS), then you already
have the means to deliver the additional certificates.

So I'm not sure how to interpret this suggestion here, and/or why OCSP is
somehow the appropriate technology for it.