[IETF-PKIX] OCSP Change Request

[Stephen Farrell <stephen.farrell@xxxxxx>]

Hi All,

The OCSP draft is very close to solving a number or problems which
we've seen arise when developing certificate handling applications. Basically
whilst the code to verify a certification path is relatively simple, the code
to
find a certification path and related CRLs is very hard! (Consider delta-CRLs,
NULL-DNs + many alternate names, etc.)

I'd like to suggest we supplement the current OCSP draft so as to allow the
OCSP
client to choose whether or not to blindly believe the OCSP server whilst at
the same time allowing the OCSP client programmer to avoid the complexity
of writing path traversal and CRL (esp. delta CRL) handling code.

Specifically, I'm asking for support for the following requirements:

1. OCSP servers which are not CAs (e.g. just a certificate validation engine
and LDAP client) to be fully supported.
2. The OCSP protocol should provide a means to relieve OCSP clients from the
burden of certificate path traversal and CRL checking whilst allowing the
client to
(re-)verify the certification path itself (or archive the path & CRLs used).
3. The OCSP client should be able to indicate in the request (as an
extension) that a previously returned path is not acceptable, and that the
OCSP server should respond with the ãnextä path (if any) for the certificate.

Consequences:

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

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

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.

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.

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"
==========================================================================