1629020 - Taiwan-CA: Misissued certificate: Invalid organizationUnitName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Hao-Chun Li]

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

Steps to reproduce:

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

Our post issuance linter detected the problem notified our operator.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

(All times below are in UTC+8)
2020/4/10 16:35 The certificate is issued
2020/4/10 16:58 The problem is detected and operator is notified
2020/4/10 17:11 Our compliance team is notified and start the investigation.
2020/4/10 17:26 The certificate is revoked
2020/4/10 19:03 We have completed the investigation and determined the scope and cause of the problem

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

We are adding additional check for certificate subject and will stop issuing certificates with the problem.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

number of certs: 1
first and last certificate issued: 16:35:53

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

https://crt.sh/?id=2687880505

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

We have two independent implementation of linting to check certificates pre and post issuance.
This problem is not covered by our pre issuance linter.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

The additional check for certificate subject will be deployed by 2020/4/17.
We will review the rules of our certificate linter to ensure the problem is covered.
The update to pre issuance linter (which is built direct inside core CA system) will be deployed in 2020 Q3.

Comment 1

[Ryan Sleevi]

(In reply to Hao-Chun Li from comment #0)

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

We have two independent implementation of linting to check certificates pre and post issuance.
This problem is not covered by our pre issuance linter.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

The additional check for certificate subject will be deployed by 2020/4/17.
We will review the rules of our certificate linter to ensure the problem is covered.
The update to pre issuance linter (which is built direct inside core CA system) will be deployed in 2020 Q3.

This doesn't actually discuss what the underlying problem is, and thus doesn't really look at identifying the root cause or how these remediations will address it.

That is, while it's useful to say "A lint was violated", it's important to describe what the linter checks, how the error came to be, and what's being done about it. Deploying more linters doesn't fix or address the underlying root cause.

The specific issue here with the organizationUnitName is that it's encoded as 0C 05 C2 8D 49 43 4C. It is "UTF-8 string" (0C), 5 bytes long (05), with the encoded UTF-8 values of C2 8D 49 43 4C. This triggered the lint_subject_dn_not_printable_characters lint in ZLint.

The specific sequence of bytes that is problematic is C2 8D, which is U+008D, "Reverse line feed" in the Latin-1 supplement and the C1 control set.

With that explanation of the problem, I think the most important question is understanding the entire process that lead this sequence of bytes to be included in the subject. From there, it's useful to understand what changes are being made on 2020-04-17.

Comment 2

[Hao-Chun Li]

A more detailed description of the problem is as follows:
Customers submit their CSR which contains the desired subject attributes. Our system checks the CSR and fills the attributes into application data. The application data is verified manually for organization validation and can be corrected if necessary. When approved, the data then goes into the issuance process where it is validated by the pre-issuance linter for any exceptions that might not be covered in previous steps.

The problem that happened is a CSR submitted by our customer contains a control character U+008D which is invalid for subject attributes. The CSR checks did not check for control characters. Because the character is not printable, our operator did not recognize it either. And the linter did not include the rule to block control characters in subject attributes. Therefore, the invalid organizationUnitName in the problem went undetected before the issuance.

We are going to add checks for control characters in subject attributes to the CSR checks, which will be deployed on 2020-04-17.
We will review the linter implementation and ensure it covers the problem and other ones we may have been missing.

Comment 3

[Ryan Sleevi]

Thanks for the added details!

When you talk about having the CSR filling the data into application data, do you mean you copy the decoded value out, and then later re-encode it, or do you copy the encoded value as it is in the CSR?

For example, if there was a CSR that requested BMPString, would the generated certificate be encoded using BMPString (same as the CSR), or would it be encoded using UTF8String (as per RFC 5280)? Just trying to build a better understanding here about the flow of data through the system.

Comment 4

[Hao-Chun Li]

The value is decoded into a string. The string value is then used throughout the process until certificate generation, where it will be encoded using either PrintableString or UTF8String.

In the case of your example, it will be encoded using UTF8String (assuming it does not fit PrintableString)

Comment 5

[Hao-Chun Li]

The CSR validation has been deployed. CSR containing non-printable control characters will be rejected now.

Comment 6

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 7

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.