+1. > -----Original Message----- > From: pkix-bounces@xxxxxxxx [mailto:pkix-bounces@xxxxxxxx] On Behalf Of > Henry B. Hotz > Sent: Monday, April 08, 2013 1:35 PM > To: Sean Turner > Cc: pkix@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 > Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) > to Proposed Standard > > Actually, what I get from this and all the other discussions is that it's unclear if > the updated OCSP satisfies the "suitability for the intended purpose" test. > Or at least it fails the KISS principle w.r.t. that. > > Rephrasing: an OCSP client should be able to tell from an OCSP response if: > a) the subject cert is on the CAs white list, b) the subject cert is on the CAs > black list, c) the subject cert is not on either list, or finally d) the OCSP server > is obsolete, and doesn't support making those distinctions. It's not trivial to > see how to parse 2560bis responses w.r.t. those cases, therefore it's highly > likely that computational complexity will prevent us from doing so. Even if > that's not actually the case, then implementor misunderstandings will > prevent us from doing so in practice. > > Therefore I vote against moving this draft forward. I just don't see the point. > > If someone were to write an informational RFC which explained how to > determine which of the 4 cases an OCSP response fell into, AND if said RFC > also convinced me that the decision process was easy to understand, THEN I > would change my vote. Obviously an appendix in 2560bis would serve just as > well. > _______________________________________________ > pkix mailing list > pkix@xxxxxxxx > https://www.ietf.org/mailman/listinfo/pkix