1910237 - Entrust: Delayed Revocation for S/MIME certificates

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]

Incident Report

Summary

We previously submitted two incident reports covering a total of three (3) S/MIME certificates where errors were detected through post-issuance linting, https://bugzilla.mozilla.org/show_bug.cgi?id=1906467 and https://bugzilla.mozilla.org/show_bug.cgi?id=1906470.

When potential errors were initially flagged through linting, Entrust personnel reviewed them to confirm whether they were in fact mis-issuances. Once the notifications were confirmed to be mis-issuances, we started the revocation process and that was the point from which we measured the 5-day revocation timeline. We believed that this practice was appropriate and in accordance with the language in with S/MIME BR section 4.9.1.1. that states:

… The CA SHOULD revoke a Certificate within 24 hours and SHALL revoke a Certificate within 5 days if one or more of the following occurs:
… Item 11. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s CP and/or CPS.

Comment 8 on Bug 1906467 suggests that this practice is not in accordance with the language in s. 4.9.5, which states that the timeframe for revocation starts when a CPR or a revocation related notice is received, not after it has been investigated and confirmed. We believe that is also a reasonable interpretation of the requirements based on:

The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation SHALL NOT exceed the time frame set forth in Section 4.9.1.1.

As a best practice we believe we should adopt a more conservative approach if there is ambiguity. As such, we have updated our practice to now start the 5-day revocation period when an issue is reported, not when it is confirmed to be a mis-issuance.

Impact

Three (3) S/MIME Sponsor-Validated certificates were revoked beyond the 5-day revocation deadline by 12:08, 00:47, and 11:14 hours respectively.

Timeline

All times are UTC.

[Bug #1906467]

2024-07-02:

• 19:50 Email received from post-issuance linting software indicating an error was found by pkilint that a mailbox address was “not found in SAN”.

2024-07-03:

• 10:58 Investigation determined that a certificate was mis-issued because it was not in accordance with section 7.1.4.2.1 of the S/MIME Baseline Requirements. Analysis completed in approximately 15 hours, within our 24-hour review period target.

2024-07-08:

• 07:58 First mis-issued certificate was revoked. This was within the 5-day required revocation period started from when mis-issuance was determined, not when the report is initially received.

---

[Bug #1906470]

2024-07-03:

• 19:07 pkilint back test data on previously issued certificates was provided and analysis begun.

2024-07-04:

• 05:04 Review of the pkilint report determined that two (2) S/MIME certificates were mis-issued because they were not in accordance with section 7.1.4.2.1 of the S/MIME Baseline Requirements (S/MIME BRs). Analysis completed in approximately 10 hours, within our 24-hour review period target.

  2024-07-08:

• 11:44:50 Second mis-issued certificate was revoked.

• 22:11:42 Third mis-issued certificate was revoked.

These were within the 5-day required revocation period started from when mis-issuance was determined, not when the pkilint results were initially generated.

Root Cause Analysis

Why was the S/MIME certificate not revoked within the 5-day period from receipt of CPR?

Our process allows for a 24-hour period for the error email to be reviewed and confirmed before a mis-issuance is confirmed. In our practice, that review period was in addition to the 5-day revocation period.

Why is there a review period for the error email?

The post issuance linting is designed for all certificate types. This includes certificates which are not supported by zlint or pkilint. This process can often produce false positives which must be reviewed to determine if there is in fact a mis-issuance. That investigation is necessary to ensure that any subsequent actions, including notification to subscribers and revocation are appropriate.

Why are there false positives?

The post-issuance linter uses zlint, pkilint and custom lints. This linter tests all certificates whether they are public or private trust and for all use cases (e.g., TLS, S/MIME Code Signing, Document Signing, and VMC). Post-issuance linting is primarily relied on as an audit check and has not been finely tuned to remove false positives.

Why was the revocation start time set to the time the investigation was completed instead of when the CPR was received?

The automated email and CPRs in general are not conclusive until they are investigated to determine whether a certificate was or was not mis-issued. The current process provides 24 hours to complete this investigation. If it is determined that the report was, in fact, a mis-issuance, the 5-day revocation period is set based on the time of that determination.

Why was the error not detected by pre-issuance linting?

Pre-issuance or pre-sign linting is an actively planned update but at the time of issuance had not yet been implemented for these S/MIME certificates.

Lessons Learned

What went well

• The investigation period is limited to 24-hours, so had minimal impact to extending the revocation period.

What didn't go well

• Revocation deadline was not started when the error email (CPR) was received.

Where we got lucky

Action Items

Action Item	Kind	Due Date
Change issue management process to start revocation period when the CPR or internal report is received	Prevent	Done
Implement pre-sign linting for S/MIME	Prevent	2024-11-30

Appendix

Details of affected certificates

Issuer: https://crt.sh/?caid=12549

• S/N: CB48483E66A43F98000000004C3DD077; SHA-256 Fingerprint: 17D0710111F06B2E458B429D48AB2E92E863D5645A515F6F4D0D627238997995
• S/N: 3C7AC3C16A2B8B02000000004C3D9978; SHA-256 Fingerprint: 3B83442FF64EDBC8D8014DA546254CC61655D6C212FE02C4AE6C0720914E2051
• S/N: 2CF9C22BF6397B0E000000004C3D603F; SHA-256 Fingerprint: C6CDAC4AA517097A8573E74919A0EF086F8C3A834F499AB1205674CD385EE894

Comment 2

[Alexander P]

Despite recent events, I think it shows some amount of integrity that this was not "swept under the rug". It seems this could've been explained away with "The lint returns 500 findings per day, we cannot be expected to consider those all to be CPRs until they are reviewed. Once reviewed a human submits a CPR. Once that CPR is submitted, the clock is started." but this explanation was not offered.

I would suggest, though, that given how many delrev events Entrust and and other CAs have gone through this year and in recent history, Entrust should institutionally know that the clock does not start after the CPR is human-verified but instead when it is received. If Entrust themselves say that they categorize lint errors as CPRs, then they must certainly know there's no 24-hour window "for review" defined anywhere in the BRs.

I hope Entrust plans to begin following new and past threads on these forums and considering how they may grow from them. These threads all clarify the BR requirements about "when the clock starts":

https://bugzilla.mozilla.org/show_bug.cgi?id=1883731#c5
https://bugzilla.mozilla.org/show_bug.cgi?id=1887941#c0
https://bugzilla.mozilla.org/show_bug.cgi?id=1639801#c1
https://bugzilla.mozilla.org/show_bug.cgi?id=1640310#c0
https://bugzilla.mozilla.org/show_bug.cgi?id=1649880#c7

https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.0.5.pdf

Comment 3

[Paul van Brouwershaven]

(In reply to Alexander P from comment #2)

Thanks Alexander, we have updated our issue management process to start revocation period when the CPR or internal report is received as described in the action items.

Comment 4

[Paul van Brouwershaven]

We have no updates for this week but will keep following this bug for any questions or feedback.

May we please set the next update at 2024-09-04.

Comment 5

[Bruce Morton]

Implementation of pre-sign linting of S/MIME certificates is on track.

May we please set the next update to be 31 October 2024? Thanks.

Comment 6

[Bruce Morton]

We are on track to implement pre-sign linting for S/MIME before 2024-11-30.

May we please set the next update to be2024-11-30? Thanks.

Comment 7

[Bruce Morton]

Action Items

Action Item	Kind	Due Date
Change issue management process to start revocation period when the CPR or internal report is received	Prevent	Done
Implement pre-sign linting for S/MIME	Prevent	Done

Pre-sign linting for S/MIME deployed 2024-11-07.

All actions are completed. We request this bug be closed. Thanks.

Comment 8

[Ben Wilson]

I will consider closing this on or about next Wed. 13-Nov-2024, unless there is ongoing discussion.