[cabfpub] Name Constraints, Auditing and EKU

[Ryan Hurst]

Rob,

Turns out there is no special handling of this case.

Ryan

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

Rob,

You are right, I didn't consider that case <blush>.

I am verifying if there is special handling for this case now; will update
the thread once I confirm.

Ryan

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

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.