1452671 - SECOM: TSA Certs Issued from Root

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

CA/Browser Forum ballot 189 amended section 6.1.7 of the BRs to clarify that certificates with EKU id-kp-timeStamping must not be issued from roots. The following three certificates have been issued in violation of this requirement:

https://crt.sh/?id=378999013
https://crt.sh/?id=378999316
https://crt.sh/?id=378999186

Please provide an incident report as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

The incident report should be published in this bug and to the mozilla.dev.security.policy forum.

Comment 1

[Hisashi Kamo]

Dear Wayne-san,

Thank you for the notice.
I apologize for late response due to the trouble in our mail system and the confirmation of the Bugzilla e-mail was delayed.

We will undertake to investigate the countermeasures.

Best regards,
Hisashi Kamo

Comment 2

[Hisashi Kamo]

Dear Wayne-san,

Let us provide you our incident report as below.

1.How your CA first became aware of the problem

Via Bugzilla at 01:09 on April 10, 2018.

2.A timeline of the actions your CA took in response.

-Regarding TSA certs, we asked Mozilla and Microsoft and got reply that TSA certs were not scope on BR, and no problem for WebTrust audit.
(June 16, 2016 from Mozilla and June 18, 2016 from Microsoft)
-Amend Section 6.1.7 of Baseline Requirements (Ballot 189) was adopted on April 14, 2017.
BR section 6.1.7 is described as below and we could not realize as the exception of TSA certs. This exception section 3 is not changed as before and after the ballot 189.
(BR 6.1.7 
3. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates);and”)
- We received Bugzilla at 01:09 on April 10, 2018.
- We started to undertake for investigation about the countermeasures on April 12, 2018. (We apologize for late response to Bugzilla due to the trouble in our mail system)

3.Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. 

Not applicable - problem was with TSA certs

4.A summary of the problematic certificates.

Not applicable - problem was with TSA certs

5.The complete certificate data for the problematic certificates. 

Not applicable - problem was with TSA certs

6.Explanation about how and why the mistakes were made

Regarding TSA certs, we previously asked Mozilla and Microsoft and got reply that TSA certs were not scope on BR, and no problem for WebTrust audit.
In the subsequent voting result, TSA was deleted from the exception, but we could not realize because the description part of the content was limited as Background of Ballot 189.
This exception section 3 of BR 6.1.7 is not changed as before and after the ballot 189.
In addition to this, regarding compliance with BR, we mainly strive to respond to newly occurring requirements in a timely manner.
As a result, TSA compliance which was a conventional problem remains.

7.List of steps your CA is taking to resolve the situation

We are now planning to change to more secure new Root CA( Security Communication RootCA3: SHA-256, RSA4096bit) which will be negotiated with Adobe shortly to embed and then we will not directly issue TSA certs from this new Root CA.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 3

[Wayne Thayer]

(In reply to Hisashi Kamo from comment #2)
> 
Thank you for providing the incident report. 

> 7.List of steps your CA is taking to resolve the situation
> 
> We are now planning to change to more secure new Root CA( Security
> Communication RootCA3: SHA-256, RSA4096bit) which will be negotiated with
> Adobe shortly to embed and then we will not directly issue TSA certs from
> this new Root CA.
> 
What is the timeline for completing this change?

Will you issue any more TSA certs from a root prior to making this change?

Comment 4

[Hisashi Kamo]

Dear Wayne-san,

We would like to build new TSA intermediate CA and verify with customers along with to negotiate and embed on Adobe, thus our target right now is end of September.
Prior to making this change, we do not have a plan to issue TSA certs from a root.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 5

[Hisashi Kamo]

Dear Wayne-san,

We have already built new timestamping intermediate CA and started issuing TSA certificate from that intermediate CA to one of our time stamping provider.

Thank you for your consideration.

Best regards,
Hisashi Kamo

Comment 6

[Wayne Thayer]

Dear Kamo-san,

Thank you for the update. Will you be revoking the timestamping certificates that are still valid and were issued from the root?

Best Regards,

Wayne

Comment 7

[Hisashi Kamo]

Dear Wayne-san,

Let us tell you our idea as below.
On this matter, we believe that revoking TSA certificates is very difficult.

As the reason that TSA certificates are used for documents need to maintain integrity for a long time and it is due to various circumstances related to the Japan's Digital Signature Act.

- TSA certificates are issued for the validity period of 11 years (renewed every year), used for signing for 1 year and used for verification for the remaining 10 years.

- The documents to be verified contain a large number of legal documents such as agreements between well-known major listed companies in Japan.

- It is necessary to secure the authenticity of the documents during the valid period of those legal documents.

Please let us add that Japan's accredited TSA authorities are operated based on strict security standards of Japan's Digital Signature Act that is comparable to WebTrust audit standard.

It will be greatly appreciated if you have any advice or plan on this matter.

Best regards,
Hisashi Kamo

Comment 8

[Wayne Thayer]

In my opinion, the explanation given for not revoking the misissued TSA certificates is acceptable. As there are no other remaining actions, I am closing this bug.