[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: OCSP response pre-production
> The simple fix I most recently proposed could, I believe, be
> applied to RFC 2560 as it progresses from Proposed to Draft
> due to the poll's consensus. Meanwhile, I strongly suspect
> that the syntax and semantic changes of more sophisticated
> solutions will force a version delta, a new I-D and all that
> entails regarding WG, IETF and IESG ratification. That is, OCSPv2.
I am not a friend of adding an error message that adds nothing to the
security of the protocol but introduces the need for a second round-trip
into OCSPv1. As a client cannot really rely on the error message the
situation will not get better. From a security point of view, the
proposed error message does not bring any advantage (as it can be
faked), technically it introduces the disadvantage of having to do two
requests.
*** I therefore suggest to leave OCSPv1 as it is (instead of making it
worse) and work with Davids extension to go in for OCSPv2. ***
In the meantime (until we get OCSPv2) people can use server-generated
nonces (which are compliant with the current state of RfC2560 and with
all existing clients out there).
--
Florian Oelmaier
SyTrust