1544722 - SECOM: certificate for which “L” and “ST” not set

Assignee

Description

•

6 years ago

We investigated and found the certificate for which “L” and “ST” not set.
We contacted the customer for revocation of the certificate.
https://crt.sh/?id=203300823&opt=cablint

Here is our incident report.

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 March 6, 2019.

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/02/03 This certificate was issued.
2019/03/06 The problem certificate was found in our investigation.
2019/03/15 The problem certificate was revoked.

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/03/15 The problem certificate was revoked.

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/02/03 This certificate was issued.
2019/03/15 The problem certificate was revoked.

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

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 “L” and “ST”.
No more certificate will be issued because the system has been configured at the maintenance work on November 2018.

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.

No more certificate will be issued because the system has been configured at the maintenance work on November 2018.
Let us supplement that the errors described at
https://crt.sh/?id=203300823&opt=cablint were fixed.
(“SAN” on November 2018 and “AIA” on August 2017)

Thank you for your consideration.

Best regards,
Hisashi Kamo

Wayne Thayer

Comment 1

•

6 years ago

(In reply to Hisashi Kamo from comment #0)

Thank you for this incident report.

We investigated and found the certificate for which “L” and “ST” not set.
We contacted the customer for revocation of the certificate.
https://crt.sh/?id=203300823&opt=cablint

Here is our incident report.

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 March 6, 2019.

Why did an investigation take place on 03/06?

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/02/03 This certificate was issued.
2019/03/06 The problem certificate was found in our investigation.
2019/03/15 The problem certificate was revoked.

Please explain why this certificate was not revoked in the time required by BR section 4.9.1.1 and how SECOM will prevent future revocation delays?

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/03/15 The problem certificate was revoked.

This response does not answer question #3.

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/02/03 This certificate was issued.
2019/03/15 The problem certificate was revoked.

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

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 “L” and “ST”.
No more certificate will be issued because the system has been configured at the maintenance work on November 2018.

Why was this certificate not detected in November 2018? Has SECOM scanned the database of active certificates to verify that no other certificates with the same or similar problems exist?

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.

No more certificate will be issued because the system has been configured at the maintenance work on November 2018.
Let us supplement that the errors described at
https://crt.sh/?id=203300823&opt=cablint were fixed.
(“SAN” on November 2018 and “AIA” on August 2017)

Thank you for your consideration.

Best regards,
Hisashi Kamo

Assignee: wthayer → h-kamo

Status: UNCONFIRMED → ASSIGNED

Ever confirmed: true

Flags: needinfo?(h-kamo)

Whiteboard: [ca-compliance]

Hisashi Kamo

Assignee

Comment 2

•

6 years ago

Wayne-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

Flags: needinfo?(h-kamo)

Hisashi Kamo

Assignee

Comment 3

•

6 years ago

Wayne-san,

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

Why did an investigation take place on 03/06?

It was caused by when we found that the certificate listed in https://misissued.com, which we view irregularly.
After examining the contents, we aware this problem on 2019/03/06.
This 2019/03/06 has no logical necessity.

Please explain why this certificate was not revoked in the time required by BR section 4.9.1.1 and how SECOM will >prevent future revocation delays?

Because this certificate is used for the system cooperation with the important infrastructure of the system for our customer, so we suspect the impact on the many end-users for revocation of the certificate.
Considering these impact, the revocation was done after getting agreement with customer, which took some time.
From now on, we will try to make arrangement promptly even though we care about the contents of the incident and impact on the customer.
Besides, now we are in the middle of the investigation for that the similar incidents may happening with other certificates. The investigation will be completed by the end of May.

This response does not answer question #3.

CA on this has finished issuing certificates.

Why was this certificate not detected in November 2018? Has SECOM scanned the database of active certificates to >verify that no other certificates with the same or similar problems exist?

Because we haven’t done checking with all certificates at the time the bug of the checking system updated in November, 2018.
From now on, we will review the checking system regularly to improve the accuracy, and Self-Audit, which is done in quarterly, will be done for not sampling with the target, but targeting with all certificates.

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

Wayne Thayer

Comment 4

•

6 years ago

Kamo-san,

Besides, now we are in the middle of the investigation for that the similar incidents may happening with other certificates. The investigation will be completed by the end of May.

Please update this bug with the results of your investigation.

Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 01-June 2019

Hisashi Kamo

Assignee

Comment 5

•

5 years ago

Wayne-san,

Please let us update the results of our investigation.

We found 7 certificates as below.

We started to make an arrangement with our customer for the prompt revocation.
Because these certificates are used for the system cooperation with the important infrastructure of the system for the customer, so we suspect the impact on the many end-users for revocation of these certificates.
We are now targeting to revoke all of these certificates by the end of June.
Upon making any progress, we will update it.

Thank you for your consideration.

Best regards,
Hisashi Kamo

CN=endpoint.europe.tel.com,O=Tokyo Electron,C=JP

CN=telwebmail.tel.com,O=Tokyo Electron,C=JP

CN=lyncweb.asia.tel.com,OU=Information Systems Dept, O=Tokyo Electron Limited,C=JP

CN=exhyep.telgrp.com,O=Tokyo Electron,C=JP

CN=lyncdiscover.telgrp.com,O=Tokyo Electron,C=JP

CN=lynchyeg.telgrp.com,O=Tokyo Electron,C=JP

CN=lyncrp.telgrp.com,O=Tokyo Electron,C=JP

Ryan Sleevi

Comment 6

•

5 years ago

Because these certificates are used for the system cooperation with the important infrastructure of the system for the customer, so we suspect the impact on the many end-users for revocation of these certificates.

We are now targeting to revoke all of these certificates by the end of June.

This is not an acceptable timeline based on the information provided. While CAs are ultimately responsible for the decision about whether or not to revoke, if SECOM should make a decision to not revoke until the end of June, it will be substantially and significantly worse for them with respect to ongoing public trust.

In the past year, the level of detail and expectation regarding a CAs' decision to intentionally and knowingly violate the BRs, by not revoking, has increased. A level of "we suspect the impact" is simply not an acceptable level of detail going forward. Please review the discussions with DigiCert around underscores to know what the minimum is.

Comment #1 asked SECOM about the steps taken to prevent further delays. This was to highlight the importance of prompt revocation. The steps taken in Comment #3 were clearly ineffective. While I realize SECOM acknowledge the possibility of other incidents in that message, I cannot stress enough the importance of ensuring complete and total transparency and prompt revocation.

Please carefully review Bug 1517617, Bug 1519572, Bug 1516599, Bug 1526154, Bug 1516561, Bug 1516453, Bug 1515788. Please carefully review https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation and specifically "When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis." and "Any decision to not comply with the timeline specified in the Baseline Requirements must also be accompanied by a clear timeline describing if and when the problematic certificates will be revoked or expire naturally, and supported by the rationale to delay revocation.". Please carefully review the m.d.s.p. discussion then, and over the past six months, to understand the expectation.

We cannot force you to revoke - that is a decision the CA takes. However, if a CA makes a decision to delay revocation, it unquestionably owes the community a response that is as or more detailed than any previous response, that makes it clear why such a decision was made, the factors contributing, and the steps the CA is taking to meaningfully not have this happen again. As it stands, this response does not rise to that level at all, which is why it runs the risk of being significantly negative for SECOM if SECOM should delay revocation any further. It has been two months. further delays are unconscionable and irresponsible.

Flags: needinfo?(h-kamo)

Hisashi Kamo

Assignee

Comment 7

•

5 years ago

Ryan-san,

Thank you for your comments.
We apologize for delay.

We are taking care of this incident very seriously.
3 certificates out of 7 have been revoked, and continuously doing our best effort to revoke the remaining 4 certificates early next week.
Please let us report details next week.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Hisashi Kamo

Assignee

Comment 8

•

5 years ago

Ryan-san,

Please let us update that the remaining 4 certificates have been revoked.
There was a certificate that could take a long time to revoke, but as a result of serious discussions with the customer continuously and then all the 7 certificates we reported have been revoked today.

Best regards,
Hisashi Kamo

Ryan Sleevi

Comment 9

•

5 years ago

Wayne: Any follow-ups? I think a normal follow-up question is how delays in revocation will be prevented in the future, but I'm deferring to you.

Flags: needinfo?(wthayer)

Ryan Sleevi

Updated

•

5 years ago

Whiteboard: [ca-compliance] - Next Update - 01-June 2019 → [ca-compliance]

Wayne Thayer

Comment 10

•

5 years ago

(In reply to Ryan Sleevi from comment #9)

Wayne: Any follow-ups? I think a normal follow-up question is how delays in revocation will be prevented in the future, but I'm deferring to you.

Yes. My understanding is that 4 certificates were not revoked within the time required by the BRs.

Kamo-san: please explain what SECOM is doing to ensure that BR revocation requirements are met in the future?

Flags: needinfo?(wthayer) → needinfo?(h-kamo)

Hisashi Kamo

Assignee

Comment 11

•

5 years ago

Wayne-san,

Please let us comment as below.

Regarding with our current rules and procedures for revocation, we have been abided by what is described in the validation manual, which is in compliance with BR.
When we confirm a certificate which may be conflict, or potential conflict with BR, we will promptly report it to Bugzilla, and also implement the following measures so that the revocation will be completed by the revocation date in compliance with the revocation reason of Article BR 4.9.1.

Review and recosideration of the revocation flow according to the revocation reason of Article BR 4.9.1
Implementing prompt notification and explanation to the customers concerned
(Necessity of revocation, the impact on compliance if the revocation is delayed)
Updating the manual to ensure that the revocation process is done without any delay

Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Wayne Thayer

Comment 12

•

5 years ago

Kamo-san:

Has the validation manual been updated with these changes?

It is not clear to me how these changes would have prevented the delays in revocation as you have described in this incident. Can you explain?

Flags: needinfo?(h-kamo)

Hisashi Kamo

Assignee

Comment 13

•

5 years ago

Wayne-san,

Please let us answer as below.

We are planning to implement the update of the manual from now on.

The major reason for the delay of revocation is that we took more time for coordinating with the customers than we initially expected.

Making use of this experience, we will review the customer coordination work flow thoroughly and try to optimize operations in better way. In addition to that, we will create a format as explanatory materials for customers, so that we will set up the system in which we can explain any situation to customers promptly.
By optimizing customer coordination as stated above, we will make our best effort to respond faster than ever before.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Wayne Thayer

Comment 14

•

5 years ago

(In reply to Hisashi Kamo from comment #13)

Wayne-san,

Please let us answer as below.

We are planning to implement the update of the manual from now on.

This response is not clear to me. Comment #11 described a change that was to be made to the validation manual. Has this change been completed? If not, please update this bug when the change has been completed.

Flags: needinfo?(h-kamo)

Hisashi Kamo

Assignee

Comment 15

•

5 years ago

Wayne-san,

Please let us inform you that the manual has been updated today.
Thank you for your consideration.

Best regards,
Hisashi Kamo

Flags: needinfo?(h-kamo)

Wayne Thayer

Comment 16

•

5 years ago

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

Status: ASSIGNED → RESOLVED

Closed: 5 years ago

Resolution: --- → FIXED

Nobody; OK to take it and work on it

Updated

•

2 years ago

Product: NSS → CA Program

David Lawrence [:dkl]

Updated

•

2 years ago

Whiteboard: [ca-compliance] → [ca-compliance] [ov-misissuance]

Bugzilla

SECOM: certificate for which “L” and “ST” not set

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

People

(Reporter: h-kamo, Assigned: h-kamo)

References

Details

(Whiteboard: [ca-compliance] [ov-misissuance])

Crash Data

Security

(public)

User Story

Description

Comment 1

Comment 2

Comment 3

Comment 4

Comment 5

Comment 6

Comment 7

Comment 8

Comment 9

Updated

Comment 10

Comment 11

Comment 12

Comment 13

Comment 14

Comment 15

Comment 16

Updated

Updated