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

[Ryan Sleevi <[e-mail]>]

On Fri, Oct 25, 2019 at 11:18 AM Dr. Pala <[e-mail]> wrote:

> [ ...]
>>
> 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.
>

I suppose I'm still not sure I fully understand your concerns here.

That is, it seems like as an operational consideration, the balancing of
the issuerDistributionPoint allows you to bound your worst-case
performance, while making suitable tradeoffs for your average and best case
scenarios. As others have suggested, it seems like more work would be
needed to show the math as to why this is a problem, given the rather
extensive flexibility already afforded to address this using existing
technologies.


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

As others have suggested (e.g. in PKIX), I think that it'd be far more
useful to not suggest it's a "OCSPv2" and instead highlight that you're
interested in providing an alternative revocation protocol, one that
seemingly combines elements of SCVP with the design of underlying protocols
like TLS.


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

I have no interest in this work. I think that, for the problem described,
it would be incompatible and undesirable for the PKIs I work with (that is,
the Web PKI used by Chrome).

That doesn't preclude there being value in exploring this for other PKIs;
my only interest would be in trying to effectively communicate the lack of
interest to avoid overfit for an implementation that won't adopt :)

To echo other's remarks, I think an improved approach that clearly
communicated the problem statement, and the comparison with the existing
technologies and operational capabilities, would be very useful in helping
others determine the relevance to their PKIs and/or products. From both
this and the PKIX thread, I do feel I've got sufficient information to say
"Not interested", but it took me quite a bit of confusion to get there ;)