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

[Denis <[e-mail]>]

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.

Denis

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix