Re: Optimizing OCSP - Time for some spec work ?

Peter Gutmann <[email protected]>
Newsgroups gmane.ietf.x509
Message-ID <[email protected]>
Niklas Matthies <[email protected]> writes:

>To make the additional responses optional (controlled by the client), a
>corresponding request extension could be defined. Hence that aspect could be
>covered by specifying a profile of the current OCSP protocol.

You could also do a simpler version where the responder includes an extension
that says "I've checked the entire chain from the cert you requested all the
way up to the root.  You're welcome".  It'd be fully compatible with current
deployments, and if clients are able to process the extension they get extra
value from it.

>OCSP responses are allowed to include additional single responses that
>weren't explicitly requested by the client, see RFC 6960 section 4.2.2.3 last
>paragraph.

At one point this was tested and the it was found that the number of
responders/clients who could handle more than one entry per OCSP query and who
hadn't been set up explicitly to work with the Indentrus trust model, which
requires multiple entries, was approximately zero.  So possibly the "I've
verified all the certs up to the root" extension would be easier to get
deployed.

Peter.

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.