Closed Bug 1398233 Opened 2 years ago Closed 2 years ago

Sertifitseerimiskeskuse: Non-BR-Compliant OCSP Responders

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kwilson, Assigned: mihkel.tammsalu)

References

Details

(Whiteboard: [ca-compliance])

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
I have sent email to this CA to inform them of this bug, and request that their current POCs get Bugzilla accounts and respond in this bug.
It was also noted that this CA needs to provide an email address for reporting problems.

Currently their Problem Report Mechanism as stated in the Common CA Database says:
We have published 24/7 contact information for all parties to inform us of any suspicions and revocations. Use cases for all parties to inform us are described in our terms and conditions published on our website.

This is not very helpful, so the CA needs to send Kathleen the exact URL and/or email address to put into this field in the CCADB.
SK ID Solutions is aware of the OCSP issue and we are already making detailed action plan for resolving the bug reported #1398233. If needed planning is made we will provide also the incident report. 

Mihkel Tammsalu 
SK ID Solutions AS 
Service Manger
(In reply to Kathleen Wilson from comment #0)

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

Where this incident report must be presented? In group topic here?: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/o1MX07iWDco/RuM1NK_0AQAJ
Flags: needinfo?(kwilson)
It is fine to post the incident report in this bug.

Gerv
Flags: needinfo?(kwilson)
Incident report:

1) How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the date.
> SK ID Solution AS (hereafter SK) got notified of the issue (bug) on the 8th of September via email from Kathleen Wilson, referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1398233

2) A timeline of the actions your CA took in response.
a) On 9th september SK received a registered bug via email from Kathleen Wilson, referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1398233
b) 11th till 14th september the reported bug #1398233 was presented to needed people inside SK who will be involved to fix it and the first draft plan was made.
c) On 25th september we have complete overview what actions are needed to take, to resolve/fix the OCSP issue latest 09/10/2017

3) Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
> Not applicable

4) 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.
> Not applicable

5) 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.
> Not applicable

6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
> At that point when the root CA OCSP was implemented, SK was aware of the decision to use CRL based information in OCSP response as the root A itself is offline.


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.
> Latest 09/10/2017 SK will immplement fix in the system where new OCSP database is created based on certificates issued by root CA. Then the OCSP response is created according the right information. All other requests for certificate serials which are not in this database is OCSP response conform to BR requirement with Status="unknown".

If there are some extra explanations needed, let us know!

Mihkel Tammsalu
SK ID Solutions AS
Trust Service Manger
(In reply to Kathleen Wilson from comment #2)
> It was also noted that this CA needs to provide an email address for
> reporting problems.


This has been provided by the CA, and I updated the "Problem Reporting Mechanism" field for this CA in the Common CA Database.
# Incident report status update:

06.10.17 - we have implemented the fix in our system. Also we tested it in the test environment and all seems to work as planned.

But we need to postpone the date (09/10/2017) when we swich our CA OCSP to use the new system, because on 05/10 started Estonian e-elections (https://www.valimised.ee/en/municipal-council-election-2017) and at that period we have "freeze" where we can not make any changes in live environment, to lower the risk that some change might affect the whole ecosystem. So we can make the chnage latest 18/10.2017
(In reply to Mihkel Tammsalu from comment #6)
> > Latest 09/10/2017 SK will immplement fix in the system where new OCSP database is created based on certificates issued by root CA. Then the OCSP response is created according the right information. All other requests for certificate serials which are not in this database is OCSP response conform to BR requirement with Status="unknown".

The requirement to not return "good" for unknown certificates has been in the BRs for several years, due to the Diginotar incident. Was Sertifitseerimiskeskuse aware of this requirement? If not, why not? If so, why has it taken an incident like this in order for the requirement to be implemented?

Gerv
Assignee: kwilson → mihkel.tammsalu
Status update is that OCSP fix is in LIVE for our CA OCSP.

(In reply to Gervase Markham [:gerv] from comment #9)
> (In reply to Mihkel Tammsalu from comment #6)
> > > Latest 09/10/2017 SK will immplement fix in the system where new OCSP database is created based on certificates issued by root CA. Then the OCSP response is created according the right information. All other requests for certificate serials which are not in this database is OCSP response conform to BR requirement with Status="unknown".
> 
> The requirement to not return "good" for unknown certificates has been in
> the BRs for several years, due to the Diginotar incident. Was
> Sertifitseerimiskeskuse aware of this requirement? If not, why not? If so,
> why has it taken an incident like this in order for the requirement to be
> implemented?
> 
> Gerv

I guess our incident report point #6 answered why the decision was made, I repeat:

6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
> At that point when the root CA OCSP was implemented, SK was aware of the decision to use CRL based information in OCSP response as the root A itself is offline.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.