Actually, what I get from this and all the other discussions is that it's
unclear if the updated OCSP satisfies the "suitability for the intended
purpose" test. Or at least it fails the KISS principle w.r.t. that.
Rephrasing: an OCSP client should be able to tell from an OCSP response if:
a) the subject cert is on the CAs white list, b) the subject cert is on the CAs
black list, c) the subject cert is not on either list, or finally d) the OCSP
server is obsolete, and doesn't support making those distinctions. It's not
trivial to see how to parse 2560bis responses w.r.t. those cases, therefore
it's highly likely that computational complexity will prevent us from doing so.
Even if that's not actually the case, then implementor misunderstandings will
prevent us from doing so in practice.
Therefore I vote against moving this draft forward. I just don't see the point.
If someone were to write an informational RFC which explained how to determine
which of the 4 cases an OCSP response fell into, AND if said RFC also convinced
me that the decision process was easy to understand, THEN I would change my
vote. Obviously an appendix in 2560bis would serve just as well.