It is impossible to write a text that cannot deliberately be misunderstood.
This debate is so full of constructed, non-existent problems. Nothing has changed for the clients. The client can receive an error, or they can receive (good, revoked or unknown). The meaning of those responses are pretty clearly explained. The only thing we talk about here is an extremely unlikely and rare exception case where the responder is allowed to respond revoked even if a cert was never issued. I'm sorry to say, but this is getting ridiculous. /Stefan On 4/9/13 4:41 PM, "Piyush Jain" <piy...@ditenity.com> wrote: >> I'd rather not try to describe what clients should do or expect in terms >of >> non-issued certificates. >> Clients are really not meant to know anything beyond "revoked" = this >>cert >> should not be trusted. >[Piyush] >Thanks for clarifying your position on this Stefan. >This is the position I disagree with. I think several people in the WG >expressed that the meaning should be clearly conveyed if "revoked" is >extended to communicate "non-issued". Expectation that clients should >treat >these responses as normal revoked is not aligned with WG consensus IMO. >> >> This is a server choice to prevent the requested cert (if it exist at >>all) >from >> being accepted. >> For requests for real certs, issued by a trusted CA, this case will >>never >even >> occur unless the CA is compromised. >[Piyush] > And I think this is the only case that is interesting to the clients. I >combed through the WG discussion and did not find a single case being >discussed where clients benefit from sending OCSP requests for serial >numbers for non-existent certificates. > >> And, if I put something in, given the discussion so far, the chance that >there >> will be some major disagreements with it, is really high. >[Piyush] >These are the issues that implementers will have to deal with. If there >are >going to be disagreement, they should be dealt with before the document is >published IMO, unless 2560bis is considered a stop gap measure and OCSP v2 >is on the radar. >I understand the desire to wrap up the pending documents so pkix can be >disbanded on schedule. However, I'll leave that to the AD to decide that >the >benefits of meeting that schedule outweighs the cons of publishing a >document that can potentially lead to confusion among implementers. > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
