Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

["Piyush Jain" <[e-mail]>]

> 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.