1914020 - SwissSign: S/MIME NCP non ASCII symbols in email and SAN field wrong coding

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Sandy Balzer]

Attachment: ncp_affected certs.txt

Preliminary Incident Report

Summary

This is a preliminary incident report and we will post updates.
During our annual Audit our audit body checked the S/MIME NCP certificates issued since last audit period and notified us that for some certificates the SAN field is not displayed correctly in different certificate viewer tools.
Our following pre-investigation showed that there are mis coded non ascii characters in the SAN (SubjectAlternativeName) field and this led to the error.
This is against the requirement of S/MIME BR 7.1.2.4 that requires all other fields to conform to RFC 5280. RFC 5280 4.2.1.6 requires that e-mail addresses in SAN must be IA5STRING.
We have started our mis-issuance process to revoke the affected certificates.

Impact

194 SMIME NCP certificates are affected.
First affected certificate issued: CET 2023-12-02 00:02
Last affected certificate issued: UTC 2024-02-20 02:01
Our pre-investigation shows that since 23rd of February the then activated linters prevent additional mis-issuance.
Therefore, we have not stopped issuance of S/MIME certificates.

Timeline

All times are UTC.

2023-09-01
On this date the S/MIME BR chapter 7.1.2.4 was released, that requires all other fields to conform to RFC 5280. RFC 5280 4.2.1.6 requires that e-mail addresses in SAN must be IA5STRING.

2023-12-02, 01:02 First mis-issuance

2024-02-20, 02:01 Last mis-issuance

2024-02-23
Activation of S/MIME Linter

2024-08-19, 13:30
Investigation of certificates reported by audit body

2024-08-20 18:30
Posting of this Bugzilla

Root Cause Analysis

This is a preliminary incident report and we will post updates based on the ongoing RCA

Lessons Learned

What went well

• Implementation of S/MIME linter preventing further mis-issuances

What didn't go well

• Our test-cases did not include checking for non ascii characters in the local-part of the e-mail address

Where we got lucky

• Only one customer has used non-ascii characters for the same e-mail address (based on the current information)

Action Items

Action Item	Kind	Due Date
revocation of affected certificates	mitigate	24.8.2024 at 12:30 UTC
include test-coverage to include testing for non ascii characters	Prevent	to be defined

Appendix

Details of affected certificates

see attached list

Comment 1

[Stephan Verbücheln]

In your list, many certificates are listed twice and most SHA-256 hashes are 20 instead of 32 bytes long. Please provide a correct list.

Comment 2

[Sandy Balzer]

(In reply to Stephan Verbücheln from comment #1)

In your list, many certificates are listed twice and most SHA-256 hashes are 20 instead of 32 bytes long. Please provide a correct list.

Thank you for your feedback, please find attached the new list (NCP_affected_2024-08-21.txt) of affected certificates we have generated using our internal systems.
98 Certificates remain affected.

We will update this Bugzilla with our RCA asap.

Comment 3

[Sandy Balzer]

Attachment: updated certicate list

see comment 2
https://bugzilla.mozilla.org/show_bug.cgi?id=1914020#c2

Comment 4

[Sandy Balzer]

Summary

Update: We revoked all affected certificates before 24.8.2024 12:30 UTC.

Impact

Internal investigation confirmed 98 SMIME NCP certificates were affected.

Timeline

All times are UTC.

2023-09-01
On this date the S/MIME BR chapter 7.1.2.4 was released, that requires all other fields to conform to RFC 5280. RFC 5280 4.2.1.6 requires that e-mail addresses in SAN must be IA5STRING.

2023-12-02, 01:02
First mis-issuance

2024-02-20, 02:01
Last mis-issuance

2024-02-23
Activation of S/MIME Linter

2024-08-19, 13:30
Investigation of certificates reported by audit body

2024-08-20, 18:30
Posting of this Bugzilla

2024-08-23, 08:51:00
Revocation of affected certificates finished

2024-08-23, 16:30
Posting of update

Root Cause Analysis

Our CA software did not check for miscoded characters in the S/MIME certificates SAN field and so this miscoding passed into the S/MIME certificate in the timeframe before our S/MIME Linters were enabled.

Action Items

Action Item	Kind	Due Date
revocation of affected certificates	Done	2024-08-23 at 08:51:00 UTC
include test-coverage to include testing for non ascii characters	Prevent	planned for 2024-08-30

Comment 5

[Sandy Balzer]

Update 2024-08-30

Summary

Update: we are working on the inclusion of the test-coverage for non ascii characters and plan to finish by end of next week.

Action Items

Action Item	Kind	Due Date
revocation of affected certificates	Done	2024-08-23 at 08:51:00 UTC
include test-coverage for non ascii characters	Prevent	planned for 2024-09-06

Comment 6

[Stephan Verbücheln]

Can you elaborate which non-ASCII characters were problematic? Can you give examples for affected e-mail addresses?
Please note that non-ASCII characters are legitimate in e-mail addresses (see RFC 6532 etc.).

Comment 7

[Sandy Balzer]

(In reply to Stephan Verbücheln from comment #6)

Can you elaborate which non-ASCII characters were problematic? Can you give examples for affected e-mail addresses?
Please note that non-ASCII characters are legitimate in e-mail addresses (see RFC 6532 etc.).

Dear Stephan,

There were German Umlaut (ö ä ü) characters in the SAN. While RFC 6532 allows for internationalization of email addresses, the S/MIME BR 7.1.2.4 requires the SAN to conform to RFC 5280. RFC 5280 4.2.1.6 requires that e-mail addresses in SAN must be IA5STRING, which does not allow these non ASCII symbols.

Due to data protection laws we cannot give the exact wrong entries, but they looked something like:

hö[e-mail]
prü[e-mail]
bä[e-mail]

Does this answer your question?

Kind regards

Comment 8

[Stephan Verbücheln]

(In reply to Sandy Balzer from comment #7)
Thank you. This answered all my questions.

Comment 9

[Stephan Verbücheln]

I have looked into it again and was confused again. Then I noticed that the BR just changed on August 29.

The previous BRs only mentioned RFC 6532 when defining “Mailbox Address”. Now the BR explicitly allows “id-on-SmtpUTF8Mailbox, encoded in accordance with RFC 9598” in section 7.1.4.2.1 “Subject alternative name extension”.

So you should probably re-consider your linter scripts.

Comment 10

[Sandy Balzer]

(In reply to Stephan Verbücheln from comment #9)

I have looked into it again and was confused again. Then I noticed that the BR just changed on August 29.

The previous BRs only mentioned RFC 6532 when defining “Mailbox Address”. Now the BR explicitly allows “id-on-SmtpUTF8Mailbox, encoded in accordance with RFC 9598” in section 7.1.4.2.1 “Subject alternative name extension”.

So you should probably re-consider your linter scripts.

Dear Stephan,

You are correct, the most recent S/MIME BR v1.0.6 does allow id-on-SmtpUTF8Mailbox in the SAN.

However, our certificates were issued before this was allowed and our encoding uses the coding described in RFC 5280 as "rfc822Name [1] IA5String". Because of this encoding, these certificates would also be mis-issued under the most recent BR.

Our linter does indeed catch the wrong coding. That's why after 2024-02-23 there were no more mis-issuances.

Does that align with your statement?

Kind regards

Comment 11

[Sandy Balzer]

Update

Summary

Update: we have finished the inclusion of the test-coverage for non-ascii characters.

Action Items

Action Item	Kind	Due Date
revocation of affected certificates	Mitigate	Done 2024-08-23 at 08:51:00 UTC
include test-coverage for non ascii characters	Prevent	Done 2024-09-06

Comment 12

[Ben Wilson]

I will schedule this matter for closure on Wed. 11-Sept-2024.