Subject: Re: I-D ACTION:draft-ietf-pkix-ocsp-path-00.txt

From: Denis Pinkas <[email-masked]>
Date: Wed, 04 Oct 2000 12:05:40 +0200

Comments on the document on Path discovery

It is questionable whether this function, used alone, should be considered
an extension to OCSP.

Today the basic task of OCSP is to provide the revocation status of the
certificate. However, path discovery may be useful even if no OSCP service
is ever supported by the CA which has issued the certificate (but only
CRLs).

It would seem more appropriate to allow the same server to support both an
OCSP service and a path discovery service, rather than to consider this
service as an extension to OCSP.

Since an OCSP request is assumed to be used, that request includes the
certificate identifier of the leaf certificate. However, the definition of
the "top" root key and the constraints are is missing. They may be indicated
using one of the following ways:

1) with an OID of the validation policy, or
2) with a set of self-signed certificates, and, if the Certificate Policy
constraints and the naming constrains are not included in it, to specify
them separately. For the revocation information, it should be possible to
indicate whether CRLs or OCSP responses are requested, at least for the leaf
certificate and the CA certificates.

The response is missing an easy way to relate every CRL or OCSP response to
every certificate of the chain.

In the security consideration section, it is mentioned that this service
need not be trusted. This is an interesting remark which may be used as an
additional argument to dissociate that service from an OCSP service, since
by definition all responses from an OCSP server are signed (unless there is
an error) and if the service is untrusted, then no signature is necessary.
So returning all that information, without a signature should be considered.

Remainder: As this has already been raised on the mailing list, the fact
that the server is defined as stateful is not appropriate. The parameter
"retryReference" should be deleted.

The structure of both the request and the response should be modified to
accommodate these requirements.

Denis