Re: [IETF-PKIX] OCSP Status Information on a Certificate

[Andreas Berger <aberger@xxxxxxxxxxxxxxxx>]

Paul Hoffman / IMC wrote:
> 
> At 08:48 AM 4/17/98 -0700, you wrote:
> >And in the event a client receives {is revoked, not issued}, which
> >dominates?  Similarly, {not revoked, not issued}.  I remain unconvinced this
> >is no problem.
> 
> To the client, "not issued" is always more important than revoked or not
> revoked. We can put that in the OCSP spec.
> 
> >As soon as OCSP clients are out there in any volume, there
> >are those who will seek to determine the client's behavior in fringe cases.
> 
> I fully agree. That's why I'm I don't think that issued/not issued should
> be a MAY: I think it has to be a MUST. We can be sure that some clients
> will blow the comparison unless they are always told whether or not the
> cert was even issued.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
Paul, I disagree.

The issued/not issued flag can only be answered by a small set of OCSP
responders. Let's take - for example - a company that operates an OCSP
responder of some of the most frequently used CAs in the world. It load
their CRLs to reduce communication cost and offers these "CRLs on-line"
to the internal client software (thus lowering the maintainance cost to
distribute CRLs to all clients). Given a specific certificate, such an
OCSP responder can only answer the question of revocation (revoked/not
revoked) on the basis of the CRL (so revoked is: on the list, not
revoked is: not on the list).

So probably we need some kind of "don't know" of the OCSP responder.

Regarding the question above: when a certificate was "not issued" this
is a no-go for the verification process. I think that we could drop any
other answers if the certificate was never issued. This is different for
"issued: don't know" and "issued: yes".

Andreas
-- 
Erst kommt das Fressen, dann kommt die Moral
 -- Bertolt Brecht