Stefan Santesson wrote: > > 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. As I wrote: As long as the spec is _entirely_silent_ about expected/desirable behaviour of the client on receipt of a repurposed "unauthorized(7)" OCSPResponseStatus, the new error code with be provable "backwards compatible" within the definition of the specification, because *ANY* client behaviour will formally provable meet the spec and therefore "be interoperable". How indiviual OCSP clients behave in particular, and whether all implementors appreciate the behaviour of their own implementation will then be _irrelevant_. ... which is why I believe that leaving client behaviour for the receipt of OCSPResponseStatus error code entirely unspecified is a bad idea, and for the repurposed "unauthorized(7)" it's a really bad idea. rfc5019 only talks about caching of signed OCSP responses: http://tools.ietf.org/html/rfc5019#section-6.1 -Martin