> 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
