Re: [pkix] Straw-poll on OCSP responses for non-revoked certificates.

[[e-mail] (Martin Rex)]

Carl Wallace wrote:
>
> 1 but would like for the responder certificate or response to include some
> indication that the responder is using these new semantics.

I also choose 1, and I am not aware of any technical objection against 1,
why _permitting_ (rather than requiring) OCSP responders to do this
should be detrimental to the security of the peer authentication performed
by the RP or to the interop between the RP and the OCSP responder. 

I'm OK with defining an RECOMMENDing an explicit confirmation of
these semantics through a non-critical response extension.



Option 2 looks like a coffin nail for *ALL* OCSP extensibility to me.
It just doesn't make sense to me to add a "perfect" option on top of
good and permitting only _new_ RPs to recognize it; allowing+expecting
them to then fail on "good" no longer being good enough, while
effectively misleading the entire installed base on the guidance
to better not trust the cert (serial) in the response.


Option 3 looks like a technical problem.  Error responses are unsigned
and (a) are supposed to cause a fallback to CRLs (but CRLs processing
can not possibly detect the problem that the OCSP responder is trying
to convey) and (b) can not be cached by RPs that use OCSP to determine
that status of their communication peer's certificate.



About RPs that retry for OCSP responses with status "revoked,certificateHold",
the existing semantics of nextUpdate should be followed:

   http://tools.ietf.org/html/rfc2560#section-2.4

The removeFromCRL reason code is limited to delta-CRLs in order to
supersede a certificateHold of the baseCRL to which the delta CRL refers.
On the next regular CRL, a certificateHold crlEntry may reappear when
the permanent status is still undetermined, may be dropped/missing
when the hold status is lifted, or it may be replaced by a permanent
revocation.


-Martin