Re: Optimizing OCSP - Time for some spec work ?

Niklas Matthies <[email protected]> writes:

>In my opinion that's highly dubious, as it reverses the chain of trust. Even
>if you trust the responder to have performed that check correctly, you first
>have to validate the responder's signature before you can trust the (signed)
>extension to be authentic, [...]

Given that the current near-universal use [0] is to trust a replayed, stale
response, typically applying only to the leaf cert, and frequently not even
from the OCSP responder but from an unrelated third party (RFC 6066), this is
a considerable improvement on the current state of practice.

>Suppose that the responder has been compromised (and that it has the ocsp-
>nocheck extension): Then if the CA certificate is revoked due to that
>compromise, a client trusting the extension won't notice, as the compromised
>responder will happily (and falsely) assert that it has successfully checked
>the CA chain.

That's not any worse than the current situation, where the CA cert isn't
checked at all (unless the third-party server implements RFC 6961 and replays
stale responses for the CA certs as well as stale responses for its own cert)
[0 again].  And that's the worst-case situation, for anything other than
worst-case it's an improvement.

Peter.

[0] By this I mean use in HTTPS, and I realise I'm now making the same flawed
    case that I've pointed out numerous times on the TLS WG list, assuming
    that the entire world is the web, but for OCSP this is the near-universal
    use.

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix