[cabfpub] Name Constraints, Auditing and EKU
rob.stradling at comodo.com
Thu Apr 25 12:28:11 MST 2013
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:
>>> 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
>> ~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
I would like to understand how to configure "Independent OCSP Signer" in
Windows, but I haven't managed to find any documentation.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public