+1.
-----Original Message-----
From: pkix-bounces(_at_)ietf(_dot_)org
[mailto:pkix-bounces(_at_)ietf(_dot_)org] On Behalf Of
Henry B. Hotz
Sent: Monday, April 08, 2013 1:35 PM
To: Sean Turner
Cc: pkix(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pkix