Re: Clarification request on RFC 2560

[John Thielens <johnt@xxxxxxxxxxxx>]

Margus:

> If the client can not count on something, this feature is not very
> useful. In this case, the client must still implement functionality for
> retrieving certificates needed for verification of the OCSP response
> (this is a MUST, because I can't rely on the OCSP response itself).
> Retrieving certificates from the OCSP response itself means that the
> client developer must do additional work in hope that some OCSP
> responder will put something useful in the response.
> 
> I would suggest explicitly stating the assumptions that the client can
> make about the content of the certs field, and if these assumptions
> consist of an empty set, removing this field as it only complicates
> things without providing any measurable value.

Part of this depends on the trust model between the client and the server.  If there were no certs in the request, this would require the server to have foreknowledge of the requester's certificate, indexed by its name (requestorName).  By allowing the requester to supply certs, presumably a cert chain up to but not including some trust root expected at the server, this makes the protocol more flexible.

Ditto for the certs in the response from the server.  This is very common practice and appears in protocols like SSL/TLS, CMS (S/MIME), and so on.

The reason I say the entity using the certs MUST NOT count on any particular meaning to the order or presence of the certs is because normal path discovery and path validation rules apply here per 2459 (sec. 6.1 -- although this is somewhat thin on discovery).  Before path validation, the client counts on nothing.  But after path validation, the client knows exactly what to trust.

John