Re: Optimizing OCSP - Time for some spec work ?

I also don't see how this "I've checked the entire chain from the cert 
you requested all the way up to the root.  You're welcome" extension 
would work.

Consider a scenario in which a CA's private key had been compromised, 
and its certificate had been revoked. The attacker, who can use the 
compromised key to issue bogus certificates can not only issue bogus 
end-entity certificates, but also bogus OCSP responder certificates, and 
the bogus certificates can refer to the attacker's OCSP responder as the 
source for status information. The attacker's OCSP responder will 
"helpfully" says "I've checked the entire chain from the cert you 
requested all the way up to the root.  You're welcome." in order to 
encourage me not to directly check the status of the intermediate 
certificates.

The attacker's OCSP responder will tell me that the entire chain is 
okay, but the root CA would have told me that the CA certificate it 
issued has been revoked.

+-----------------------+
|                       |
|        Root CA        |
|                       |
+-----------------------+
             |
             |
            \/
+-----------------------------------------+
|          |
|    Compromised CA         |
|                                         |
+-----------------------------------------+
|                          |
             | certificates issued      |
            \/    by attacker           \/
+-----------------------+ +-----------------------+
|                       | |                       |
|    Bogus certificate  | |    Attacker's OCSP    |
|                       |    |     responder |
+-----------------------+ +-----------------------+


On 10/27/19 6:12 PM, Niklas Matthies wrote:
> 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://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpkix&amp;data=02%7C01%7Cdavid.cooper%40nist.gov%7C2fb50645c09a42b2aa8008d75b2ae66d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637078112122458384&amp;sdata=BmfMVlkZJtYAzOByzxCk5aa6aXFCWOJDxUIVXxxM9vQ%3D&amp;reserved=0 
>
>

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