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