Camerfirma: Govern d'Andorra Audit Delay
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: ana.lopes, Assigned: ana.lopes)
Details
(Whiteboard: [ca-compliance] [audit-failure] [audit-delay])
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.90 Safari/537.36
Steps to reproduce:
-
How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
We became aware of the problem when the Govern of Andorra told us that they will not be able to carry the audit within the planned deadlines because the auditor assignation had been cancelled due to internal issues (March 30th, 2021) -
A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
2.1. After knowing the situation, we studied the possibilities to have an audit report in time and not affect the CA services. (March 30th – April 6th )
2.2. We study the possibilities to speed the audit assignation process and contacted some audit companies to ask them to begin the audit review as soon as possible. Camerfirma took control of this year's audit and followed its internal process to select the auditor in a short time as an exception due to the extraordinary situation (April 6th )
2.3. After studying all the possibilities, we were conscious that it would not be possible to have the report in time, but we could have it with a little delay, so we decided to accept this best option that consist of starting the audit next week and have the report available for the first week of May. (April 8th) -
Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
The CA has not stopped its activity. We will have the audit of the correct period only two weeks later without any gaps in the audit period and we do not consider it as a risk for the users or the CA activity. -
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.
There are a total of 12205 affected certificates, that corresponds to the total amount of certificates issued during the period to be audited (January 17th 2020 to January 16th 2021), -
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.
See attached file. -
Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The CA Entitat de Certificació de l'Administració Pública Andorrana-19, belonged to the Govern of Andorra manages its audits by itself and they have a very strict procedure with a lot of internal management requirements to assign the auditors every year.
For this year’s audit they published the offer on December 12th 2020 (https://www.bopa.ad/bopa/032149/Pagines/GC20201210_16_32_34.aspx) with a deadline to apply until January 12th 2021 and nobody applied to the offer. They started a second process and changed some points on February 1st 2021. This time some audit companies presented their candidature and they planned to assign the auditor and start this week as latest, but last week (March 30th 2021) we were informed about the assignment cancellation made by the governmental supervisor because they had not complied with the public administrator procedures for this kind of contracts.
After their communication we started planning the strategies and considering different scenarios.
Due to the impossibility to have the auditor assignation in time to have the audit ready, we have stablished a plan with them so that the audit can start next week, but it will not be finished until May and we will not have the audit ready to publish in CCADB in time (April 16th 2021). -
List of steps your CA is taking to resolve the situation
• We studied the possibilities to manage the audit to get an audit report in time with The Govern of Andorra (March 30th – April 6th )
• Camerfirma took control of the audit assignation process for this year’s audit as an exception due to the extraordinary situation (April 6th )
• Now, we are atudying the contractual possibilities to internalize the annual audit management process for the following years. Our purpose is to manage the audits for all our SubCAs, but in cases like this, we need to analyze the contract because Govern of Andorra is a public administration with specific regulation for contracts.
|
||
Updated•4 years ago
|
We became aware of the problem when the Govern of Andorra told us that they will not be able to carry the audit within the planned deadlines because the auditor assignation had been cancelled due to internal issues (March 30th, 2021)
1.) How come you only realised that this audit would be delayed on April 7th when you were told exactly that on the 30th of March?
2.) Why did you only disclose this issue 10 days after you were notified that this audit would be delayed, and two days after you 'realised' that the audit would be delayed?
The wiki page on audit statements is quite clear in that regard:
When a CA realizes that their audits will be delayed by a force majeure, Mozilla expects the CA to promptly disclose the issue, to provide regular updates, and to remain fully compliant with all other aspects of the Mozilla Root Store policy
- https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
- List of steps your CA is taking to resolve the situation
- We studied the possibilities to manage the audit to get an audit report in time with The Govern of Andorra (March 30th – April 6th )
- Camerfirma took control of the audit assignation process for this year’s audit as an exception due to the extraordinary situation (April 6th )
- Now, we are atudying the contractual possibilities to internalize the annual audit management process for the following years. Our purpose is to manage the audits for all our SubCAs, but in cases like this, we need to analyze the contract because Govern of Andorra is a public administration with specific regulation for contracts.
[context]
In one of your previous communications [0] on the mozilla-dev-security mailing list, you mentioned the following, with a planned date of June 2021:
a. Action Point 10.
Insource the management of all the operational activities of the intermediate CAs (June 2021).
How:
- Obligation of the SubCA to use the application of controls defined by Camerfirma (obligation to send us evidence that they have implemented them).
- SubCA obligation to submit to audits set by Camerfirma and with an auditor selected by Camerfirma.
- Insource management of all the operational activities of the intermediate CAs in a discretionary manner.
After requesting more information on this, you responded with some further explanation:
In such a way we’ll be able, at any timer, to insource the management of operational activities of our ‘problematic’ intermediate CA.
While virtuous intermediate CA will be allowed to retain the control of their operational activities as long as they remain virtuous.
[question]
3.) Although I fully understand that June 2021 has not yet come and gone, what is your current status on these points with regards to the Govern 'd Andorra subCA?
[0] https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog
The CA has not stopped its activity. We will have the audit of the correct period only two weeks later without any gaps in the audit period and we do not consider it as a risk for the users or the CA activity.
4.) Assuming that the users that you mention are the end users that use the Mozilla Root Store, and trust the Mozilla Root Store to contain trustworthy roots: Could you help me understand why an unaudited and unconstrained (sub)CA is not considered a risk for the users?
- 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.
See attached file.
I'm having trouble finding the certificates associated with these fingerprints in crt.sh (5 random entries chosen, none found for all of [normal search, sha256(cert), sha256(subjectPublicKeyInfo), serial number]. This is not suprising, as there are 0 certificates for that CA [1] available in crt.sh.
5.) Could you next time validate that you provide enough information for us to retrieve the complete certificate data?
(In reply to Matthias from comment #1)
Please find below the answer to your questions:
1.) How come you only realised that this audit would be delayed on April 7th when you were told exactly that on the 30th of March?
The 30th of March the CA informed us about the problems with the audit assignation. We started working to find an audit company that could perform the audit within the deadlines. We contacted some companies to ask them for a proposal and timeline.
Finally, none of them could assure that they would have the report in time. So we state the date on 7th that was the date when we had already received all the responses.
2.) Why did you only disclose this issue 10 days after you were notified that this audit would be delayed, and two days after you 'realised' that the audit would be delayed?
We became aware of the problem on 7th. We contacted a Mozilla representative immediately to ask them about how to proceed and we reported the problem as soon as we decided the solution and confirm with the selected audit the performance of the audit, that was the day that we opened this bug (9th of April).
We could not report the problem without the confirmation of the auditor for this week’s audit because in case negative, the problem to report would have changed.
3.) Although I fully understand that June 2021 has not yet come and gone, what is your current status on these points with regards to the Govern 'd Andorra subCA?
In this case, the Govern of Andorra had started their internal processes to select the audit company for this year before we established our plan.
Before implementing the new controls, we need to study the contracts to change the conditions with the clients and we could not have the process finished for this year’s audit for that CA, but we will have the control over all their future audits.
4.) Assuming that the users that you mention are the end users that use the Mozilla Root Store, and trust the Mozilla Root Store to contain trustworthy roots: Could you help me understand why an unaudited and unconstrained (sub)CA is not considered a risk for the users?
We do not consider it as a problem for the users because there will not be any gap between audits and the audit will be complete, so all the services given during the period will be analyzed in the report.
5.) Could you next time validate that you provide enough information for us to retrieve the complete certificate data?
All these certificates are SMIME and that is why we do not include them in crt.sh
(In reply to Matthias from comment #1)
Please find below the answer to your questions:
1.) How come you only realised that this audit would be delayed on April 7th when you were told exactly that on the 30th of March?
The 30th of March the CA informed us about the problems with the audit assignation. We started working to find an audit company that could perform the audit within the deadlines. We contacted some companies to ask them for a proposal and timeline.
Finally, none of them could assure that they would have the report in time. So we state the date on 7th that was the date when we had already received all the responses.
2.) Why did you only disclose this issue 10 days after you were notified that this audit would be delayed, and two days after you 'realised' that the audit would be delayed?
We became aware of the problem on 7th. We contacted a Mozilla representative immediately to ask them about how to proceed and we reported the problem as soon as we decided the solution and confirm with the selected audit the performance of the audit, that was the day that we opened this bug (9th of April).
We could not report the problem without the confirmation of the auditor for this week’s audit because in case negative, the problem to report would have changed.
3.) Although I fully understand that June 2021 has not yet come and gone, what is your current status on these points with regards to the Govern 'd Andorra subCA?
In this case, the Govern of Andorra had started their internal processes to select the audit company for this year before we established our plan.
Before implementing the new controls, we need to study the contracts to change the conditions with the clients and we could not have the process finished for this year’s audit for that CA, but we will have the control over all their future audits.
4.) Assuming that the users that you mention are the end users that use the Mozilla Root Store, and trust the Mozilla Root Store to contain trustworthy roots: Could you help me understand why an unaudited and unconstrained (sub)CA is not considered a risk for the users?
We do not consider it as a problem for the users because there will not be any gap between audits and the audit will be complete, so all the services given during the period will be analyzed in the report.
5.) Could you next time validate that you provide enough information for us to retrieve the complete certificate data?
All these certificates are SMIME and that is why we do not include them in crt.sh
Thank you for your response.
3.) Although I fully understand that June 2021 has not yet come and gone, what is your current status on these points with regards to the Govern 'd Andorra subCA?
In this case, the Govern of Andorra had started their internal processes to select the audit company for this year before we established our plan.
Before implementing the new controls, we need to study the contracts to change the conditions with the clients and we could not have the process finished for this year’s audit for that CA, but we will have the control over all their future audits.
6.) Has this incident not changed your opinion on the "virtuous"-ity of this subCA, and you do not consider taking any further action other than what you had already planned for all of your subCAs?
We do not consider it as a problem for the users because there will not be any gap between audits and the audit will be complete, so all the services given during the period will be analyzed in the report.
I am very suprised to see a CA that knows with certainty that they will pass an audit before the auditor has finished said audit. Unless I misunderstand something about the timing of this audit, there is no guarantee that the auditee (Govern d'Andorra) will pass the audit until after the audit has ended. At the moment of writing the initial report, the audit had not yet started ("... so that the audit can start next week")
The complete certificate data for the problematic certificates
5.) Could you next time validate that you provide enough information for us to retrieve the complete certificate data?
All these certificates are SMIME and that is why we do not include them in crt.sh
I think you might not understand my point.
Please note that providing hashes of the certificate data does not equal providing the complete certificate data, unless there is some (public and trusted) database where we can easily look up these hashes to retrieve the certificate data. This is why that section of the problem report template also explicitly mentions "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". CT logging allows e.g. crt.sh to include these certificates into a publicly searchable database. If the certificates are not logged (or otherwise publicly searchable with the provided information), the "complete certificate data" clause is not fulfilled by providing only hashes of the certificate data.
Because this is a delayed audit report, I won't press on receiving the full certificate data. There are no specific problems with the certificates themselves, and I don't consider them important to understanding the problem at hand. But note that if there is a problem with your certificates, "The complete certificate data for the problematic certificates" is not equal to "the hashes of the problematic certificates" unless they are reverseable (e.g. through crt.sh).
Due to the impossibility to have the auditor assignation in time to have the audit ready, we have stablished a plan with them so that the audit can start next week, but it will not be finished until May [...]
7.) Would you have a status update on the current status of the audit?
(In reply to Matthias from comment #4)
6.) Has this incident not changed your opinion on the "virtuous"-ity of this subCA, and you do not consider taking any further action other than what you had already planned for all of your subCAs?
We have included the item 5. Contractual obligations in our action plan for SMIME certificates (https://bug1693113.bmoattachments.org/attachment.cgi?id=9203978) that will help us control the activity of our SubCAs because we consider we need to have more control over their operations in general (not only for this one).
In this case, this SubCA is an internal SubCA that works with Camerfima Infrastructure, so after analyzing this problem and other possible risks, we are working on changing the contracts to have more control over their audits and documentation.
Regarding the following comment "I am very suprised to see a CA that knows with certainty that they will pass an audit before the auditor has finished said audit. Unless I misunderstand something about the timing of this audit, there is no guarantee that the auditee (Govern d'Andorra) will pass the audit until after the audit has ended. At the moment of writing the initial report, the audit had not yet started ("... so that the audit can start next week")":
We cannot assure that this SubCA will pass the audit, but nothing has changed since the last revision and in our opinion, there are no reasons to have new problems in this revision.
7.) Would you have a status update on the current status of the audit?
The audit started on April 12th and, according to the last information provided by the auditors yesterday, the review process is 50% completed.
Update:
The auditors continue performing the audit and we will give more details about their progress next week.
Update:
The auditors are analyzing the last evidences and they expect to end the audit next week and have the report ready in two weeks.
|
|
||
Comment 8•3 years ago
|
||
Hello Ana,
Please provide an update on the status of the audit report.
Thanks,
Ben
Hi Ben,
Sorry for the delay, we were waiting for the signed report to upload them here because the audit tasks took more time than we expected based on the audit program that we received at the begining of the revision.
Please, find the report "IL562 Webtrust CA report - Govern Andorra 2021" attached.
|
Assignee | |
Comment 10•3 years ago
|
||
|
|
||
Updated•3 years ago
|
|
|
||
Comment 11•3 years ago
|
||
I have updated the CCADB with the recent audit report and intend to close this bug on or about Friday, 9-July-2021.
|
|
||
Updated•3 years ago
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Updated•2 months ago
|
Description
•