[cabfpub] Name Constraints, Auditing and EKU

[Ryan Hurst]

Rob

If my memory serves me correctly the handling of "OCSP Stapling" is outside
the chain engines EKU logic where the nesting is applied, in other words it
doesn't matter that the roots don't have EKU verification; what matters is
maps into the OCSP verification rules I tried to describe.


Ryan 

-----Original Message-----
From: Rob Stradling [mailto:rob.stradling at comodo.com] 
Sent: Tuesday, April 23, 2013 2:29 PM
To: Ryan Hurst
Cc: Erwann Abalea; public at cabforum.org
Subject: Re: [cabfpub] Name Constraints, Auditing and EKU

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_!!

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