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 18.104.22.168 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 22.214.171.124.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 126.96.36.199.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 email@example.com. This mail was sent by firstname.lastname@example.org because of our company out bound email regulations.
After that, the discussion on email@example.com 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.