[cabfpub] Name Constraints, Auditing and EKU

[Rob Stradling]

Ryan,

If a Root CA issues a Name-Constrained Subordinate CA Certificate that 
contains the OCSP Signing EKU, then surely that Subordinate CA 
Certificate can also function as a "2. CA delegated" OCSP Response 
Signer _for the Root CA_?

Or are you perhaps implying that Windows will spot 
basicConstraints:CA=TRUE and/or keyUsage:keyCertSign in the Subordinate 
CA Certificate and therefore refuse to let the cert be used as a 
Delegated OCSP Response Signer cert?

On 23/04/13 21:50, Ryan Hurst wrote:
> I am just catching up on my CAB Forum mail, I see this conversation
> regarding the OCSP signing EKU and it seems there may be a miss
> understanding.
>
> There are four trust models for OCSP:
> 1. CA Signed; the same key/certificate that signed the certificate was used
> to sign the OCSP status.
> 2. CA delegated; the same key/certificate that signed the certificate was
> used to sign a certificate that contains the OCSP Signing EKU that was used
> to sign a OCSP response.
> 3. VA Signed; the relying party has been configured out of band to trust
> this specific key/certificate to sign OCSP responses for a given set
> (usually all) of certificates.
> 4. VA delegated; the relying party has been configured out of band to trust
> a specific key/certificate to sign OCSP responses for a given set of
> certificates, that entity has signed a certificate/key that contains the
> OCSP Signing EKU.
>
> It is only possible to trust do 1 & 2 automatically in that they are in
> essence leverage the policy expressed in the certificate and not out of band
> configuration. In other words even if clients support 2 & 3 (which most
> don't in my testing) the only thing the browsers do is #1 and #2.
>
> 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, I am also confident what was once
> the ValiCert  (now Axway) client behaved this way.
>
> As such I don't see a need to exclude name constrained CAs from using OCSP.
>
> Ryan
>
>
> -----Original Message-----
>> 12. Appendix B(2)G:
>>        "id-kp-OCSPSigning MUST be present"
>>
>> Disagree.  The OCSP Signing trust purpose is not supposed to be passed
>> down from the Root, and AFAIK there is no way to prevent a Subordinate
>> CA from issuing delegated OCSP Signing Certificates!  (If you have
>> evidence to the contrary, please say).
>
> I think the requirement is really a "id-kp-OCSPSigning MUST NOT be present".
> If CA A issues a certificate to CA B with id-kp-OCSPSigning in the EKU,
> then CA B has now a valid OCSP responder for certificates issued by CA
> A; which is certainly NOT something wanted by CA A.
>
> There are limits to using an extension for something it wasn't designed
> for... I'm not a fan of "EKU constraints".
>
>> 13. Appendix B(2)G:
>>        "** Extended Key Usage within Subordinate CAs is an exception to
>>         RFC 5280 that MAY be used to further protect relying parties until
>>         the Name Constraints extension is supported by Application
>>         Software Suppliers whose software is used by a substantial portion
>>         of Relying Parties worldwide."
>>
>> I agree that we should note that this is "an exception to RFC 5280".
>> However, I don't think Mozilla have any plans to stop requiring EKU once
>> Name Constraints are supported more widely, since EKU and Name
>> Constraints achieve different things.
>
>
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.