1959721 - Lawtrust: The S/MIME CA’s policy identifiers did not align with the CA/Browser Forum Requirements.

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Marcile De Waal]

Attachment: RCA - S/Mime audit finding

1. Summary
The following observations were made regarding the issuance of test certificates during our S/MIME audit for the period 1 January 2024 – 31 Dec 2024:

Observation Relevant WebTrust Criteria
1 The S/MIME CA’s policy identifiers did not align with LAWtrust-CA’s disclosed Business Practices. Principle 1: The Certification Authority (CA) discloses its S/MIME Certificate practices and procedures and its commitment to provide S/MIME Certificates in conformity with the applicable CA/Browser Forum Requirements.
2 The S/MIME CA’s policy identifiers did not align with the CA/Browser Forum Requirements. Principle 2: The Certification Authority (CA) maintains effective controls to provide reasonable assurance that:
• Subscriber information was properly collected, authenticated (for registration activities performed by the CA, Registration Authority (RA) and subcontractor) and verified;
• The integrity of keys and certificates it manages is established and protected throughout their life cycles.

This is an example of the certificate policy identifiers in test certificates that we issued in 2024:

With the subject name formatted like this:

The auditors when they started looking at the sampling in January 2025 indicated that we cannot have the OU / O / C in our DN of the certificate when we do Individual-validated certificates. After quite a bit of to and fro, and no way of changing the actual DN to not include those three items, we made the call to change to organization-validated certs that will allow that in the DN. The change unfortunately was not finalised in the audit period. Hence the observation. We then changed the policies to the information as per the certificate attached to this incident report.

2. Impact
Only 12 internal/test user certificates were issued.
1 Audit test certificate was issued
None of the incorrectly issued certificates have been used except for internal testing

3. Timeline
2024 (Various dates and times as listed below)
12 users were created and Internal User Certificates were issued in 2024 for testing purposes and to establish and document procedures. The certificates are dual keypair, so a verification certificate and an encryption certificate were issued for each.
List of activated certificates are as indicated below in the Appendix below. The DNs of the certificates have not been included in the list because they containing ID numbers. The format of the DN of the certificates was : serialNumber=1234567899+cn=Test_Marcus 113452+Email=[e-mail],ou=Altron Class 3 RA,o=Lawtrust,c=ZA

Certificates were issued without the certificate policy identifier for the certificate types.
14 Mar 2024 08:24:47 UTC
First S/MIME Test Certificate pair (Encyption and Verification) issued
(See Appendix below for dates and times of certificate issuance)

1 Nov 2024 10:00 UTC
S/MIME audit started on 1 November 2024

15 Nov 2024 12:45 UTC
On 15 Nov 2024 10:45 a test certificate was issued for the auditors
ent_smime:Encryption 372EE097216860721BB4D7B51A823962 Fri Nov 15 10:45:02 2024
ent_smime:Verification 5C80A53D3725F926C75A74860C099489 Fri Nov 15 10:45:02 2024

3 Dec 2024 15:00 UTC
On 3 Dec 2024 13:00 it was indicated that the certificate policy identifier is missing from the certificate policies

4 Dec 2024 09:53 UTC
On 4 Dec 2024, 07:53 a change control was logged to change the certificate template and add the Mailbox-validated Multipurpose : 2.23.140.1.5.1.2 Policy identifier to the certificate policies.

5 Dec 2024 10:46 UTC
On 5 Dec 2024 08:46 The policy identifier of 2.23.140.1.5.4.2 was added to the certificate and the sample re-issued for the audit. At that point in time the changed policy was accepted.
ent_smime:Encryption 00FF84ECEC03B032A1DD5700275FC2637D Thu Dec 5 08:46:36 2024
ent_smime:Verification 1C2271B7A8FFAEC224CD1C716787BCB4 Thu Dec 5 08:46:36 2024

13 Feb 2025 11:00 UTC
On 13 February 2025 in a meeting with the auditors between 09:00 – 10:00 it was indicated that our DN on our certificates is not correct for individual-validated certificates, and after discussions on the DN of the certificate we determined that we can only issue Organization-validated certificates as that is the only certificate policy that allows us to include the RA in the DN of the user certificate.

14 Feb 2025 16:26 UTC
7. On 14 Feb 2025 14:26 a change was logged to change the Policy Identifier to Organization-validated certificates (2.23.140.1.5.2.2) to allow for the DN to be valid and to add the Organization identifier to the certificate.

17 Feb 2025 16:00 UTC
On 17 Feb 2025 between 14:00 and 15:00 testing for the new Identifier and Organization Identifier was concluded.

18 Feb 2025 14:35
On 18 February 2025 12:35 the new Identifier and Organization Identifier was implemented in production.

19 Feb 2025 18:47 UTC
On 19 February 2025 16:47 a new sample certificate was issued.
ent_smime:Verification 34c9a77a941718c1ee9166360ecd39e5 ‎Wed ‎19 ‎Feb ‎2025 16:47:55

13 March 2025 16:35
On 13 March 2025, 14:35 – 14:45. After auditors confirmed that the new Policy identifier is acceptable, all issued user certificates were revoked, and new CRL was issued.
http://crl.lawtrust.co.za/CRL/lawtrust_secure_ca01_lawtrust_za_crlfile1.crl

9. None of the incorrectly issued certificates have been used except for internal testing.

All times are UTC.

4. Root Cause Analysis
During the implementation of S/MIME certificate profiles in preparation for compliance with the CA/Browser Forum’s S/MIME Baseline Requirements (SBRs), the CA team applied a Policy Identifier (OID) that did not align with the structure of the Distinguished Name (DN) used in the certificates. The error stemmed from a misinterpretation of Section 7.1.6.3 of the SBRs, which links specific policy OIDs to certificate profile categories (e.g., Legacy, Multipurpose, Strict).
A “5 Whys” analysis revealed the following contributing factors:

1. Why was the wrong policy OID used?
   → The certificate profile was designed using an internal spreadsheet that had not been cross-validated with the latest version of the SBRs.
2. Why wasn’t the profile validated against the SBRs?
   → The compliance review process was informal and lacked a checklist or peer review step.
3. Why was there no formal checklist or peer review?
   → The documented implementation procedure for new policy requirements was not adequate for S/Mime implementation.
4. Why was no documented procedure in place?
   → The current process for translating new external requirements into actionable internal workflows was not adequate.
5. Why was this process gap not identified earlier?
   → Past compliance efforts relied on a small team’s institutional knowledge without systematic knowledge transfer or onboarding.
   Additional contributing factors:
   • Ambiguities in the SBRs led to varying interpretations.
   • The engineer responsible for implementing the change was not subscribed to relevant policy working group mailing lists and missed clarifications discussed there.
   • The CA’s linter tool did not have SBR-specific validation rules enabled at the time of issuance.

5. Lessons Learned
• Policy interpretation must be validated against primary sources (e.g., the Baseline Requirements) and not derived solely from internal documentation or past practices.
• All new certificate profiles must undergo a documented policy compliance review, including peer validation and a mapping of profiles to applicable requirements.
• S/MIME linting rules (e.g., zlint) should be implemented before issuing certificates under the new profiles to detect structural and policy compliance issues early.
• Engineering and compliance teams must have a shared understanding of requirements. Cross-functional review improves interpretation accuracy.
• CA staff must stay informed about current policy changes by subscribing to relevant working groups and participating in discussions when needed.

6. Corrective and Preventive Action Items

Update the certificate profile to apply the correct Policy Identifier to the certificate, Corrective action, 2025-02-18 (Done)
Re-issue mississued certificates, Corrective action, 2025-03-15 (Done)
Implement Formal Certificate Profile Approval Workflow, Corrective action, 30 April 2025
Do SBR Compliance Checks with a linter tool, Preventative action, 15 April 2025 (Done)
Ensure that CA/Browser Forums discussion are monitored and maintain an internal change log , Preventative action, 30 April 2025
Arrange a training session for engineering and compliance staff on interpreting SBR’s, especially policy OID’s and DB structure, Preventative action, 30 April 2025

7. Appendix
Details of affected certificates:
certDefn serialNumber issueDate
ent_smime:Encryption 00F5002CF7520978220A083120DA794ABD Thu Mar 14 06:24:47 2024
ent_smime:Verification 00DA175878752DCAA8AFDE2123F1EDE29A Thu Mar 14 06:24:47 2024
ent_smime:Encryption 00E688A93DC66F06EB5B7C9EC7D9826E92 Thu Mar 14 07:12:01 2024
ent_smime:Verification 00969ED496AD2C6C2F85B3ABF6322C32ED Thu Mar 14 07:12:01 2024
ent_smime:Encryption 3998CB3A346599648D7A2590079814BF Mon Oct 21 08:22:56 2024
ent_smime:Verification 6E6EC28ED089B5A2EC87DA9FFE3B8709 Mon Oct 21 08:22:56 2024
ent_smime:Encryption 66DBBBB409F267E989A63C8E55994D15 Mon Oct 21 08:16:07 2024
ent_smime:Verification 00BAF05F009D2A677B4E8C2F2E6548AFE3 Mon Oct 21 08:16:07 2024
ent_smime:Encryption 4B1A63300C5879AD95AFA82936AB5D90 Mon Oct 21 08:13:08 2024
ent_smime:Verification 4BF57F6A37571124984AB33F24C04846 Mon Oct 21 08:13:08 2024
ent_smime:Encryption 00F56B87894A85E9720F2A113E23C3DB39 Fri Oct 25 06:26:00 2024
ent_smime:Verification 7BCD840001FB80C84EDAA7A4D86D859F Fri Oct 25 06:26:00 2024
ent_smime:Encryption 71BBDD62300D6F281827EC9473D25177 Fri Oct 25 10:46:47 2024
ent_smime:Verification 00FFFC2900CF85CDFA8749F9AD9FA55676 Fri Oct 25 10:46:47 2024
ent_smime:Encryption 00B91E4165403DCA06DB5A2346FEF23447 Tue Nov 5 07:37:06 2024
ent_smime:Verification 0096521E0948C37663F66710E63A670602 Tue Nov 5 07:37:06 2024
ent_smime:Encryption 00A2769A2916B52AA1737E5DB7226A6E90 Mon Nov 11 13:42:13 2024
ent_smime:Verification 00DFA7B4C38A6C150541AFFCF4CFE1F3FF Mon Nov 11 13:42:13 2024
ent_smime:Encryption 372EE097216860721BB4D7B51A823962 Fri Nov 15 10:45:02 2024
ent_smime:Verification 5C80A53D3725F926C75A74860C099489 Fri Nov 15 10:45:02 2024
ent_smime:Encryption 00F9F80936B4660A43BA505B6F642D1BEF Tue Nov 19 16:06:42 2024
ent_smime:Verification 008A6A161F18A3085B624647C3D1660270 Tue Nov 19 16:06:42 2024
ent_smime:Encryption 7F9F7ABBCA175375281CB41491302CB8 Thu Dec 5 08:39:05 2024
ent_smime:Verification 287D1C96866581689E1F64925D28D70E Thu Dec 5 08:39:05 2024
ent_smime:Encryption 00FF84ECEC03B032A1DD5700275FC2637D Thu Dec 5 08:46:36 2024
ent_smime:Verification 1C2271B7A8FFAEC224CD1C716787BCB4 Thu Dec 5 08:46:36 2024

They are listed on the crl.
http://crl.lawtrust.co.za/CRL/lawtrust_secure_ca01_lawtrust_za_crlfile1.crl

Comment 1

[Malcolm D]

(In reply to Marcile De Waal from comment #0)

This is an example of the certificate policy identifiers in test certificates that we issued in 2024:

With the subject name formatted like this:

There appears to be text missing from your post

Comment 2

[Martijn Katerbarg]

Based on The December 3rd and the February 13th items, it is unclear to me whether Lawtrust has a single incident here (incorrect Reserved OID), or two different incidents (Incorrect Reserved OID and Incorrect Subject DN). Could you please clarify?

If Lawtrust became aware of the incorrect OIDs on December 3rd, why did it take until March 13th to revoke the affected certificates?

If Lawtrust became aware of the incorrect OIDs on December 3rd, why did it take until today to open the incident report?

Note that as of March 1st, 2025, a new incident report template is required, which this incident did not utilize.

Comment 3

[Marcile De Waal]

(In reply to Malcolm D from comment #1)

(In reply to Marcile De Waal from comment #0)

This is an example of the certificate policy identifiers in test certificates that we issued in 2024:

With the subject name formatted like this:

There appears to be text missing from your post

Hi Malcom,
I couldn't get the sceenshots into the bug, that is why i attached the PDF document with the details in it. Here is the missing piece though:

Policy Identifiers:
[1]Certificate Policy:
Policy Identifier=1.3.6.1.4.1.54383.1.2.3
[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
https://www.lawtrust.co.za/repository
[1,2]Policy Qualifier Info:
Policy Qualifier Id=User Notice
Qualifier:
Notice Text=LAWtrust issues Certificates to subscribers as outlined by the LAWtrust Certification Practice Statement (CPS) which can be found at https://www.lawtrust.co.za/repository.
[2]Certificate Policy:
Policy Identifier=2.23.140.1.5.4.2

With the subject name formatted like this:
0.9.2342.19200300.100.1.3 = [e-mail]
CN = Marcus Craveiro
SERIALNUMBER = 7908185048086
CN = LAWtrust Secure CA01
O = Lawtrust
C = ZA

Comment 4

[Marcile De Waal]

(In reply to Martijn Katerbarg from comment #2)

Based on The December 3rd and the February 13th items, it is unclear to me whether Lawtrust has a single incident here (incorrect Reserved OID), or two different incidents (Incorrect Reserved OID and Incorrect Subject DN). Could you please clarify?

If Lawtrust became aware of the incorrect OIDs on December 3rd, why did it take until March 13th to revoke the affected certificates?

If Lawtrust became aware of the incorrect OIDs on December 3rd, why did it take until today to open the incident report?

Note that as of March 1st, 2025, a new incident report template is required, which this incident did not utilize.

Hi Martin,
It is one incident where we had planned on using on OID with a specific DN format, that had to be changed to a different OID with another DN format.
3rd Dec - we made specific changes for the audit, and they at that point in time were happy with the changes made. We didn't make anymore changes at that point in time, wanting to make sure that what we did was correct before we started revoking and re-issuing taking into consideration that all our certs were internal test certs still. We have not issued any client certificates yet.
13th March - We had a meeting with the auditors and had confirmation of the way forward and went ahead and revoked all the issued certificates at that point in time.

I waited with the incident report until we knew the impact on our audit report and had confirmation of what needed to happen to resolve the issue. I want to stress the fact that we have only issued internal test certificates at this point in time.

On the report template - I have tried to get the report as complete as possible, pse let me know what i missed that i can add it to a final report.

Comment 5

[Martijn Katerbarg]

On the report template - I have tried to get the report as complete as possible, pse let me know what i missed that i can add it to a final report.

Please review https://www.ccadb.org/cas/incident-report, which is at version 3.0 as of March 1st, 2025 with a required template shown at https://www.ccadb.org/cas/incident-report#full-incident-report

I waited with the incident report until we knew the impact on our audit report and had confirmation of what needed to happen to resolve the issue.

The above mentioned page states the requirements for when a preliminary report needs to be posted and when a full incident report is expected.

Comment 6

[chrome-root-program]

This report has gone stale and has not yet addressed Comment 5.

Comment 7

[Marcile De Waal]

Full Incident Report

Summary

• CA Owner CCADB unique ID:
  A000282

• Incident description:
  During the implementation of S/MIME certificate profiles in preparation for compliance with the CA/Browser Forum’s S/MIME Baseline Requirements (SBRs), the CA team applied a Policy Identifier (OID) that did not align with the structure of the Distinguished Name (DN) used in the certificates. The error stemmed from a misinterpretation of Section 7.1.6.3 of the SBRs, which links specific policy OIDs to certificate profile categories (e.g., Legacy, Multipurpose, Strict).

• Timeline summary:

  • Non-compliance start date:
    14 March 2024
  • Non-compliance identified date:
    3 Dec 2024
  • Non-compliance end date:
    13 March 2025 (No certificates were issued between 3 Dec 2024 and 13 March 2025)

• Relevant policies:
  CPS
  [2]Certificate Policy:
  Policy Identifier=2.23.140.1.5.4.2

• Source of incident disclosure:
  Yearly Webtrust and S/Mime Audit

Impact

• Total number of certificates:
  12 internal or test users were created
  1 audit test user was created

• Total number of "remaining valid" certificates:
  0 - no other certificates was issued, and all incorrectly certificates was revoked

• Affected certificate types:
  End User S/Mime certificates

• Incident heuristic:
  3 - All affected certificates are disclosed in the Appendix

• Was issuance stopped in response to this incident, and why or why not?:
  Yes, issuance was stopped. Only test certificates was issued for the audit, so limited certificates was issued.

• Analysis:

The following observations were made regarding the issuance of test certificates during our S/MIME audit for the period 1 January 2024 – 31 Dec 2024:
1 The S/MIME CA’s policy identifiers did not align with LAWtrust-CA’s disclosed Business Practices.
Principle 1: The Certification Authority (CA) discloses its S/MIME Certificate practices and procedures and its commitment to provide S/MIME Certificates in conformity with the applicable CA/Browser Forum Requirements.
2 The S/MIME CA’s policy identifiers did not align with the CA/Browser Forum Requirements.
Principle 2: The Certification Authority (CA) maintains effective controls to provide reasonable assurance that:
• Subscriber information was properly collected, authenticated (for registration activities performed by the CA, Registration Authority (RA) and subcontractor) and verified;
• The integrity of keys and certificates it manages is established and protected throughout their life cycles.

Certificates were issued with the following identifiers:
Policy Identifiers:
[1]Certificate Policy:
Policy Identifier=1.3.6.1.4.1.54383.1.2.3
[1,1]Policy Qualifier Info:
Policy Qualifier Id=CPS
Qualifier:
https://www.lawtrust.co.za/repository
[1,2]Policy Qualifier Info:
Policy Qualifier Id=User Notice
Qualifier:
Notice Text=LAWtrust issues Certificates to subscribers as outlined by the LAWtrust Certification Practice Statement (CPS) which can be found at https://www.lawtrust.co.za/repository.
[2]Certificate Policy:
Policy Identifier=2.23.140.1.5.4.2

With the subject name formatted like this:
0.9.2342.19200300.100.1.3 = [e-mail]
CN = Marcus Craveiro
SERIALNUMBER = 7908185048086
CN = LAWtrust Secure CA01
O = Lawtrust
C = ZA

During the implementation of S/MIME certificate profiles in preparation for compliance with the CA/Browser Forum’s S/MIME Baseline Requirements (SBRs), the CA team applied a Policy Identifier (OID) that did not align with the structure of the Distinguished Name (DN) used in the certificates. The error stemmed from a misinterpretation of Section 7.1.6.3 of the SBRs, which links specific policy OIDs to certificate profile categories (e.g., Legacy, Multipurpose, Strict).

• Additional considerations:
  All 12 certificates issued where internal certificates to determine the process and test the environment surrounding the CA assisting in the download of the certificates.

Timeline

2024 (Various dates and times as listed below)
12 users were created and Internal User Certificates were issued in 2024 for testing purposes and to establish and document procedures. The certificates are dual keypair, so a verification certificate and an encryption certificate were issued for each.
List of activated certificates are as indicated below in the Appendix below. The DNs of the certificates have not been included in the list because they containing ID numbers. The format of the DN of the certificates was : serialNumber=1234567899+cn=Test_Marcus 113452+Email=[e-mail],ou=Altron Class 3 RA,o=Lawtrust,c=ZA

Certificates were issued without the certificate policy identifier for the certificate types.
14 Mar 2024 08:24:47 UTC
First S/MIME Test Certificate pair (Encyption and Verification) issued
(See Appendix below for dates and times of certificate issuance)

1 Nov 2024 10:00 UTC
S/MIME audit started on 1 November 2024

15 Nov 2024 12:45 UTC
On 15 Nov 2024 10:45 a test certificate was issued for the auditors
ent_smime:Encryption 372EE097216860721BB4D7B51A823962 Fri Nov 15 10:45:02 2024
ent_smime:Verification 5C80A53D3725F926C75A74860C099489 Fri Nov 15 10:45:02 2024

3 Dec 2024 15:00 UTC
On 3 Dec 2024 13:00 it was indicated that the certificate policy identifier is missing from the certificate policies

4 Dec 2024 09:53 UTC
On 4 Dec 2024, 07:53 a change control was logged to change the certificate template and add the Mailbox-validated Multipurpose : 2.23.140.1.5.1.2 Policy identifier to the certificate policies.

5 Dec 2024 10:46 UTC
On 5 Dec 2024 08:46 The policy identifier of 2.23.140.1.5.4.2 was added to the certificate and the sample re-issued for the audit. At that point in time the changed policy was accepted.
ent_smime:Encryption 00FF84ECEC03B032A1DD5700275FC2637D Thu Dec 5 08:46:36 2024
ent_smime:Verification 1C2271B7A8FFAEC224CD1C716787BCB4 Thu Dec 5 08:46:36 2024

13 Feb 2025 11:00 UTC
On 13 February 2025 in a meeting with the auditors between 09:00 – 10:00 it was indicated that our DN on our certificates is not correct for individual-validated certificates, and after discussions on the DN of the certificate we determined that we can only issue Organization-validated certificates as that is the only certificate policy that allows us to include the RA in the DN of the user certificate.

14 Feb 2025 16:26 UTC
7. On 14 Feb 2025 14:26 a change was logged to change the Policy Identifier to Organization-validated certificates (2.23.140.1.5.2.2) to allow for the DN to be valid and to add the Organization identifier to the certificate.

17 Feb 2025 16:00 UTC
On 17 Feb 2025 between 14:00 and 15:00 testing for the new Identifier and Organization Identifier was concluded.

18 Feb 2025 14:35
On 18 February 2025 12:35 the new Identifier and Organization Identifier was implemented in production.

19 Feb 2025 18:47 UTC
On 19 February 2025 16:47 a new sample certificate was issued.
ent_smime:Verification 34c9a77a941718c1ee9166360ecd39e5 Wed 19 Feb 2025 16:47:55

13 March 2025 16:35
On 13 March 2025, 14:35 – 14:45. After auditors confirmed that the new Policy identifier is acceptable, all issued user certificates were revoked, and new CRL was issued.
http://crl.lawtrust.co.za/CRL/lawtrust_secure_ca01_lawtrust_za_crlfile1.crl

None of the incorrectly issued certificates have been used except for internal testing.

Related Incidents

No related incidents was logged

Root Cause Analysis

Contributing Factor 1: Incorrect Policy Identifier used

• Description:
  The policy identifier (OID) used for the S/Mime certificates was selected due to the type of certificates that would be issued from the CA, which was individual validated certificates. What was missed was the OU in the full DN of the users which indicated our RA which will be issuing the certificates that was invalid for individual validated certificates.

• Timeline:
  The certificates was issued during the course of 2024, with the bulk (10 of the 12) issued in Oct 2024

• Detection:
  The Webtrust Audit which included the S/MIME audit indicated in Feb 2025 that the OU cannot be used in indivudual validated certificates.

• Interaction with other factors:
  No other factors where experienced during the incident

• Root Cause Analysis methodology used:
  5-Whys was used after the detection to determine where we went wrong.
  A “5 Whys” analysis revealed the following contributing factors:

  Why was the wrong policy OID used?
  → The certificate profile was designed using an internal spreadsheet that had not been cross-validated with the latest version of the SBRs.
  Why wasn’t the profile validated against the SBRs?
  → The compliance review process was informal and lacked a checklist or peer review step.
  Why was there no formal checklist or peer review?
  → The documented implementation procedure for new policy requirements was not adequate for S/Mime implementation.
  Why was no documented procedure in place?
  → The current process for translating new external requirements into actionable internal workflows was not adequate.
  Why was this process gap not identified earlier?
  → Past compliance efforts relied on a small team’s institutional knowledge without systematic knowledge transfer or onboarding.
  Additional contributing factors:
  • Ambiguities in the SBRs led to varying interpretations.
  • The engineer responsible for implementing the change was not subscribed to relevant policy working group mailing lists and missed clarifications discussed there.
  • The CA’s linter tool did not have SBR-specific validation rules enabled at the time of issuance.

Lessons Learned

• What went well:
  We could control the certificates that was issued and the problem could be fixed once we determined what the problem was and what needed to be done to fix it.
• What didn’t go well:
  The controls on the CA/Browser Forum’s S/MIME Baseline Requirements (SBRs) was misinterpreted and the initial certificate policy identifier was incorrectly selected.
• Where we got lucky:
  The total count of certificates that was issued is very low and restricted to internal users.
• Additional:
  • Policy interpretation must be validated against primary sources (e.g., the Baseline Requirements) and not derived solely from internal documentation or past practices.
  • All new certificate profiles must undergo a documented policy compliance review, including peer validation and a mapping of profiles to applicable requirements.
  • S/MIME linting rules (e.g., zlint) should be implemented before issuing certificates under the new profiles to detect structural and policy compliance issues early.
  • Engineering and compliance teams must have a shared understanding of requirements. Cross-functional review improves interpretation accuracy.
  • CA staff must stay informed about current policy changes by subscribing to relevant working groups and participating in discussions when needed.

Action Items

Action Item	Kind	Corresponding Root Cause	Evaluation Criteria	Due Date	Status
Update certificate profile	Corrective	Root Cause # 1	Compare profile to CPS entries	2025-02-18	Done
Re-issue mississued certificates	Corrective	Root Cause # 1	Check all current certicates to ensure issued date after 1 March 2025	2025-03-15	Done
Implement formal Certificate Profile approval workflow	Corrective	Root Cause # 1	Workflow created and implemented	2025-04-30	Done
Do SBR Compliance Checks with a linter tool	Corrective	Root Cause # 1	Linter tool check passed without any errors	2025-04-15	Done
Ensure that CA/Browser Forums discussion are monitored	Preventative	Root Cause # 1	Subscriptions updated	2025-04-30	Done
Maintain an internal change log	Preventative	Root Cause # 1	Change log created	2025-04-30	Done
Arrange training for engineering and compliance staff	Corrective	Root Cause # 1	Knowledge levels increased after session	2025-04-30	Done

Appendix

CertDefn	Serial Number	IssueDate
ent_smime:Encryption	00F5002CF7520978220A083120DA794ABD	Thu Mar 14 06:24:47 2024
ent_smime:Verification	00DA175878752DCAA8AFDE2123F1EDE29A	Thu Mar 14 06:24:47 2024
ent_smime:Encryption	00E688A93DC66F06EB5B7C9EC7D9826E92	Thu Mar 14 07:12:01 2024
ent_smime:Verification	00969ED496AD2C6C2F85B3ABF6322C32ED	Thu Mar 14 07:12:01 2024
ent_smime:Encryption	3998CB3A346599648D7A2590079814BF	Mon Oct 21 08:22:56 2024
ent_smime:Verification	6E6EC28ED089B5A2EC87DA9FFE3B8709	Mon Oct 21 08:22:56 2024
ent_smime:Encryption	66DBBBB409F267E989A63C8E55994D15	Mon Oct 21 08:16:07 2024
ent_smime:Verification	00BAF05F009D2A677B4E8C2F2E6548AFE3	Mon Oct 21 08:16:07 2024
ent_smime:Encryption	4B1A63300C5879AD95AFA82936AB5D90	Mon Oct 21 08:13:08 2024
ent_smime:Verification	4BF57F6A37571124984AB33F24C04846	Mon Oct 21 08:13:08 2024
ent_smime:Encryption	00F56B87894A85E9720F2A113E23C3DB39	Fri Oct 25 06:26:00 2024
ent_smime:Verification	7BCD840001FB80C84EDAA7A4D86D859F	Fri Oct 25 06:26:00 2024
ent_smime:Encryption	71BBDD62300D6F281827EC9473D25177	Fri Oct 25 10:46:47 2024
ent_smime:Verification	00FFFC2900CF85CDFA8749F9AD9FA55676	Fri Oct 25 10:46:47 2024
ent_smime:Encryption	00B91E4165403DCA06DB5A2346FEF23447	Tue Nov 5 07:37:06 2024
ent_smime:Verification	0096521E0948C37663F66710E63A670602	Tue Nov 5 07:37:06 2024
ent_smime:Encryption	00A2769A2916B52AA1737E5DB7226A6E90	Mon Nov 11 13:42:13 2024
ent_smime:Verification	00DFA7B4C38A6C150541AFFCF4CFE1F3FF	Mon Nov 11 13:42:13 2024
ent_smime:Encryption	372EE097216860721BB4D7B51A823962	Fri Nov 15 10:45:02 2024
ent_smime:Verification	5C80A53D3725F926C75A74860C099489	Fri Nov 15 10:45:02 2024
ent_smime:Encryption	00F9F80936B4660A43BA505B6F642D1BEF	Tue Nov 19 16:06:42 2024
ent_smime:Verification	008A6A161F18A3085B624647C3D1660270	Tue Nov 19 16:06:42 2024
ent_smime:Encryption	7F9F7ABBCA175375281CB41491302CB8	Thu Dec 5 08:39:05 2024
ent_smime:Verification	287D1C96866581689E1F64925D28D70E	Thu Dec 5 08:39:05 2024
ent_smime:Encryption	00FF84ECEC03B032A1DD5700275FC2637D	Thu Dec 5 08:46:36 2024
ent_smime:Verification	1C2271B7A8FFAEC224CD1C716787BCB4	Thu Dec 5 08:46:36 2024

They are listed on the crl.
http://crl.lawtrust.co.za/CRL/lawtrust_secure_ca01_lawtrust_za_crlfile1.crl

Comment 8

[YAMADA Taro]

Thank you for the incident report. I have some questions.

1. It seems like the problem was found on February 13th, but the bad certificates were not revoked until March 13th. Why did it require a month to revoke?
2. On February 18th, the policy OID was changed to 2.23.140.1.5.2.2. What is in the common name attribute after this change? If possible, please share the entire DN.
3. In the root cause analysis, there were some ambiguities in the SMIME BR. Concretely, what are these ambiguities?
4. What linter was used to do the compliance checks?

It is interesting that the example certificate uses attribute with OID 0.9.2342.19200300.100.1.3 instead of the normal emailAddress attribute (1.2.840.113549.1.9.1), but I don't think it is wrong (just interesting).

Comment 9

[Martijn Katerbarg]

The change unfortunately was not finalised in the audit period. Hence the observation.

Please note, even if it had been finalised in the audit period, I would still expect an observation since other test certificates had already been issued incorrectly.

Based on the incident report, I understand you now issue the certificate as OV - Multipurpose (2.23.140.1.5.2.2), correct?

If so, based on the certificate details share in the attachment, it looks like there may be three other non-conformities:

• The certificate shown in https://bug1959721.bmoattachments.org/attachment.cgi?id=9478302 shows "rf822Name" has been added in the SubjectDN. The S/MIME BRs do not permit that for the Multipurpose profile.
• The "OU" field lists "Altron Class 3 RA". Is "Altron Class 3 RA" a registered organization name, or just a department within the organization?
• The certificate contains a Common Name which is neither the organization name, nor email address.

Since CT logs are generally not used for S/MIME certificates, I'm curious if you're willing to share the reissued certificate, or if you can confirm the above items have been resolved simultaniously when you updated the Policy OID.

It is interesting that the example certificate uses attribute with OID 0.9.2342.19200300.100.1.3 instead of the normal emailAddress attribute (1.2.840.113549.1.9.1), but I don't think it is wrong (just interesting).

If indeed these are issued under the Multipurpose profile/OID, then this would not be allowed according to the S/MIME BRs.

Comment 10

[Marcile De Waal]

(In reply to YAMADA Taro from comment #8)

Thank you for the incident report. I have some questions.

1. It seems like the problem was found on February 13th, but the bad certificates were not revoked until March 13th. Why did it require a month to revoke?
2. On February 18th, the policy OID was changed to 2.23.140.1.5.2.2. What is in the common name attribute after this change? If possible, please share the entire DN.
3. In the root cause analysis, there were some ambiguities in the SMIME BR. Concretely, what are these ambiguities?
4. What linter was used to do the compliance checks?

It is interesting that the example certificate uses attribute with OID 0.9.2342.19200300.100.1.3 instead of the normal emailAddress attribute (1.2.840.113549.1.9.1), but I don't think it is wrong (just interesting).

Hi Yamada,

1. The auditors asked us not to revoke yet, they wanted to confirm the configuration we were using at that stage was indeed incorrect. Due to the amount of certificates we did hold off on the revocation until we cleared it with them. The moment they confirmed we revoked.
2. The common name on the new certificates will look like this:
   E = [e-mail], 2.5.4.97 = LEIXG-5493008L577L3WTISK41, O = Lawtrust, C = ZA
3. The ambiguities were resolved with a later version of the BR that was issued, but it confused us on the common name that we could use.
4. We used two linter tools - PKIMetal and Digicert's S/Mime Linting tool to determine the correct format for the new cert templates that we can use going forward.
   The email OID was fixed as well in the new templates. Think it was a combination of CA software and OS that we are using.

Comment 11

[Marcile De Waal]

(In reply to Martijn Katerbarg from comment #9)

The change unfortunately was not finalised in the audit period. Hence the observation.

Please note, even if it had been finalised in the audit period, I would still expect an observation since other test certificates had already been issued incorrectly.

Based on the incident report, I understand you now issue the certificate as OV - Multipurpose (2.23.140.1.5.2.2), correct?

If so, based on the certificate details share in the attachment, it looks like there may be three other non-conformities:

• The certificate shown in https://bug1959721.bmoattachments.org/attachment.cgi?id=9478302 shows "rf822Name" has been added in the SubjectDN. The S/MIME BRs do not permit that for the Multipurpose profile.
• The "OU" field lists "Altron Class 3 RA". Is "Altron Class 3 RA" a registered organization name, or just a department within the organization?
• The certificate contains a Common Name which is neither the organization name, nor email address.

Since CT logs are generally not used for S/MIME certificates, I'm curious if you're willing to share the reissued certificate, or if you can confirm the above items have been resolved simultaniously when you updated the Policy OID.

It is interesting that the example certificate uses attribute with OID 0.9.2342.19200300.100.1.3 instead of the normal emailAddress attribute (1.2.840.113549.1.9.1), but I don't think it is wrong (just interesting).

If indeed these are issued under the Multipurpose profile/OID, then this would not be allowed according to the S/MIME BRs.

Hi Martin,

We changed the DN configuration to the following:
E = [e-mail]
2.5.4.97 = LEIXG-5493008L577L3WTISK41
O = Lawtrust
C = ZA
That was passed through the linting tools without any errors. We struggled to get the correct OID configuration, but going through various iterations we eventually managed to get the DN so that we could use our CA as is, and still indicate specific clients on the certificate, which was our original intention with adding the RA.

Comment 12

[incident-reporting]

This report has gone stale. Lawtrust, please provide (a) an update or (b) a Closure Report if you feel this is ready for closure.

Comment 13

[Marcile De Waal]

Report Closure Summary

• Incident description:

During the implementation of S/MIME certificate profiles in preparation for compliance with the CA/Browser Forum’s S/MIME Baseline Requirements (SBRs), the CA team applied a Policy Identifier (OID) that did not align with the structure of the Distinguished Name (DN) used in the certificates. The error stemmed from a misinterpretation of Section 7.1.6.3 of the SBRs, which links specific policy OIDs to certificate profile categories (e.g., Legacy, Multipurpose, Strict).

• Incident Root Cause(s):

We correctly selected an S/MIME certificate policy identifier (OID) intended for individual-validated certificates. However, we mistakenly included an Organizational Unit (OU) field in the Subject Distinguished Name (DN) that identified the Registration Authority (RA) involved in validating certificate contents. This OU value is not permitted under the S/MIME Baseline Requirements (SBRs) for individual-validated certificates.

This disallowed OU was due to our lack of institutionalized compliance knowledge. Our compliance efforts have relied on a small group, without documented procedures or formal onboarding processes to ensure proper interpretation and implementation of evolving requirements. Other contributing factors included: complexity and ambiguity in the S/MIME BRs, lack of familiarity with information in relevant working group mailing lists, and our certificate linting tool was not up-to-date with rules specific to the S/MIME Baseline Requirements.

• Remediation description:

Various remediation items were identified as per the full incident report. In Summary the following was done
Certificate profile was updated
Incorrect certificates were revoked
Certificate approval process was changed
Linter Tools were used to check the new profile settings
Subscriptions were updated on the browser forum's mailing lists to monitor discussions
Internal training session was completed to assist people setting up the profiles.

• Commitment summary:
  Processes were put in place to avoid future issues similar to what happened. No new certificate templates can be deployed without following the procedures.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 14

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2025-06-12.