Re: [IETF-PKIX] OCSP Change Request

[mmyers@xxxxxxxxxxxx]

Steve,

Comments inline.

At 10:53 AM 12/16/97 +0000, Stephen Farrell wrote:
> . . .
>The current protocol almost supports the above. Changes which would
>support the above could be:
>
>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.

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

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

>Some further requirements which could be proposed (though I'’m luke-warm
>about these myself):
>
>1. Allow the OCSP client to supply a set of partial paths in the request
>(might
>be too much data though).
>2. Allow the OCSP client to specify which root CAs are acceptable to it.
(This
>may also affect the key which the OCSP server uses to sign the response!)
>
>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.

>
>A final comment. I question the utility of a policy OID in the request. As
>this is
>apparently not intended to be a value from a certificatePolicies extension it
>is
>not clear who will ever define OIDs so that interoperability won’'t be
>impeded.

Which is why I didn't make them part of the standard response syntax.

>I’'d suggest either, a) change this to a request extension with a string
>syntax
>(as the global uniqueness of the OID gains nothing), or, b) limit this to be
>an
>OID which represents the policy OID input to the certificate validation
>algorithm as given in X.509.

I was intending to make some non-normative statements in the base OCSP
document identifying policy OIDs as one example of request extension.

>
>Regards,
>Stephen.
>
>--
>==========================================================================
>Stephen FARRELL......................................tel:  +353-1-676 9089
>Software and Systems Engineering Ltd......................................
>Fitzwilliam Court....................................fax:  +353-1-676 7984
>Leeson Close.................................email: stephen.farrell@sse.ie
>Dublin 2...........................................www: http://www.sse.ie/
>IRELAND................................................"A Siemens Company"
>==========================================================================
>
>