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

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

Hi Ryan,

On 10/24/19 9:37 AM, Ryan Sleevi wrote:
>
>
> On Thu, Oct 24, 2019 at 11:01 AM Dr. Pala <[e-mail] 
> <mailto:[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 [...]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?
Yes and No. "Yes" because CRLs provide the same type of information - 
you are correct :D "No" because CRLs provide all the information at once 
- the reason we have OCSP today is to address the "Large CRLs" problem.
> That is, it's not clear "Why OCSP" vs "Why not something else" in your 
> overall message here.

Well, I do not want to exclude the possibility to work on "something 
else" :D

Our proposal is to provide a more efficient way to deliver the service 
that can still be used with current protocols (e.g., OCSP stapling) - 
this addresses the medium-term deployment and, we believe, provide an 
additional tool for the PKI architects when planning / designing the 
revocation infrastructure for their PKIs.

If there are other proposals on the table for improving efficiency, it 
would be great to hear them - this can spark an healthy discussion 
around handling revocation in PKIX (maybe a dedicated WG if LAMPS is not 
the right place... ?) :D However, until then, our proposal is to work on 
something rather than not do anything :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.
I think you got it right :D The main difference is that the 
issuerDistributionPoint is a static assignment and that might not be 
optimal. As you point out, it is a possibility today to do this, however 
there is no guarantee for the client that the target CRLs will not be 
big in size (since it is a static assignment, that is an unknown). 
Therefore, to provide the same level of flexibility, you might need to 
plan for thousands or even millions of different endpoints for a single 
CA. Conceptually, not a big issue. From a DevOps perspective... very 
scary, IMHO.
> [...]
>
> 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.
Sorry for the lack of clarity here - I meant providing the revocation 
information for the full chain, not the full chain itself :D In 
particular, although this is possible with today's protocol, it is a 
feature that is not used by clients. There might be several 
considerations as to why this is (my personal point of view is because 
of a series of different practical reasons - trust model, AIA in 
certificates, how path-building and validation is approached by crypto 
libraries).

As discussed before, there might be some other technologies for this - 
our proposal is to provide an updated version of the OCSP that optimizes 
responses for the non-revoked case and lowers the operational 
requirements and costs associated with it.

Does this address your questions ? Would you be interested in 
participating to the work ?

Cheers,
Max

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