Closed Bug 1398259 Opened 7 years ago Closed 6 years ago

SECOM: Non-BR-Compliant OCSP Responders

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: h-kamo)

References

Details

(Whiteboard: [ca-compliance] [ocsp-failure]) 

Problems have been found with OCSP responders for this CA, and reported in the mozilla.dev.security.policy forum here:

https://groups.google.com/d/msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ

As per section 4.9.10 of the BRs, OCSP responders MUST NOT respond with a “good” status for unissued certificates. The effective date for this requirement was 2013-08-01.

Please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
Dear Kathleen-san,

We are already examining details of countermeasures with software vendor.
Upon progress, let us provide you an incident report.
Hisashi: do you have any update?

Gerv
Dear Gerv-san,

We have been confirming continuously with the software vendor, and the countermeasures were found.
We are waiting for the specific procedures from them.
Hopefully, we will be able to comment next week.
Dear Gerv-san,

Let us update the current status as follows.
In cooperation with the software vendor, we realized details of program modification to cope with this issue.
We are now developing the program to output the list of serial numbers of issued certificates and send them to OCSP.
We are continuing closely collaborating with the software vendor and are working diligently, and we expect to complete in several weeks.
The status of the progress and schedule will be reported again when it becomes clear.
Let us report for SHA-1 OCSP responder certificates as below.

For our SHA-1 route and SHA-1 intermediate CAs, OCSP responder certificates were issued by SHA-1.
The SHA-1 OCSP responder certificates for 1 route and 2 intermediate CAs have already been revoked today and yesterday.
Regarding 1 root CA and 1 intermediate CA, it is necessary to change to the OCSP responder certificate of SHA-2, 
but it is related to the specification of the CA product and it is now under investigation of an immediate countermeasure.
(All SSL/ TLS certificates have been revoked but because the certificates validity period have not expired.)

We also supplement the following.
In the case other than for OCSP, SHA-1 SSL/ TLS certificates have never been issued since January 1, 2016.
All SSL/ TLS certificates issued before January 15, 2015 that have expiration dates after January 1, 2017 have already been revoked.

/ Revoked 
https://crt.sh/?id=220573680&opt=cablint
https://crt.sh/?id=220607689&opt=cablint
https://crt.sh/?id=220573686&opt=cablint

/ Will be changed to SHA-2
https://crt.sh/?id=220563972&opt=cablint
https://crt.sh/?id=220607693&opt=cablint

Best regards,
Hisashi Kamo
(In reply to Hisashi Kamo from comment #4)
> In cooperation with the software vendor, we realized details of program
> modification to cope with this issue.
> We are now developing the program to output the list of serial numbers of
> issued certificates and send them to OCSP.

The requirement not to return "good" for unknown certificates has been a requirement for several years, following the Diginotar breach. Why is it just being implemented now? Was SECOM unaware of this requirement? Was SECOM's vendor unaware of this requirement?

Gerv
We were awared of this requirement.

We could not confirm the existence of the modification program so far, but we got this timing because we got the details of the procedure to output the list of serial numbers of issued certificates and send them to OCSP, and then we are now working diligently to cope with this.

As a current situation, although we are checking the operation with the setting procedures provided by the vendor applying the modification program, it is not working properly. 
We are checking the details to the vendor and still corresponding.

Best regards,
Hisashi Kamo
(In reply to Hisashi Kamo from comment #7)
> We were awared of this requirement.

Then why was it not implemented until now?

Gerv
We conducted a program modification investigation, but the investigation was not enough and failure to realize countermeasures.
We decided that we could not implement countermeasures because of the problem regarding not only the OCSP but also the CA product not having any countermeasures.
Those are why the implementation is now.
We believe the point of reflection is that the subsequent investigation was not enough.

Best regards,
Hisashi Kamo
Hi Hisashi,

I'm afraid I don't understand your last comment :-( Could you either explain more specifically, or perhaps even ask someone with more fluent English to explain it?

Thanks,

Gerv
Dear Gerv-san,

I apologize for it.
At the last comment, I meant following.
We believe that this issue occurred as a result of not conducting adequate investigation.
Since then, we would like to conduct a thorough investigation.

Best regards,
Hisashi Kamo
Hisashi: I'm afraid the answers you are giving are not nearly detailed enough for us to have continued confidence in SECOM's processes and procedures. If this requirement was overlooked, how many other requirements have been overlooked? What are you doing to find the root cause, work out if other BR requirements were affected, and make sure SECOM is in full BR compliance?

Gerv
Dear Gerv-san,

Regarding compliance with BR, we mainly strive to respond to newly occurring requirements in a timely manner.
As a result, OCSP compliance which was a conventional problem remains.
We are sorry that the investigation of the details including the vendor on this issue was not enough.

As for BR, this is very important to interpret language precisely, so we are currently translating the whole latest version.
We are going to confirm again the translated version of BR and carry out self assessment based on the translated version of BR.

Best regards,
Hisashi Kamo
Hisashi-san: please can you compile a full incident report for this incident, as outlined here? https://wiki.mozilla.org/CA/Responding_To_An_Incident .

Gerv
Dear Gerv-san,

Regarding the incident report, please let us provide you early next week.
Thank you for your consideration.

Best regards,
Hisashi Kamo
Dear Gerv-san,

Here is the incident report.

1.	How your CA first became aware of the problem 
Via a problem report submitted to your Problem Reporting Mechanism at 9:48PM on August 29, 2017.

2.	A timeline of the actions your CA took in response.
2017/09/01 18:26　Initiate investigation with a vendor.
2017/09/01 19:08  Reply mozilla.dev.security.policy for Initiate investigation.
2017/09/07 19:19  Escalate to department of vendor’s home country handling this issue.
Details are described in Section 7.

3.	Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.
Not applicable. Problem was with OCSP response.

4.	 A summary of the problematic certificates.
Not applicable. Problem was with OCSP response.

5. 	The complete certificate data for the problematic certificates.
Not applicable. Problem was with OCSP response.

6. 	Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Regarding compliance with BR, we mainly strive to respond to newly occurring requirements in a timely manner.
As a result, OCSP compliance which was a conventional problem remains.
We are sorry that the investigation of the details including the vendor on this issue was not enough and failure to realize countermeasures.

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.

The steps are as follows.

(9/1)  Initiate investigation about CA product specifications and countermeasures with the vendor.
(9/7)  Escalate to department of the vendor’s home country handling this issue for exact countermeasures.
(9/15) Obtain countermeasures from the vendor.
(from 9/21) Expected results cannot be obtained by application of countermeasures, and then initiate for investigation and confirmation of correspondence contents with the vendor including home country.
(10/4)  Confirm for specifications of CA product regarding SHA-2 compatibility of OCSP certificate.
(from 10/4)  Start investigating countermeasures for CA products that SHA-1 CA cannot sign SHA-2.
When the server certificate is SHA-1 and the CRL is SHA-2 signed, it is necessary to investigate whether browsers and OS can correctly verify for revocation using CRL.
When OCSP is SHA-2, CRL is also SHA-2 signed due to the CA product specifications, it is necessary to verify whether there is no problem even if the server certificate is SHA - 1 and CRL is SHA-2.
(10/5)  Revoke SHA-1 OCSP certificates of two intermediate CAs
(10/6)  Revoke a SHA-1 OCSP certificate of root CA
(10/16)  Apply of countermeasures (respond with unknown status for a certificates that has not been issued) 
(from 10/16)  Initiate confirmation to develop requirements of program modification with the vendor. (DB search, program automatically create the original data of revocation information) 

Because it takes long to develop the program modification, we would like to correspond  with the route CA in advance that automatically creation is unnecessary.
In regards to intermediate CA, we would like to correspond after the development of program modification.

We believe that this issue occurred as a result of not conducting enough investigation.
From now on, we would like to conduct a thorough investigation even in case of issues involving vendors.

Best regards,
Hisashi Kamo
Hisashi-san: has this problem yet been resolved in production?

Gerv
Flags: needinfo?(h-kamo)
Dear Gerv-san,

Regarding countermeasures to respond with unknown status for certificates that have not been issued, we are now almost finish the program modification and move on to the test process.
Our target to solve this issue is by the end of December.

Best regards,
Hisashi Kamo
Flags: needinfo?(h-kamo)
Hisashi: please provide an update on the problem of SECOM OCSP responders returning a 'good' response for unknown certificates, The following report indicates that a number of SECOM CAs are still not in compliance.

https://crt.sh/ocsp-responders?randomserial=Good&trustedBy=Mozilla&trustedFor=Server%20Authentication&trustedExclude=constrained,expired,onecrl&randomserial=Good&sort=2&dir=v

Wayne
Dear Wayne-san,

We apologize for delay.
We are now evaluating the final stage of the test process.
The target date right now will be February 6.

Thank you for your consideration.

Best regards,
Hisashi Kamo
Whiteboard: [ca-compliance] → [ca-compliance] [remediation-accepted] Next Update - 6-Feb 2018
Dear Wayne-san,

We apologize for delay.

The issue for Root CAs has been solved.
We are now working diligently to solve for intermediate CAs, thus let us have some more time until March 5 due to troubleshooting and final work.

Thank you for your consideration.

Best regards,
Hisashi Kamo
Whiteboard: [ca-compliance] [remediation-accepted] Next Update - 6-Feb 2018 → [ca-compliance] [remediation-accepted] Next Update - 5-Mar 2018
Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254
QA Contact: gerv → wthayer
Dear Wayne-san,

Let us inform you that the issue for intermediate CAs was solved today.
(Regarding root CAs, it has been already solved before)

Thank you for your consideration.

Best regards,
Hisashi Kamo
The report linked above confirms that this problem has been fixed, so I am marking this resolved.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] [remediation-accepted] Next Update - 5-Mar 2018 → [ca-compliance] [ocsp-failure]
You need to log in before you can comment on or make changes to this bug.