Re: Optimizing OCSP - Time for some spec work ?

On Sat 2019-10-26 at 11:07h, Peter Gutmann wrote on pkix:
>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.

In my opinion that's highly dubious, as it reverses the chain of 
trust. Even if you trust the responder to have performed that check 
correctly, you first have to validate the responder's signature before 
you can trust the (signed) extension to be authentic, and for that you 
have to validate the responder's certificate chain, which includes the 
CA that issued the certificate being revocation-checked, and hence 
whose validity the extension is supposed to confirm. This effetively 
creates a cyclic dependency of trust.

Suppose that the responder has been compromised (and that it has the 
ocsp-nocheck extension): Then if the CA certificate is revoked due to 
that compromise, a client trusting the extension won't notice, as the 
compromised responder will happily (and falsely) assert that it has 
successfully checked the CA chain.

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

Having implemented such a client myself, I have to concur. :)

Niklas

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix