It is risky to assume that existing clients would work appropriately if
you send them a new never seen before error code.
I'm not willing to assume that unless a big pile of current implementers
assures me that this is the case.
/Stefan
On 3/27/13 3:14 PM, "Martin Rex" <mrex@xxxxxxx> wrote:
>Stefan Santesson wrote:
>> "Martin Rex" <mrex@xxxxxxx> wrote:
>>
>> >Adding 3 more OCSPResponseStatus error codes {
>>no_authoritative_data(7),
>> >single_requests_only(8), unsupported_extension(8) } with well-defined
>>and
>> >conflict-free semantics to the existing enum would be perfectly
>>backwards
>> >compatible.
>>
>> Of course it is backwards compatible with the standard, but not with the
>> installed base.
>>
>> What would happen to the installed base of clients if OCSP responders
>> would change from current "unauthorized" to one of your new error codes?
>
>
>Actually, please look at the I-D text again. Even if the Servers would
>change their response to a new error code for the "I can not respond
>authoritatively", it will be 100% backwards compatible with the clients.
>
>That is at least what proposed change implies!
>
>So lets assign new error codes and have Server change their response!
>
>
>
>"Backwards compatibility" is relevant in the same fashion as
>interoperability
>-- interoperability among independent implementations as well as interop
>between new implementations and the installed base.
>
>Since the current change only "conveys" information, and does that in
>an extremely ambiguous fashion, moving to a new error code is provably
>NOT going to be any problem to interop, The desired client behaviour
>is completely unspecified, so *ANY* client behaviour will be acceptable.
>
>
>Based on the current text, your claim must be bogus, that assignment of
>new error codes for this purpose would be backwards incompatible.
>
>
>What I can not yet completely rule out, though, is that there are some
>currently unstated expectations / desired behaviour that you would
>want to retain, and which is currently undocumented. Should that be
>the case, then it is paramount that any such expectation about desired
>behaviour is ADDED to the document, in order to enable interop with
>independent implementations.
>
>It is conceivable that such "desired/expected" behaviour consists of some
>kind of "blacklisting" that had been previously implemented for the
>"unauthorized(7)" error code, and that the inventors of the rfc5019
>profile (VeriSign and Microsoft) wanted to take advantage of.
>
>Should that be the case, then I would really be curious what kind of
>blacklisting that is that implementors are thinking of when they
>express their concern a move to a newly assigned error code would
>be "backwards incompatible". Is it about the caching of that responses
>on clients? Is there any "negative response caching"? Are negative
>responses cached "per server" or per (requested) certificate status?
>
>
>-Martin