1888714 - Entrust: EV Certificate missing Issuer’s EV Policy OID

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Bruce Morton]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Comment 1

[Bruce Morton]

Preliminary Incident Report

The EV Guidelines section 9.7 (3) states that the certificatePolicies extension in EV Certificates issued to subscribers must include the issuer’s EV policy identifier (OID). Recently we were made aware of EV TLS certificates issued by Entrust that did not contain our EV TLS CP OID.

In one instance, certificates were issued without the CP OID in the period between September 11, 2023, and September 22, 2023. These certificates are a subset of the certificates disclosed in https://bugzilla.mozilla.org/show_bug.cgi?id=1883843 and are currently being replaced and revoked (current status of this process can be reviewed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1886532 ).

We can confirm that the Entrust EV TLS CP OID is included in all EV certificate profiles since March 18, 2024, as stated in section 9.7 (3) of the EV Guidelines, and mis-issued certificates are being addressed per the incidents referenced above.

In a second instance, we confirmed that six certificates issued by “Entrust 4K TLS Certification Authority - EVTLS1” and “Entrust P384 TLS Certification Authority - EVTLS2” did not contain our EV TLS CP OID. These certificates were being used on test websites; all of these certificates have since been replaced or expired. We will provide a full incident report including a list of all impacted certificates on or before 2024-04-05.

To be further explored

We believe that there may have been an error in ballot 151 and TLS BR 1.5.7 (see https://cabforum.org/uploads/EV-V1_5_7-redlined.pdf). In this update the following statements were made:

Section 7.1.6.1 states:

EV OID: An identifying number, in the form of an “object identifier,” that is included in the certificatePolicies field of a certificate that: (i) indicates which CA policy statement relates to that certificate, and (ii) is either the CA/Browser Forum EV policy identifier or a policy identifier that, by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate.

Section 9.3.2 states:

Each EV Certificate issued by the CA to a Subscriber MUST contain a policy identifier that is either defined by these Guidelines or the CA in the certificate’s certificatePolicies extension that: (i) indicates which CA policy statement relates to that Certificate, (ii) asserts the CA’s adherence to and compliance with these Guidelines, and (iii), is either the CA/Browser Forum’s EV policy identifier or a policy identifier that, by pre-agreement with the Application Software Supplier, marks the Certificate as being an EV Certificate.

The author of the ballot may not have considered section 9.7, which states “The Issuer’s EV policy identifier.” An edit to “EV policy identifier” would have supported the either/or option from section 9.3.2.

Comment 2

[Adriano Santoni]

It seems to me too that the requirement in EVG 9.7 (3) conflicts with 9.3.2.

Comment 3

[Ryan Dickson]

Hi Bruce,

Thank you for providing a preliminary report.

Regarding the statements in “To be further explored”, I have a different interpretation, where I don’t believe the existing language in the EVGs limits EV certificates to only one certificatePolicies extension value. I also do not believe the requirements in 9.7 (3) conflict with 9.3.2, as described below.

EVGs (Section 9.3.2):

Each EV Certificate issued by the CA to a Subscriber MUST contain a policy identifier that is either defined by these Guidelines or the CA in the certificate’s certificatePolicies extension that:

1. indicates which CA policy statement relates to that Certificate,
2. asserts the CA’s adherence to and compliance with these Guidelines, and
3. is either the CA/Browser Forum’s EV policy identifier or a policy identifier that, by pre‐agreement with the Application Software Supplier, marks the Certificate as being an EV Certificate.

Discussion: In my opinion, the phrase "MUST contain a" does not inherently limit the certificate to only one policy identifier; it specifies a requirement rather than imposing a numerical restriction (i.e., it mentions a policy identifier, not the only policy identifier). This interpretation means that while at least one policy identifier meeting the outlined criteria must be present for the certificate to be considered EV compliant, the guidelines do not explicitly prevent the inclusion of additional policy identifiers that also meet these or other standards.

When considering both sets of language in EVG 9.7 (3) and TLS BR Section 7.1.2.7.5, it seems to me a more appropriate interpretation is that both the Issuer’s EV policy and the Reserved Certificate Policy Identifier of 2.23.140.1.1 must be asserted. This behavior is consistent with what we see across the ecosystem when considering a sampling of other EV issuers, examples below:

• https://crt.sh/?sha256=838ab91ed939fe6663263ecc2aec93d3438770c39dfd16877bd9deecf19821b6
• https://crt.sh/?sha256=91f0245dc132aa430cddb2280e0b69cbbb9775eb207d08115e980cd3ee88c35d
• https://crt.sh/?sha256=effcbb8e15f89f7ad7ac1537ec462d273eda1a2fca8967c211830223cb42432d
• https://crt.sh/?sha256=e43861c283952362ee00ff9b92c6e8fabf0a350b602739e7ce51a89fed01a2bb

If I’ve misunderstood anything, please let me know!

Thanks,
Ryan

Comment 4

[Bruce Morton]

(In reply to Ryan Dickson from comment #3)

When considering both sets of language in EVG 9.7 (3) and TLS BR Section 7.1.2.7.5, it seems to me a more appropriate interpretation is that both the Issuer’s EV policy and the Reserved Certificate Policy Identifier of 2.23.140.1.1 must be asserted.

Hi Ryan, thanks for the reply. I agree that is an appropriate interpretation. That said, I brought this up as an area to be explored because I think it would be valuable to streamline the guidelines, and make them easier to interpret and maintain.

I believe the intent of CA/Browser Forum ballot 151 was to use standard reserved policy identifiers. This is also consistent with the Microsoft policy requirement which states “CAs must use the following OIDs in the end-entity certificate: DV 2.23.140.1.2.1; OV 2.23.140.1.2.2; EV 2.23.140.1.1; IV 2.23.140.1.2.3; EV Code Signing 2.23.140.1.3; Non-EV Code Signing 2.23.140.1.4.1.”

Our collective issue is that we are trying to interpret implementation of the certificate policy identifier from multiple requirements documents and browser policies. It would help if we could limit the interpretation effort.

The good news is TLS BR SC-62 certificate profile update limits interpretation and provides a more explicit result. For the certificate policy identifier, the TLS BRs now have a MUST requirement for “A Reserved Certificate Policy Identifier” and a MAY requirement for “Any other identifier”. I think this provides clear direction and preference.

However, the EV Guidelines provide an EITHER/OR and a MUST requirement for the certificate policy identifier. Additionally, with the MUST requirement for the Issuer’s EV policy identifier, the preference appears to be reversed from the TLS BRs.

We could provide better clarity to the CAs, auditors and linting authors if we specify the requirements in just one document, meeting the preference which is deemed most suitable by the browser vendors. I assume this would be as stated in the TLS BRs. If this is the appropriate direction, we could address the issue with the CA/Browser Forum Validation Subcommittee and propose a ballot to remove EV Guidelines section 9.3 subsections and text and reference the TLS BRs. I also think that EVG section 9.7 could be deleted as there are no additional requirements which are not covered by either the EV Guidelines or TLS BRs.

Comment 5

[Martijn Katerbarg]

The good news is TLS BR SC-62 certificate profile update limits interpretation and provides a more explicit result. For the certificate policy identifier, the TLS BRs now have a MUST requirement for “A Reserved Certificate Policy Identifier” and a MAY requirement for “Any other identifier”. I think this provides clear direction and preference.

FWIW, I would say that SC31 already made this clear, adding the following language in TLS BR v1.7.1:

Effective 2020-09-30, a Certificate issued to a Subscriber MUST contain, within the Certificate's certificatePolicies extension, one or more policy identifier(s) that are specified beneath the CA/Browser Forum's reserved policy OID arc of {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1).

The certificate MAY also contain additional policy identifier(s) defined by the Issuing CA. The issuing CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these requirements.

Comment 6

[Rob Stradling]

(In reply to Bruce Morton from comment #4)

(In reply to Ryan Dickson from comment #3)

When considering both sets of language in EVG 9.7 (3) and TLS BR Section 7.1.2.7.5, it seems to me a more appropriate interpretation is that both the Issuer’s EV policy and the Reserved Certificate Policy Identifier of 2.23.140.1.1 must be asserted.

Hi Ryan, thanks for the reply. I agree that is an appropriate interpretation.
...
However, the EV Guidelines provide an EITHER/OR and a MUST requirement for the certificate policy identifier. Additionally, with the MUST requirement for the Issuer’s EV policy identifier, the preference appears to be reversed from the TLS BRs.

When there are apparent "inconsistencies" between two requirements documents, or even between two sections of the same document, I certainly agree that efforts should be made to clarify the wording of those document(s). However, until such clarification occurs, CAs should be striving to adhere to the most restrictive of the requirements. In this case, as Ryan has already pointed out, including "both the Issuer's EV policy and the Reserved Certificate Policy Identifier of 2.23.140.1.1" achieves that.

EVG Section 9.3.5 (Subscriber Certificates) says (emphasis mine):
"A Certificate issued to a Subscriber MUST contain one or more policy identifier(s), defined by the
Issuing CA, in the Certificate’s certificatePolicies extension that indicates adherence to and
compliance with these Guidelines."

This requirement is more restrictive than the "EITHER/OR" language in Section 9.3.2, so it takes precedence. "EITHER/OR" does not forbid "BOTH".

I do wonder how to interpret "defined by the Issuing CA" though. Can a CA "define" 2.23.140.1.1 in its CP/CPS to be the OID it uses as its "Issuer's EV policy identifier", even though the CA is not the owner of that OID arc?

Comment 7

[Bruce Morton]

Thanks Rob, we are in agreement that the more restrictive language prevails. This is a discussion can be addressed within the CA/Browser Forum, while we focus on the incident itself here.

Also note, we are late with the incident report which we will plan to post by 11 April 2024.

Comment 9

[Bruce Morton]

Attachment: ev-missing-oid-precerts.xlsx

Comment 10

[Bruce Morton]

Attachment: ev-missing-oid-leafcerts.xlsx

Leaf certificates will be uploaded to crt.sh within 24 hours.

Comment 11

[Bruce Morton]

(In reply to Bruce Morton from comment #8)
Comment 8 should be deleted from this bug. Correct Incident Report to follow.

Comment 12

[Bruce Morton]

Incident Report

Summary

The EV Guidelines section 9.7 (3) states that the certificatePolicies extension in EV Certificates issued to subscribers must include the issuer’s EV policy identifier (OID). Recently we were made aware of EV TLS certificates issued by Entrust that did not contain our EV TLS CP OID.

In one instance, certificates were issued without the CP OID in the period between September 11, 2023, and September 22, 2023. These certificates are a subset of the certificates disclosed in https://bugzilla.mozilla.org/show_bug.cgi?id=1883843 and are currently being replaced and revoked (current status of this process can be reviewed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1886532 ).

We can confirm that the Entrust EV TLS CP OID is included in all EV certificate profiles since March 18, 2024, as stated in section 9.7 (3) of the EV Guidelines, and mis-issued certificates are being addressed per the incidents referenced above.

In a second instance, we confirmed that six certificates issued by “Entrust 4K TLS Certification Authority - EVTLS1” and “Entrust P384 TLS Certification Authority - EVTLS2” did not contain our EV TLS CP OID. These certificates were being used on test websites; all of these certificates have since been replaced or expired.

Impact

This incident involves 1969 EV TLS certificates. 1963 EV TLS certificates were issued between September 11, 2023, 13:46:00 UTC and 22 September 2023 11:34:42, UTC. In addition, 6 EV TLS certificates were issued to Entrust for test sites between January 24, 2024, 15:18 UTC and January 24, 2024, 21:19 UTC.

EV Certificates with only the CA/Browser Forum reserved certificate policy identifier, but without the Entrust EV certificate policy identifier were not accepted as EV certificates in some browsers. In addition, removal of the Entrust EV certificate policy identifier was not in alignment with the EV Guidelines.

Timeline

All times are UTC.

2022-11-30:

• EV Guidelines 1.8.0 section 9.3.2 states, “Each EV Certificate issued by the CA to a Subscriber MUST contain a policy identifier that is either defined by these Guidelines or the CA in the certificate’s certificatePolicies extension”
• EV Guidelines 1.8.0 section 9.7 states, “The certificatePolicies extension in EV Certificates issued to Subscribers MUST include the following: certificatePolicies:policyIdentifier (Required), The Issuer’s EV policy identifier.”

2023-04-22:

• Ballot SC62 Certificate Profiles Update was adopted. This ballot added EV certificate profile requirements to the TLS BRs.

2023-08-17:

• TLS BRs 2.0.1 section 7.1.2.7.5 states:

• certificatePolicies MUST be present. MUST assert the Reserved Certificate Policy Identifier of 2.23.140.1.1 as a policyIdentifier. See Section 7.1.2.7.9.

• TLS BRs 2.0.1 section 7.1.2.7.9 states:

• policyIdentifier - MUST - One of the following policy identifiers: A Reserved Certificate Policy Identifier MUST The Reserved Certificate Policy Identifier (see Section 7.1.6.1) associated with the given Subscriber Certificate type (see Section 7.1.2.7.1).
• anyPolicy - MUST NOT - The anyPolicy Policy Identifier MUST NOT be present.
• Any other identifier - MAY - If present, MUST be defined and documented in the CA’s Certificate
  Policy and/or Certification Practice Statement.

2023-09-11

• Based on the TLS BR section 7.1.2.7.9 MUST requirement for the Reserved Policy Identifier and the MAY requirement for Any other identifier, Entrust updated the certificate profile to remove the Entrust certificate policy identifier.

2023-09-15

• Ballot SC62 Certificate Profiles Update was effective.

2023-09-22

• Entrust added the Entrust EV certificate policy identifier back to EV certificates.

Root Cause Analysis

1. Why was there a problem?
The Entrust EV certificate policy identifier were removed from Entrust EV TLS certificates, which is not in alignment with the EV Guidelines.

2. Why was the Entrust EV certificate policy identifier were removed?
Entrust interpreted from the TLS BRs that since there is a MUST requirement for the “reserved certificate policy identifier” and a MAY requirement for “Any other identifier” that the certificate did not need the Entrust certificate policy identifier. This was also in alignment with the understanding that the industry would prefer smaller certificates in the TLS ecosystem.

In addition, based on the EV Guidelines section 9.3.2 which provided an either/or requirement for “reserved certificate policy identifier” versus the “CA’s certificate policy identifier”, we removed the Entrust certificate policy identifier.

We did not recognize or understand that EV Guidelines section 9.7 was overruling the choice in section 9.3.2.

3. Why did Entrust not recognize or understand that EV Guidelines section 9.7 was overruling the choice in section 9.3.2?
With the approval of ballot SC-62 Certificate Profiles Update, the TLS BRs now provide EV TLS certificate profile requirements. Review of the EV Guidelines indicated that the CA had the section 9.3.2 either/or choice which was compatible with the new TLS BR requirements. Entrust did not recognize the difference provided by section 9.7.

4. Why did Entrust not recognize the difference provided by section 9.7?
Entrust reviewed the requirements of the TLS BRs and the EV Guidelines. The EV Guidelines provide the section 9.3.2 choice of “MUST contain a policy identifier that is either defined by these Guidelines or the CA in the certificate’s certificatePolicies extension”, but also section 9.7 stated “The Issuer’s EV policy identifier”. “The Issuer’s EV policy identifier” language is different from the language used section 9.3.2, as such “The Issuer’s EV policy identifier” content was determined to be the result of the decision made from section 9.3.2.
.

5. Why did Entrust not detect the issue?
The pre-issuance and post-issuance linters that we used did not detect this issue.

Lessons Learned

What went well

What didn't go well

• Review of the TLS BR and EV Guidelines was misinterpreted.
• Certificates were issued which were non-compliant.
• Linting software did not detect the issue.

Where we got lucky

• Error was corrected by adding the EV certificate policy identifier back to the certificates

Action Items

Miss-issued certificates are a subset of the certificates disclosed in https://bugzilla.mozilla.org/show_bug.cgi?id=1883843 and are currently being revoked. Status of revocation can be reviewed here https://bugzilla.mozilla.org/show_bug.cgi?id=1886532 .

Action Item	Kind	Due Date
Add Entrust EV certificate policy identifier to EV certificates	Correct	2023-09-22
Deployment of pkilint as post-issuance linter in addition to existing linters	Detect	TBD

Appendix

Details of affected certificates

Certificates attached.

Comment 13

[Bruce Morton]

Pkilint was deployed to post-issuance linting on 11 April 2024.

Comment 14

[Bruce Morton]

We have no updates for this week and will continue to monitor the bug.

Comment 15

[Bruce Morton]

All actions are complete, there are no updates for this week and we will continue to monitor the bug.

Comment 16

[Ben Wilson]

I intend to close this bug on Friday, 3-May-2024.

Comment 17

[amir]

I intend to close this bug on Friday, 3-May-2024.

Does this mean that the Mozilla Root Program is happy with the remediation efforts from Entrust here? Does the Mozilla root program have any questions regarding this incident? Especially how this incident relates to the rest of the recent Entrust incidents?

Comment 18

[Ben Wilson]

We will respond concerning Entrust's issues, incidents, responses and remediation efforts in due course.

Comment 19

[Bruce Morton]

There are no updates for this week and we will continue to monitor the bug.

Comment 20

[Ben Wilson]

I'll leave this bug open because the listed certificates are a subset of certificates listed as being revoked under bug #1883843 and bug #1886532.

Comment 21

[Bruce Morton]

There are no updates for this week and we will continue to monitor the bug.

Comment 22

[Ben Wilson]

I am setting the Next Update to 2024-06-28 because this is being left open per Comment #20.

Comment 23

[Bruce Morton]

(In reply to Ben Wilson from comment #22)

I am setting the Next Update to 2024-06-28 because this is being left open per Comment #20.

Hi Ben, we currently addressing the open items per comment #20 and will plan to provide an update by 2024-07-05.

Comment 24

[Bruce Morton]

Action Items

Action Item	Kind	Due Date
Add Entrust EV certificate policy identifier to EV certificates	Correct	Done
Deployment of pkilint as post-issuance linter in addition to existing linters	Detect	Done

Comment 25

[Bruce Morton]

(In reply to Bruce Morton from comment #23)

(In reply to Ben Wilson from comment #22)

I am setting the Next Update to 2024-06-28 because this is being left open per Comment #20.

Hi Ben, we currently addressing the open items per comment #20 and will plan to provide an update by 2024-07-05.

Hi Ben, all actions are closed including those associated with comment #20. Requesting to have this bug closed.

Comment 26

[Ben Wilson]

I'll close this on or about Wed. 10-July-2024, unless there are items to discuss or review.

Comment 27

[Ben Wilson]

As an added note, we may add action items related to this bug to Bug #1901270 for Entrust to address. Such items would be required as remediation for compliance issues identified in the June 21 report and in any responses from Mozilla and the Mozilla community.