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