OCSP Relay

["Michael Myers" <mmyers@xxxxxxxxxxxx>]

The assumption that an OCSP requestor is in possession of the certificate in
question potentially precludes chaining of requests.  Consider that it might
be useful to aggregate OCSP requests at the enterprise boundary.  Some of
those certificates may be internally issued, some externally issued.  In the
case of the latter, the corporate OCSP responder could issue a request to
the external CA to acquire that CA's signed response.



> -----Original Message-----
> From: IETF X.509-based public key infrastructure mailing list
> [mailto:IETF-PKIX@LISTS.TANDEM.COM]On Behalf Of SGalperin
> Sent: Friday, April 17, 1998 10:54 AM
> To: IETF-PKIX@LISTS.TANDEM.COM
> Subject: Re: [IETF-PKIX] OCSP Status Information on a Certificate
>
>
> In a message dated 98-04-17 12:31:04 EDT, you write:
>
> >
> >  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.
> >
>
> Are we talking about fat OCSP client here ?
> Does the OCSP client in this case have full certificate chain ?
> Can we safely assume that fat OCSP client will need to verify
> signatures on
> the chain first, validity and other X509v3 constraints and only
> then submit
> OCSP request for status of every certificate in the chain ?
>
> If this is so then, essentially, OCSP client is already in the
> possession of
> the well-formed certificate signed by the (indirectly or
> directly) trusted CA
> key. In these circumstances receiving an anwer "not issued" may
> only mean that
> CA key is compromised and "unathorized" certificate has been
> signed. But if
> someone has the CA key and can sign anything with it (including
> "unathorized"
> certificates) then that someone can also make sure that "unathorized"
> certificate has the same serial number as one of "authorized" and
> as long as
> we only send serial number to identify a certificate in OCSP request the
> substitution of the "authorized" cert with "unathorized" one will be
> unnoticed. This makes "never issued" somewhat useless for fat
> OCSP clients.
>
> Is this reasoning wrong ?
>
> Also since CA archiving capacity is always finiteand we also talking about
> allowing "historical" OCSP queries "never issued" will have to be replaced
> with "info
> unavailable" at least in some cases. This further redices the
> value of "never
> issued" status.
>
> --Slava Galperin
>