[cabfpub] Name Constraints, Auditing and EKU

[Rob Stradling]

On 25/04/13 17:42, Erwann Abalea wrote:
> 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?

Hi Erwann.  I've exchanged a few emails with Ryan off-list, and he is 
sure that the answer is "No".  And I hope he's right!

But if he's right, then I think that means that assigning the "OCSP 
Signing" trust purpose to a Root Certificate in the Windows Trusted Root 
Store has absolutely no effect whatsoever.  Why provide a feature that 
does nothing?

I would like to understand how to configure "Independent OCSP Signer" in 
Windows, but I haven't managed to find any documentation.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online