1646711 - SecureTrust: Metadata-only field values in 2 certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Corey Bonnell]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Comment 1

[Corey Bonnell]

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.

SecureTrust was notified of an EV mis-issuance by a security researcher to our incident reporting address as disclosed in section 1.5.2 of our CPS on 2020-06-12 at 17:00 UTC. The single certificate specified in the Certificate Problem Report indicated that it contained an invalid serialNumber of “N/A”, which is contrary to the specification in EV Guidelines section 9.2.5.

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.

2020-01-06: Issuance of problematic certificate reported by researcher
2020-06-12 17:00 UTC: Receipt of Certificate Problem Report from researcher
2020-06-12 17:42 UTC: The Certificate Problem Report is circulated to the compliance team
2020-06-12 17:53 UTC: The compliance team confirms that the problematic certificate has been mis-issued and begins revocation procedure
2020-06-12 19:29 UTC: Revocation of problematic certificate
2020-06-12 19:30 UTC: Investigation of similar mis-issuances of certificates containing “metadata-only” subject fields by examining corpus of currently valid certificates begins
2020-06-12 19:50 UTC: Removal of EV issuance permissions for all EV Analysts except for the Analyst Supervisor
2020-06-12 20:25 UTC: Identification of one additional problematic OV certificate containing a “metadata-only” Subject field
2020-06-17 13:06 UTC: Revocation of additional problematic certificate

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.

In the near term, we will be implementing technical controls to automatically detect and reject certificate requests with metadata-only Subject fields. Additionally, we will be implementing an enhancement to our validation workbench to make it easier for Analysts to populate the canned text value for the serialNumber field when the Subject is a Government Entity and no Registration Number or Date of Incorporation is available. We anticipate that these technical controls and enhancements will be deployed as part of our next release on July 15th, 2020.

As an immediate mitigation, we have restricted EV issuance permissions for all EV Analysts except for the Analyst Supervisor such that that the Supervisor will be reviewing all EV certificate requests until technical controls can be implemented. Additionally, we have bolstered training to better convey to all Analysts the prohibition on metadata-only Subject fields.

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.

Metadata-only serialNumber

• 1 instance (EV)
• Issuance date of 2020-01-06
  Metadata-only stateOrProvince
• 1 instance (OV)
• Issuance date of 2019-09-27

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=2334437112 (problematic certificate reported by security researcher)
https://crt.sh/?id=1938775843 (additional certificate discovered by database scans)

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

There was confusion by the Analyst as to whether “N/A” is the correct way to specify that a Government Entity does not have a Registration Number, nor is the Date of Incorporation readily available. We have specified in training documentation that the canned text of “Government Entity – No registration number” is to be supplied for this situation, but that was not copied into the serialNumber field on the validation workbench. Similar confusion existed for the certificate with the metadata-only stateOrProvince field, where the Analyst was unsure on the best way to express that the stateOrProvince field should be blank and not be present in the final certificate.

The two problematic certificates in question did not appear in the sample of certificates reviewed at a regular cadence by our Internal Audit and Compliance teams.

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.

As an immediate mitigation, we have restricted EV issuance capabilities to solely the Analyst Supervisor so that the Supervisor must review all EV certificate requests prior to issuance. Additionally, we have bolstered training to better convey to all Analysts the prohibition on metadata-only Subject fields.

In the next software release scheduled for July 15th, we will be adding the following technical controls and enhancements to remediate this issue and provide better guidance to Analysts:

• We will be adding a checkbox to the EV validation workbench UI that Analysts can click to automatically populate the serialNumber field with the appropriate canned text (“Government Entity – No registration number”) when a Government Entity does not have a Registration Number and no Date of Incorporation is readily available. This will provide guidance to Analysts on the best way to encode the serialNumber in this scenario.
• We will be adding pre-issuance checks that will check all Subject fields in OV and EV certificate requests and abort the issuance process if a metadata-only field value is detected. This metadata-only field detection will be done with a set of regular expressions as opposed to a set blocklist of strings, thus providing more complete assurance that unanticipated metadata-only values are rejected appropriately.

More generally, we have been executing on our plan to continuously improve the Analyst experience of our validation workbench software as well as our technical controls which automatically detect and reject invalid Subject field values to reduce the onus on careful human review. We anticipate that our current and future efforts in this area will eliminate the potential for similar classes of errors to occur.

Comment 2

[Corey Bonnell]

We have deployed the software release yesterday as planned. As described above in the incident report, this release contains several improvements to the validation workbench which provide appropriate UI improvements and technical controls to remediate this issue:

• Checkbox for Analysts to clearly denote when a Government Entity has no available Registration Number. Checking this box will populate the serialNumber subject field with the appropriate canned text. To further reduce the possibility of confusion, this checkbox is only enabled when the selected Business Category is "Government Entity".
• Regular expression-based "metadata only" field value pre-issuance checks for all subject fields (except for CN) in OV and EV certificate requests.

Although we believe that these improvements increase the intuitiveness of the UI and provide technical controls to prevent a recurrence of this specific issue, we continue to execute on our plan to continuously improve the validation workbench to reduce the onus on careful human review so that similar classes of errors are detected prior to issuance.

Comment 3

[Corey Bonnell]

We believe this issue has been remediated last week by the implementation of technical controls and UI improvements to provide clarity to Analysts.

We have no further updates to provide at this time. Absent follow-up questions, we request that this issue be closed.

Comment 4

[Ben Wilson]

I agree that we can close this bug. I'll set a reminder to close this on or after 31-July-2020 unless we are notified of additional questions or issues.