1914065 - Entrust: S/MIME certificates lacking OU verification

Status: ASSIGNED

(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/127.0.0.0 Safari/537.36

Comment 1

[Bruce Morton]

Preliminary Incident Report

Summary

Based on an internal review, we determined that the OU field was not verified in some S/MIME certificates, in accordance with the S/MIME BRs section 7.1.4.2.2.c:

If present, the CA SHALL confirm that the subject:organizationalUnitName is the full legal organization name of an Affiliate of the subject:organizationName in the Certificate and has been verified in accordance with the requirements of Section 3.2.3.

All S/MIME certificates issued in accordance with the S/MIME BRs lacking verification of OUs are considered to be mis-issued and must be revoked per S/MIME BR 4.9.1.1 item 11.

Impact

We identified 1039 S/MIME Sponsor-Validated certificates that were mis-issued where the certificates included an S/MIME BR certificate policy OID and where the subject OU field was not verified in accordance with the S/MIME BRs.

All Subscribers were advised of the miss-issued certificates.

Revocation has been completed for all mis-issued S/MIME certificates.

Next steps

A full incident report including the root cause analysis, lessons learned, and action items will be posted per the CCADB full incident report requirement.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug is invalid.
If you think the bot is wrong, please reopen the bug and move it back to its prior component.
If your bug description is written in a non-English language, please use Google Translate or a similar service to translate it.

Please note that this is a production bug database used by the Mozilla community to develop Firefox, Thunderbird and other products.
Filing test bugs here will waste the time of our contributors, volunteers and employees.
Accounts that abuse bugzilla.mozilla.org will be disabled.

Comment 3

[Bruce Morton]

Attachment: smime_orgid_cert_list_20240826.xlsx

Affected certificates

Comment 4

[Bruce Morton]

Attachment: smime_ou_cert_list_20240819.csv

Affected certificates

Comment 5

[Bruce Morton]

Incident Report

Summary

Based on an internal review, we determined that the OU field was not verified in some S/MIME certificates, in accordance with the S/MIME BRs section 7.1.4.2.2.c:

If present, the CA SHALL confirm that the subject:organizationalUnitName is the full legal organization name of an Affiliate of the subject:organizationName in the Certificate and has been verified in accordance with the requirements of Section 3.2.3.

All S/MIME certificates issued in accordance with the S/MIME BRs lacking verification of OUs are considered to be mis-issued and must be revoked per S/MIME BR 4.9.1.1 item 11.

Impact

We identified 1039 S/MIME Sponsor-Validated certificates that were mis-issued where the certificates included an S/MIME BR certificate policy OID and where the subject OU field was not verified in accordance with the S/MIME BRs.

Timeline

All times are UTC.

2023-06-23:

• Entrust provided an S/MIME BR soft launch, which permitted Subscribers to issue S/MIME certificates meeting the S/MIME BRs where the certificate would include an S/MIME BR certificate policy OID.

2024-08-09:

• S/MIME certificate profile for new S/MIME CA was finalized. The certificate profile did not permit the subject OU field.

2024-08-15:

• 14:36 Post issuance linting software for the new S/MIME profile was tested with current S/MIME certificates. There was a failure as some of the existing S/MIME certificates had the OU field.
• 17:37 Development team asked if the OU field should be supported from the new S/MIME CA to enable continued support for existing customers.
• 20:54 Compliance team confirmed that the OU field is permitted in the S/MIME BRs. Compliance team asked Validation Team to confirm the OU was verified in accordance with the S/MIME BRs. This is considered to be the time of the CPR submission.

2024-08-19:

• 15:00 Verification and Product Management finalized the investigation of S/MIME OU verification and concluded that the practices were not in accordance with the S/MIME BRs. The issue was escalated to the Incident Response Team. The submission of the issue is treated as a CPR submission.
• 19:26 Issuance was modified to decline certificate issuance from all Subscribers with OU items.
• 22:00 System upgraded to block OU approval for all certificate types.

2024-08-20:

• 06:26 All affected customers were notified of the mis-issued certificates.
• 15:12:24 Revocation of mis-issued certificates completed.

Root Cause Analysis

Background

When initially planning for support of the S/MIME BRs, the OU was field was not included in the S/MIME certificate profile since the trend in the public trust certificate ecosystem has been to deprecate the OU field.

During S/MIME BR certificate release testing it was decided to maintain support for the OU field to continue to support key escrow for Subscribers which have the OU field in their certificate. The OU field was required, since without this field the subject name would change, which with the system design in place at the time, would remove the match during certificate renewal. With no match, the history of escrowed keys would be disrupted.

Reintroduction of the OU field occurred late in the release cycle. Development review of reintroducing indicated that the OU field is a verified field. As such, it was determined that reintroduction would not cause an issue.

This is where the problem was introduced. The initial design did not support OU and so the verification process was not updated to support the new S/MIME BR OU verification requirements. When the decision to continue support of the OU field was made, the impact on the verification requirements was not revisited.

Why were the S/MIME certificates issued lacking OU verification?

The OU fields were verified, but not to the S/MIME BR requirements. The OU fields were still being verified to the requirements used before the S/MIME BRs were published which is the same as the requirements in the CSBRs.

Why were the OU fields not verified to the S/MIME BR requirements?

Original S/MIME BR certificate profile design did not allow the OU field. During development it was discovered that some existing Subscribers use the OU field and private key history (escrow). Removal of the OU field would mean the Subject DN would change and the software design would mean the Subscribers would lose key history. As such, the requirements were changed to continue allowing the OU field. However, the OU verification changes needed to comply with the S/MIME BR requirements were not updated in this design change.

Why was the OU verification per the S/MIME BR requirements not included in the design change?

When the decision was made to retain the OU field, it was determined that the OU field is allowed and must be verified. The design supported the verification requirement; however since the OU field was originally not supposed to be supported, the OU verification requirements were not updated.

Why were the OU requirements inadvertently omitted?

The update process did not involve all impacted parties, which includes the Verification team. If all parties reviewed the change proposal, then the verification requirement would have been determined. With this determination, either the OU would have been dropped as originally planned or the verification process would have been updated.

Why did the update process did not involve all impacted parties?

It was believed the review before implementation was thorough and there would be no compliance issue. We have determined in the last few months that our compliance change management policy and procedures needed to be updated to help remove similar compliance issues. The new policy was not in place at the time of the initial S/MIME BR certificate release.

Lessons Learned

What went well

• QA testing failure of a different test case started the investigation.

What didn't go well

• All impacted parties were not involved in the change process.

Where we got lucky

Action Items

Action Item	Kind	Due Date
Remove OU field from S/MIME certificates	Prevent	Done
Update Certificate Services Compliance Change Management Policy	Prevent	Done
Train all team leaders and personnel on the updated policy	Prevent	30 Sept 2024

Appendix

Details of affected certificates

Affected certificates have been posted per comment #4.