CA Certificate Profiles: OCSP Signing EKU

[lachellel]

A new comment was submitted regarding the EKUs in the CA certificate profiles.

Issue:

• Add OCSP signing to the EKU value asserted in CA certificates

Impacts:

• Root CA certificate profile
• Subordinate CA certificate profile
• Section 7 of this CP

Actions:

• Review the trust store and Baseline Requirements policies again
• Review other entity CA certificates for clarity
• Sample the ocsp responses, ocsp certs, and processing in libraries
• Update profiles and policy based on outcomes

[techliaison]

why add an EKU to the Root CA certificate? The Root will be using a delegated OCSP responder and not using its own key to sign the responses.

[lachellel]

I'm just adding the received comment for tracking here first. :grinning:

[Chokhani]

The reason for including EKU in Sub CA certificate is that this certificate already has EKUs and since Sub CA will issue delegated OCSP Responder certificate, it is safest from interoperability perspective to add the EKU. Otherwise, clients processing OCSP Responder certificate chain (those who enforce EKU constraints on the chain might fail.

We are not asking to add EKU to root certificate. However, if the root is promulgated with restrictive EKU properties (which it should) OCSO Signing should also be added to those

[Chokhani]

Folks are confusing root properties with contents of X.509 root certificate. Root properties are metadata associated with the root by a given environment

[ryancdickson]

Sample Certificates updated in Pull Request: # 507 - "Upload updated Test Certs"

[lachellel]

Reviewed four providers and samplings of CA certs (intermediate issuing, and roots just for good measure):

• Goog
• Digicert
• Comodo
• LE

Haven't found a single CA cert that asserts the EKU yet. It would be nice to understand which clients that are targeted for this use case (TLS, webpki) actually would fail.

[Chokhani]

It does not matter.

It is safer to assert the OCSP Signing EKU in CA certificate in order to perform the delegation properly

From: LRL [mailto:notifications@github.com] Sent: Friday, August 31, 2018 4:19 PM To: uspki/policies policies@noreply.github.com Cc: Chokhani chokhani@libra-sec.com; Comment comment@noreply.github.com Subject: Re: [uspki/policies] CA Certificate Profiles: OCSP Signing EKU (#515)

Reviewed four providers and samplings of CA certs (intermediate issuing, and roots just for good measure):

• Goog
• Digicert
• Comodo
• LE

Haven't found a single CA cert that asserts the EKU yet. It would be nice to understand which clients that are targeted for this use case (TLS, webpki) actually would fail.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uspki/policies/issues/515#issuecomment-417778566 , or mute the thread https://github.com/notifications/unsubscribe-auth/Ak55Om9v1lHdu24T-8f5zGgglSw3IO2-ks5uWZpIgaJpZM4TgBfa .

[Chokhani]

OK.

I may have been a bit hasty. What is the e-mail saying?

Is it saying that the commercial certificates examined do not have EKU in CA certificates or is this is saying that the CA certificates have EKU, but do not have OCSP Signing EKU?

Also, note that the comment was to add the OCSP Signing to Server Auth and hence why would web PKI fail?

The use case for adding OCSP Signing EKU in case EKU is present is to accommodate clients that force EKU on the path and thus ensure that the OCSP certificate path will succeed.

Once we get on the same page, I can share security considerations if they are relevant.

From: Santosh Chokhani [mailto:chokhani@libra-sec.com] Sent: Friday, August 31, 2018 6:05 PM To: 'uspki/policies' reply@reply.github.com; 'uspki/policies' policies@noreply.github.com Cc: 'Comment' comment@noreply.github.com Subject: RE: [uspki/policies] CA Certificate Profiles: OCSP Signing EKU (#515)

It does not matter.

It is safer to assert the OCSP Signing EKU in CA certificate in order to perform the delegation properly

[rmhrisk]

Because the inherited EKU behavior inclusion of OCSP signing in a ICA is signaling the parents delegation Of response signing authority (e.g. you can revoke certificates issued by the parent)

As for the CA providers mentioned all do CA signed responses, UAs allways trust the certificate signing key for response signing.

[Chokhani]

See inline

From: Ryan Hurst [mailto:notifications@github.com] Sent: Saturday, September 1, 2018 10:46 PM To: uspki/policies policies@noreply.github.com Cc: Chokhani chokhani@libra-sec.com; Comment comment@noreply.github.com Subject: Re: [uspki/policies] CA Certificate Profiles: OCSP Signing EKU (#515)

Because the inherited EKU behavior inclusion of OCSP signing in a ICA is signaling the parents delegation Of response signing authority (e.g. you can revoke certificates of the parent)[Santosh] I suspect you mean the certificates issued by the parent. Delegation by a CA does not authorize you to revoke the CA’s certificate.

As for the CA providers mentioned all do CA signed responses, UAs allways trust the certificate signing key for response signing.[Santosh] The US Fed Public Web PKI does not set DS bit in KU of the Sub CA certificate since that key is NOT used for OCSP signing. Thus, having the OCSP does not mean that if the CA went rogue or was compromised, OCSP responses signed by it should be trusted.

[Santosh] Personally, I would be ok with not asserting OCSP Signing EKU if CAB Forum can have a written position or requirement for OCSP clients to not enforce EKU on the OCSP certificate’s certification path. As you might know, the IETF has washed its hands off the EKU debate. Now, we have X.509 and 5280 on one side not enforcing it on the path and MS CAPI enforcing it. Not an ideal situation.

[rmhrisk]

Yes, I meant certificates issued by the parent.

If I recall forrly most clients ignore KU flags.

Most UAs now implement EKU constraints, not just CAPI.

[Chokhani]

See inline.

From: Ryan Hurst [mailto:notifications@github.com] Sent: Monday, September 3, 2018 8:30 AM To: uspki/policies policies@noreply.github.com Cc: Chokhani chokhani@libra-sec.com; Comment comment@noreply.github.com Subject: Re: [uspki/policies] CA Certificate Profiles: OCSP Signing EKU (#515)

Yes, I meant certificates issued by the parent.[Santosh] Great. My original question remains: Do these CA certificates have EKUs or not?

If I recall forrly most clients ignore KU flags.[Santosh] That would not be RFC 5280 compliant which requires that if a certificate has both KU and KU, it be used only for the purpose consistent with both and goes on to define DS and NR as the bits for OCSPSigning EKU.

I would say that if the CA certificate did not have EKU in the first place, do NOT add one for the sake of OCSPSigning. But, if it does have EKU, either add OCSPSigning or reach some sort of agreement via CAB Forum to ensure that the OCSP clients do not enforce EKU for the certificate path. Your point about client not being standard compliant enforces my viewpoint of wanting to ensuring interoperability or having some sort of implementers agreement.

[lachellel]

@Chokhani to close this one out:

Question: Do these CA certificates have EKUs or not? Answer: Yes. The issuing CA certs have EKUs as do our profiles. You can review these and others at their repositories or query crt.sh for other samples.

[lachellel]

Re-open this one. The conversations were unclear - review samples again.

Question: Do these CA certificates have EKUs or not?

[Chokhani]

Yes; they do and that is where the rub is. They have some EKUs and not OCSP.