ietf
[Top] [All Lists]

Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

2013-03-27 10:59:55
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

<Prev in Thread] Current Thread [Next in Thread>