1544712 - SECOM: certificate for which “OU=-”

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Comment 1

[Hisashi Kamo]

We investigated and found the certificate for which “OU=-”.
We contacted the customer for revocation of the certificate.
https://crt.sh/?id=21316536&opt=cablint

Here is our incident report.

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.

The problem certificate was found in our investigation and contacted the customer to revoke the certificate on February 6, 2019.

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.

2016/06/01 This certificate was issued.
2019/02/06 The problem certificate was found in our investigation.
2019/02/13 The problem certificate was revoked.

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.

2019/2/13 The problem certificate was revoked.

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.

2016/06/01 This certificate was issued.
2019/02/13 The problem certificate was revoked.

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=21316536&opt=cablint

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

Because of a bug in the check system of the input data for “OU”.
Plans are underway to upgrade the system as a countermeasure.

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.

Plans are underway to upgrade the system as a countermeasure.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 2

[Ryan Sleevi]

(In reply to Hisashi Kamo from comment #1)

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.

The problem certificate was found in our investigation and contacted the customer to revoke the certificate on February 6, 2019.

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.

2016/06/01 This certificate was issued.
2019/02/06 The problem certificate was found in our investigation.
2019/02/13 The problem certificate was revoked.

This appears to be outside the time permitted by the Baseline Requirements. Is there an explanation about why the requirements of Section 4.9.1.1 were ignored?

There's also notable absences from the timeline and description - for example, what caused you to examine the certificate issued on 2016/06/01? Was it a routine linting, an audit review, etc? These are details that help the public understand how SECOM approaches certificate issues. It also omits the contact to the customer (apparently on 2019/02/06), whether the customer responded/acknowledged (if so, when?), whether SECOM had to contact the customer again, etc.

The more details you provide, the better our understanding can be, and thus reduces the likelihood of assuming the worst about the CA.

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

Because of a bug in the check system of the input data for “OU”.
Plans are underway to upgrade the system as a countermeasure.

This does not explain what the bug was, when it was introduced, how it was introduced, whether other certificates were examined, whether they were impacted.

The goal of these incident reports is to help understand both SECOM's existing controls that may have mitigated this, as well as possible best practices that all CAs should apply. No CA can look at this report and understand from the description how to avoid this issue, and thus it's not a good incident report.

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.

Plans are underway to upgrade the system as a countermeasure.

Similar to the description of the bug, a description about the specific steps being taken. What will upgrading the system entail? What new checks will be introduced? How will they be tested? Based on the description of the bug (which needs to be provided), how can the community understand that these issues will be addressed. We want to ensure the issue is comprehensively measured.

Similarly, what are the concrete dates for proposed next steps? How will we measure progress? When can we expect updates?

In short, we need more information. We need more information about what went wrong, we need more information about how SECOM handled it once they discovered something went wrong, and we need to understand what steps are being taken proactively to prevent future things going wrong. These incident reports provide an opportunity for the CA to comprehensively answer any concerns and to demonstrate leadership in the CA space - and the more information provided, the better it is for the CA, both now and in the future.

Comment 3

[Hisashi Kamo]

Ryan-san,

Thank you for your comments.
We are now preparing the answers and let us have some time to post it on next week.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 4

[Hisashi Kamo]

Ryan-san,

Thank you for your comments.
Please let us answer as below.

This report describes that the certificate which used to be not against BR(Version 1.6.4), but is considered to be against the current BR(Version1.6.5). It also includes the information why the decision has been changed that way.

This appears to be outside the time permitted by the Baseline Requirements. Is there an explanation about why the >requirements of Section 4.9.1.1 were ignored?

Since we took some time to conclude that the problem was caused by that OU had only metadata, it took time for revocation. At that time, BR Version 1.6.4 noted that only metadata was not permitted in 7.1.4.2.2.j.[Other Subject Attributes],so that we considered it was a different definition from i[organizationalUnitName]
(Then after we pointed out that fact, BR1.6.5 was updated.)

There's also notable absences from the timeline and description - for example, what caused you to examine the >certificate issued on 2016/06/01? Was it a routine linting, an audit review, etc? These are details that help the public >understand how SECOM approaches certificate issues. It also omits the contact to the customer (apparently on >2019/02/06), whether the customer responded/acknowledged (if so, when?), whether SECOM had to contact the customer >again, etc.

The more details you provide, the better our understanding can be, and thus reduces the likelihood of assuming the >worst about the CA.

The direct cause was when we found out that the certificate was listed in https://misissued.com, which we view irregularly.
2019/02/06 When we did irregular inspection and the certificate was detected.
2019/02/07 After the internal discussion, we decided that we should do some action for this certificate.
2019/02/07 We explained the customer about the problem of the certificate and gathered some information on the impact of this revocation, which communication took some time.
2019/02/13 The customer agreed with the revocation, and after reissuing the certificate, they revoked the certificate.
2019/02/15 According to BR Version 1.6.4, it is described in 7.1.4.2.2.j.[Other Subject Attributes] that only metadata is not allowed, actually we were not sure whether OU=- could be a problem or not, so we sent the question to [e-mail]. This mail was sent by [e-mail] because of our company out bound email regulations.
After that, the discussion on [e-mail] started with Ballot SC16.
2019/04/16 BR Version 1.6.5 explicitly defines OU=- is problematic. At the same time, we posted in Bugzilla.

This does not explain what the bug was, when it was introduced, how it was introduced, whether other certificates were >examined, whether they were impacted.

The goal of these incident reports is to help understand both SECOM's existing controls that may have mitigated this, >as well as possible best practices that all CAs should apply. No CA can look at this report and understand from the >description how to avoid this issue, and thus it's not a good incident report.

At the time of 2019/02/06, when the value of OU had only metadata, the certificate application with [-][.][(only space)]was able to be accepted. We had done investigation on other certificates and found there was one certificate which was corresponded to the problem after all.

Similar to the description of the bug, a description about the specific steps being taken. What will upgrading the >system entail? What new checks will be introduced? How will they be tested? Based on the description of the bug (which >needs to be provided), how can the community understand that these issues will be addressed. We want to ensure the >issue is comprehensively measured.

Similarly, what are the concrete dates for proposed next steps? How will we measure progress? When can we expect >updates?

About the description of the bug, the certificate application with only metadata letters on the DN contents was able to be accepted. For improving the measure, when there is a certificate application with only metadata letters in DN, it should not be acceptedin DN.
Now we have been working on the above improvement measure, and we will plan to update it by the end of June.

We really appreciated your comments.
Continuously please give us comments if you have further questions.

Last of all, we’d like to inform you that most of Japan business entities including us will have special long National holiday from April 27th to May 6th because of the new emperor’s enthronement, which you may already knew from the news, and this happens only one time ever in our history.
For that reason, we really appreciate your understanding that we can start contacting with you after May 7th.

Best regards,
Hisashi Kamo

Comment 5

[Ryan Sleevi]

There has been no update following May 7 regarding a concrete timeline of proposed steps.

Comment 6

[Hisashi Kamo]

Ryan-san,

We apologize very much for delay and overlooked the update.

Now we have been working on the above improvement measure, and we will plan to update it by the end of June

The measure was completed on June 23.
Please let us make sure for making the report timely from now on.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 7

[Wayne Thayer]

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