1727963 - DigiCert: Truncation of Registration Number

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Jeremy Rowley]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 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.

During a regular audit of our certs, the audit team found a registration number that didn’t fit an expected pattern. We determined that the cert had a truncated registration number. After recognizing an improper truncation within the Registration Number field, our internal Audit Team conducted an internal investigation where we found 2 certificates with this condition.

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.

08/23/2021: The long registration number pattern was added and disclosed as source on our GitHub repository.

08/23/2021: A certificate was verified using the registration number. The registration number exceed 64 characters. The certificate issued but with a registration number truncated to 64 characters.

08/23/2021: Staff noticed the truncated registration number and escalated it for further review.

08/23/2021: Compliance confirmed the issue, and DigiCert kicked off an investigation into what process truncating the registration number.

08/24/2021: Compliance team ran a comprehensive system sweep for certificates with truncated registration number and found 2 certificates with this condition.

08/24/2021: Engineering team identified the issue as a system limitation: when the registration number in the certificate issuance request exceeds the maximum length allowed, the system will issue a certificate with a truncate value instead of rejecting the request. Other fields rejected the request.

08/27/2021: Engineering applied a path to have the CA reject all signing requests if the passed information is greater than the length allowed by RFC5280.

We scheduled the revocation for five days from when we confirmed the issue.

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.

On August 27, 2021, we applied a patch to reject all publicly-trusted signing requests if information submitted to the CA exceeds a limit set in 5280, aligning registration number to how the rest of the fields work.

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.

There are two certs, one issued on 07/28/2020 and one issued on 08/23/2021

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=3152952273
https://crt.sh/?id=5092003257

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

When implementing the requirements of Appendix G in Oct 2017, we ended up truncating the information instead of rejecting the signing request. We’d implemented a check on the validation system before that and found that subject information (like address and org name info) was properly rejected if the approved information exceeded the allowed length. Registration information was not included in the change that rejected incorrect subject information. The CA system, aware of the limitations on length imposed by 5280, truncated information that was sent to it but not rejected. We have rectified this by changing the CA to reject all information too long for signing instead for truncating.

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.

On August, 27, 2021, we implemented a change on the CA to reject all signing requests with a field greater than the allowed length instead of having the CA truncate the information. We’ve looked at the other subject fields to make sure they are consistently performing the operation.

Comment 1

[Ben Wilson]

Hi Jeremy,
It looks like the registration numbers required a long narrative explanation of their source (they attempted to explain their source). I think the field was intended to just contain some type of alphanumeric identifier. Are there plans to introduce anything to help all CAs better handle these situations? Also, are there any other remediation tasks that DigiCert still needs to perform (e.g. identifying similar situations where something like this might occur in other fields, providing guidance on handling long text fields, etc.)? If not, can this bug be closed?
Thanks,
Ben

Comment 2

[Jeremy Rowley]

Hey Ben,

As part of remediating this bug, we reviewed the RA system as well as the CA system. In the RA system, O fields longer than 64 characters are rejected and can't be submitted to the CA. If a name is longer than the allowed length, the validation agent must shorten the name as allowed in the BRs before submitting the cert for signing. During our review, we found three instances where the truncation by the agent was improper:
091b6d7aa803fa62b3f149b1b3912296
0329849002fc6d122f3ba791e8263794
025c46718edc22ab80b5b6e4f4d7d19d

These are being revoked in accordance with the 5 day rule.

For remediation, we added a warning to the RA that if any information is longer than the allowed length to carefully consider how to do the truncation. We also added a warning system to alert staff if the field contains missing parentheses, braces, etc. This is only a warning as we identified a few organization names that had a single parenthetical in their legal name.

As for helping other CAs, we recommend the same sanity check on the CA. Warn if there are weird combinations, like an open parenthesis without a closing one or if the character count is within 1 of the maximum length. We talked about proposing this as a zlint, but we believe getting to zero warnings in zlint is a good goal. Adding this kind of warning in zlint would create too many false positives.

Any other information you want to know? If not, I'm ready to close this bug.

Comment 3

[Ben Wilson]

I'll schedule this bug for closure on next Wed. 8-Sept-2021.

Comment 4

[Ryan Sleevi]

Jeremy: I'm just wanting to under a bit more here.

First, it seems like those disclosed in Comment #2 are somewhat separate - the serialNumber vs organizationName seems like they have their own distinct process expectations, and thus distinct controls, so even if both were truncated, it seems like separate failures.

With respect to the values entered in - which is what Ben was asking about in Comment #1 - it does seem like, beyond these values being truncated, they were also wrong. That is, is the suggestion here that neither the "Housing Development Finance Corporation Bank of Sri Lanka" nor the National CSIRT of Cyprus have readily verifiable dates of creation?

In the case of the latter, for example, we see it's asserting Decision No. 81/477, which was dated 22/10/16 - presumably, that's 2016-10-22. Thus, the to Ben's point, the disclosure of the source seems contrary to the expectations of 9.2.5 of the EVGs.

This has obvious implications for thinking about mitigating strategies. In fact, I have no confidence in the mitigation outlined for serialNumber, because it doesn't seem to reflect the expectation of what the serialNumber contains. If, for example, you recognized that for Government Entity business categories, the serialNumber may need to contain a formatted date, Government Entity, or registration number conforming to one of the relevant syntaxes, that feels like a more meaningful improvement.

Similarly, it's concerning how these, as EV certificates, made it through two-party control and still weren't flagged.

I'd like to ask that you more carefully analyze the facts here, and see if there are further opportunities for improvement, taking into context both the semantic meaning of the field and how other fields can be leveraged to better inform controls - and alert for additional review.

Comment 5

[Jeremy Rowley]

First, it seems like those disclosed in Comment #2 are somewhat separate - the serialNumber vs organizationName seems like they have their own distinct process expectations, and thus distinct controls, so even if both were truncated, it seems like separate failures.

Yeah - they are different root causes. I considered filing separate bugs on this but figured the two were related enough and had the same timeline/investigation that itI could just use this one since they were the same investigation. I can file a separate bug if you want. The bugs occurred on two separate systems - the CA, which truncated information, and the RA, which rejected information over a certain size. To get around the RA rejection, the validation staff usually shortens the information using standard abbreviations (eg changing corporation to corp). In these three cases, we the validation staff dropped too much information.

With respect to the values entered in - which is what Ben was asking about in Comment #1 - it does seem like, beyond these values being truncated, they were also wrong. That is, is the suggestion here that neither the "Housing Development Finance Corporation Bank of Sri Lanka" nor the National CSIRT of Cyprus have readily verifiable dates of creation?

They have a date of creation, but they also have a legislative reference, which is the registration number under 11.2.1. We bias towards the registration number, even though government entity registration numbers and date of creation seem to have equal footing.

In the case of the latter, for example, we see it's asserting Decision No. 81/477, which was dated 22/10/16 - presumably, that's 2016-10-22. Thus, the to Ben's point, the disclosure of the source seems contrary to the expectations of 9.2.5 of the EVGs.

For the registration number, we follow 11.2.1:
Registration Number: The CA MUST attempt to obtain the Applicant’s date of
incorporation, registration, or formation, or the identifier for the legislative
act that created the Government Entity. In circumstances where this
information is not available, the CA MUST enter appropriate language to
indicate that the Subject is a Government Entity

We try to get the identifier of the legislative act first and then the date of creation. Here, the validation staff entered the legislative act creating the government entity. The official name of the act was too long.

This has obvious implications for thinking about mitigating strategies. In fact, I have no confidence in the mitigation outlined for serialNumber, because it doesn't seem to reflect the expectation of what the serialNumber contains. If, for example, you recognized that for Government Entity business categories, the serialNumber may need to contain a formatted date, Government Entity, or registration number conforming to one of the relevant syntaxes, that feels like a more meaningful improvement.

We use the legislative act as the registration number per 11.2.1 (which is the registration number for these government entities). If there is no registration number, we use the date of creation. We do this for two reasons: 1) it gives more information about the entity named in the certificate and 2) the order matches the requirements for private organizations under 9.2.5. Changing the order to date of creation from registration number will likely result in more errors as the validation staff would need to follow an opposite approach for private vs. government.

Similarly, it's concerning how these, as EV certificates, made it through two-party control and still weren't flagged.

They weren't flagged because the RA system allowed registration number to be longer than 64 characters. The registration number was correct based on the validation documentation, but was truncated afterwards. For the org field info, the information was truncated by the validation there two different issues. For 025c46718edc22ab80b5b6e4f4d7d19d, a QIIS had the information incorrectly listed and the org name was updated, matching the QIIS. The other two, the validation staff dropped the end parenthesis, thinking it was punctuation, like the period at the end of inc or in LLC. This was an incorrect assumption and we've sent out an advisory that parentheticals are not the same as periods in corporate type identifiers. They passed secondary review because both the primary and secondary approver believed they could drop this character.

We've looked at what we can do with the fields to try and provide additional sanity checks. We already tie the government entity check to the 'government identifier' and we check formatting on date of creation, etc. For the org field, we already compare the full name to the abbreviated name.

Comment 6

[Jeremy Rowley]

I have no additional updates.

Comment 7

[Ben Wilson]

I'll close this on Friday, 17-Sept-2021, unless there are additional questions that need answering.