[cabfpub] Name Constraints, Auditing and EKU

[Erwann Abalea]

Le 23/04/2013 23:28, Rob Stradling a écrit :
> On 23/04/13 21:50, Ryan Hurst wrote:
> <snip>
>> Additionally notice the logic is gated by the signing key; even in CA
>> delegated the delegated responder can not sign for any other CA in the
>> hierarchy -- only those within its scope.
>>
>> I am confident Windows behaves this way
>
> Disagree.
>
> ~30% of the Root Certificates distributed by the Microsoft Root 
> Certificate Program are enabled by default for the "OCSP Signing" 
> trust purpose.  AIUI, this means that they are trusted to sign (or 
> issue Delegated OCSP Response Signer certs that can sign) OCSP 
> Responses _for any cert that chains to any trusted Root_!!

Interested by this information, I parsed the CAB file containing the 
root certificates distributed by Microsoft. Attached to every root 
certificate is a set of EKU, and yes, 81 root certificate (among 352) do 
have the id-kp-ocspSigning EKU associated with them.
Does that really mean that these root certificates can act as a "Trusted 
Responder" for all the roots?