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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]