SECOM: TSA certs issued from root
The bug was opened after CA/Browser Forum Baseline Requirements were amended to clarify that certificates with EKU id-kp-timeStamping must not be issued from roots. The reporter stated that SECOM had issued three timestamping (TSA) certificates in violation of this requirement and provided links to the certificates. SECOM responded that it investigated countermeasures and submitted an incident report describing how it became aware of the issue and why it believed the exception was not applied as expected after Ballot 189. SECOM stated it planned to change to a more secure new Root CA and to stop directly issuing TSA certificates from a root, and later reported that it had built a new timestamping intermediate CA and started issuing TSA certificates from that intermediate CA to one of its time stamping providers. When asked whether it would revoke still-valid timestamping certificates issued from the root, SECOM said it believed revoking TSA certificates was difficult due to long-term integrity needs for documents under Japan’s Digital Signature Act. The reporter agreed the explanation was acceptable and closed the bug, with the bug marked RESOLVED and resolution FIXED.
- A CA/Browser Forum ballot amendment clarified that id-kp-timeStamping certificates must not be issued from roots, and the reporter identified three SECOM-issued TSA certificates violating the requirement.
- SECOM began investigating countermeasures after receiving the Bugzilla notice.
- SECOM published an incident report and described planned changes to stop direct TSA issuance from a root.
- SECOM stated it was targeting end of September to build a new TSA intermediate CA and coordinate with Adobe.
- SECOM reported it had built a new timestamping intermediate CA and started issuing TSA certificates from that intermediate CA.
- The reporter closed the bug after accepting SECOM’s explanation regarding revocation.
- Fastly representative — Reported that three TSA certificates were issued in violation of the Baseline Requirements change and requested an incident report, linking to the required incident-report process.
- Secom representative — Acknowledged the notice, apologized for a delayed response, and said SECOM would investigate countermeasures.
- Secom representative — Provided an incident report describing how SECOM became aware, its investigation timeline, its explanation for the mistake, and steps planned to stop directly issuing TSA certs from a root.
- Fastly representative — Asked for a timeline to complete the change and whether SECOM would issue any more TSA certs from a root before the change.
- Secom representative — Said SECOM would build a new TSA intermediate CA, verify with customers, negotiate and embed with Adobe, and targeted end of September; it also said it did not have a plan to issue TSA certs from a root prior to the change.
- Secom representative — Reported that SECOM had built a new timestamping intermediate CA and started issuing TSA certificates from that intermediate CA to one of its time stamping provider(s).
- Fastly representative — Asked whether SECOM would revoke still-valid timestamping certificates that were issued from the root.
- Secom representative — Explained that SECOM believed revoking TSA certificates is difficult due to long-term integrity needs for documents under Japan’s Digital Signature Act and described the certificate usage timeline.
- Fastly representative — Stated the explanation for not revoking the misissued TSA certificates was acceptable and closed the bug.