Re: [IETF-PKIX] OCSP Change Request

[Stephen Farrell <farrell@xxxxxxxxxxxx>]

Hi Mike,

> >1. The standard response message should include a MessageId field. This
> >allows the client to reference a response previously received which
> >contains a path deemed unacceptable by the OCSP client. Note that this
> >does not affect caching of responses. (A HREF would also suffice.)
>
> A MessageId field sounds like a useful request extension.  It would however
> predictably extend the complexity of an OCSP server such it must maintain
> this state information in addition to, for example, nonce information.

I agree that MessageId is a request extension, but would like it to
be a standard part of the response. I can see that it introduces some
state into a server which supports the request extension, however,
that statefulness is required in order to produce a "next" path
for the same request.

> >2. The standard response should include the base64 encoding of the entire
> >path and set of CRLs used to verify the certificate. There is very little
> >overhead involved as the OCSP server must possess all the relevant
> >items.
>
> I agree the OCSP server may have this information on hand, but its
> inclusion in the default case would be overkill for environments with
> well-defined trust paths.  Also, I hadn't seen OCSP as an alternate CRL
> retrieval mechanism.  In some instances OCSP deployment, there may not be
> any CRLs to send back.

I guess we're assuming different environments. I'd like that the
OCSP server and its clients needn't necessarily share well-defined
trust paths.

How about if the standard response were to contain the full certification
path used by the OCSP server with a way of using the extension mechanism
for the client to ask for a copy of the CRLs used?

> >3. A request extension should be defined which means "give me the next
> >path for response <<MessageId>>". The response should contain an
> >alternate certification path (+ CRLs) for the initial request. Of course the
> >second response contains a different MessageId so that iteration is
> >supported. Again this response can be cached without problems. (Or
> >nothing is needed if a HREF is present.)
>
> Might I ask that a draft of this proposed use of OCSP extensibility be
> drawn up, roughly in line with the briefing of this approach to extensions
> as discussed in D.C.?

Fair enough. I'll try to do that in the next week or so.

Meanwhile, I think it'd be worthwhile addressing the issue below on
the list.

> >In addition I'd note that the OCSP server should be chosen by (e.g.
> >configured into) the OCSP client. Using a cert extension to name the OCSP
> >server seems to open up security holes - e.g. it would allow the OCSP server
> >to masquerade as a CA to any of its clients..
>
> The contents of the certificate would be trusted to the extent the
> signature on the certificate is trusted.

I guess I basically don't like the situation where a certificate
contains the location of the OCSP server - it seems too much like making
the OCSP server into a root CA for the client (unless the OCSP server
actually is a root CA for the client, which is maybe what you had in
mind).

How do you actually see this working? Do you in fact expect that certs
will contain the location of the OCSP server? If so, how does a client
know that it should trust the named OCSP server? Maybe I'm just
misreading the draft, but I'd like to see this spelt out.

Regards,
Stephen.