[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