Closed Bug 1478933 Opened Last year Closed 9 months ago

Camerfirma, Qualified Audit Statements

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: martin_ja, Assigned: martin_ja)

Details

(Whiteboard: [ca-compliance])

Attachments

(6 files, 3 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704003137

Steps to reproduce:

The purpose of this bug is to store documents related to the publicly disclosed and audited intermediate certificates chaining up to AC Camerfirma, S.A. root certificates.
All three audit statements contain qualifications, some of which are mis-issuance.

Please provide a timeline for resolving all of these qualifications, and keep this bug updated with progress.
Assignee: kwilson → martin_ja
Summary: Documents for AC Camerfirma, S.A. intermediate certificates → Camerfirma, Qualified Audit Statements
Whiteboard: [ca-compliance]
For qualifications that have been previously documented in a compliance bug, please just reference the bug. For qualifications that have not been previously documented, please supply a full incident report [1] describing the problem in detail along with remediation plans.

Please post your responses here and in the mozilla.dev.security.policy "InfoCert Acquisition of Camerfirma" thread.

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report
Flags: needinfo?(martin_ja)
I've sent email to msroot@microsoft.com to turn off the Code Signing trust bit for the "Chambers of Commerce Root", "Global Chambersign Root", and "Global Chambersign Root - 2008" roots. 
	- https://ccadb.force.com/001o000000HshEIAAZ
	- https://ccadb.force.com/001o000000HshF0AAJ 
	- https://ccadb.force.com/001o000000HshF1AAJ
Flags: needinfo?(martin_ja)
(In reply to Wayne Thayer [:wayne] from comment #7)
> For qualifications that have been previously documented in a compliance bug,
> please just reference the bug. For qualifications that have not been
> previously documented, please supply a full incident report [1] describing
> the problem in detail along with remediation plans.
> 
> Please post your responses here and in the mozilla.dev.security.policy
> "InfoCert Acquisition of Camerfirma" thread.
> 
> [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Juan: It has been nearly three weeks since I requested Camerfirma's response to all of the previously unreported issues listed in the latest audit reports. When can we expect that response?
Flags: needinfo?(martin_ja)
Hello Wayne,
Our efforts are fully dedicated to correct the detected qualifications and give a date to carry out a point-in-time audit as soon as possible.
We are in vacation period so the availability of all the people involved, including the auditors, is limited at this time. So apologize for this delay. We plan to report the new bugs along the next week and perform the PIT audit along the next month.
Best Regards
Flags: needinfo?(martin_ja)
Ramiro Muñoz posted the following incient report to the mozilla.dev.security.policy forum:

Hi Wayne here you are a response to the qualified audits. As you remarks we have include links to the previously reported bugs. We will keep you informed about the remediation process plan. Sorry for the delay  as you know Juan Angel is the person in charge of this Work and is on vacation for some days.

1- 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.

As a result of the annual Webtrst CA BR EV AC Camerfirma has been required by our auditors by means a Qualified Audit Reports a series of changes.
W4CA-1. Some discrepancies between CPS and CP

W4CA-2. Some CPs do not disclose all topics in RFC3647

W4CA-3. Camerfirma had issued certificates with error (already reported
https://bugzilla.mozilla.org/show_bug.cgi?id=1431164).

W4CA-4. Camerfirma had not revoked certificates within the time frame in accordance with the disclosed business practices (already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977)

W4CA5. For a few certificates OCSP information was inconsistent between the OCSP and CRL service under certain circumstances.

WBR-1. No sufficient controls to ensure that the CA implements the latest version of the Baseline Requirements.

WBR-2. Camerfirma had issued certificates with errors according to the CA/B Forum requirements. (Already reported
https://bugzilla.mozilla.org/show_bug.cgi?id=1431164)

WBR-3. Investigation of Certificate Problem Reports within 24 hours. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977).

WBR-4. During our procedures, we noted that for some revocation requests the subscriber Certificates were not revoked within 24 hours. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977).

WBR-5. Not evidence self-assessments on at least a quarterly basis against a randomly selected sample of at least three percent of the Certificates issued.

WEV-1. Camerfirma had issued certificates with errors according to the CA/B Forum requirements. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1431164)

WEB-2. For a few certificates OCSP information was inconsistent between the OCSP and CRL service under certain circumstances.

WEB-3. During our procedures, we noted that for some revocation requests the subscriber Certificates were not revoked within 24 hours. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977).

WEB4. Investigation of Certificate Problem Reports within 24 hours. (Already reported https://bugzilla.mozilla.org/show_bug.cgi?id=1390977).


2- 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.

During the Audit process our auditors detected some differences answers form OCSP services and CRL.
We detected some problems in the Trigger system that synchronize PKI platform and the OCSP platform. We decided to perform a full check in the OCSP platform and fix the inconsistences discovered.
2018-07-14 -> Release of the Qualified Audit Report
 2018-09-20 -> CP/CPS modification & clarification published (W4CA-1 W4CA-2 WBR-1 WBR-5)
2018-09-10 -> Complete DDBB OCSP/PKI/CRL reviewed and fixed (W4CA-5 WEV-2)
2018-09-17 -> technical controls and synchronization reports deployed. (W4CA-5 WEV-2)
October-2018 -> Depending on the Auditor availability PIT Audit.


3- 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.


CP/CPS issues are certificate are not a certificate issuing problem.
OCSP/CRL We have no found new issues in our OCSP manual controls. All certificates are correctly issued.


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.


CP/CPS issues. Do not affect to any certificate.
OCSP/CRL issue. Certificates are issued correctly. Nevertheless we are detecting wich certificates could have been affected by the inconsistences. We will provide a list in the next days.

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.

CP/CPS issues. Do not affect to any certificate.
OCSP/CRL issue. Certificates are issued correctly. Nevertheless we are detecting wich certificates could have been affected by the inconsistences. We will provide a list in the next days

6- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

CP/DPC issues……
W4CA-1
This issue comes from different interpretation from the auditor about CP and CPS. AC Camerfirma has working mainly with the CPS. AC Camerfirma CP was written in a very basic way in order to describe in detail its activity in the CPS. Information in CPS prevailed over CP. Nevertheless Auditors states that Camerfirma should fix some discrepancies between them like:
Key lengths, Contact information, reuse of keys differ between CPS and CP: From Camerfirma point of view CPS prevails. Ac Camerfirma fix this inconsistence.
W4CA-2
Disclose all topics of RFC 3649. Ac Camerfirma CPS is RFC 3649 compliance. AC Camerfirma will include all topics in the CP as well.
WBR-1.
Ac Camerfirma has a more close control about changes in the CABFORUM BR policies and modify the update CPS procedure to assure that the latest BR version is covered by our CPS.
WBR-5.
A complete Self-assessment is made over 3% of the EV certificates, and also over the all OV certificates (crt.sh) although the OV self-assessment did not cover the complete investigation as the auditor’s opinion. AC Camerfirma has changed the self-assessment procedure to include a full investigation over the 3% of the OV as well.
OCSP/CRL Issues…
W4CA5, WEB-2
OCSP and PKI/CRL are independent platforms and are synchronized by DDBB triggers. This triggers are not working properly under some circumstances (heavy traffic) and produce errors, others errors comes from behaviors when suspend and activate certificates.
Before this audit report no manual nor technical controls about OCSP/CRL synchronizations were installed.

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.

AC Camerfirma has made changes in the CP/CPS to fix the inconsistences found by the auditor and will disseminate the documents and the new procedures to avoid news problems in a future.
AC Camerfirma is working on correcting the imbalances detected and the effective processes to ensure that the information offered by the OCSP and the CRL is the same.
2018-07-14 -> Qualified Audit Report
2018-09-17 -> CPS & CP's new versions will be disclosed
New procedures and CPS/CP versions will be distributed among all affected people in other to avoid new differences between CP/CPS
New procedures for self-assessment include full revision of OV certificates.
Best control over changes in the BR version and modifications in AC Camerfirma CP/CPS.
2018-09-17 -> Finish a full review of the OCSP DDBB and synchronization with the PKI DDBB.
2018-09-24 -> fixed all inconsistences found. We've reviewed the complete databases and checked the correct OCSP/PKI/CRL alignment, correcting the problems found.
2018-10-01 -> Technical control to avoid inconsistences. We've improving the execution of the triggers and develop the controls that confirm their correct operation.
018-10-01 -> timely reports (weekly to monthly basic) to assure technical controls are working and no new inconsistences are produced.
Based on the incident report in comment #11, I understand that Camerfirma is planning a point-in-time audit to confirm that the problems identified by the qualified audit reports have been fixed. I would like to be specific about Mozilla's expectations:

Mozilla will accept the following as remediation for the audit issued documented in this bug:

1. Point-in-time WebTrust for CAs, WebTrust BR with Network Security, and WebTrust EV audits performed no later than 31-October, 2018. These audit reports must include all of the root and intermediate certificates that were in the scope of the prior period's qualified audits, they must be delivered to Mozilla within 90 days of the audit date, and they must conform to the other requirements of section 3 of Mozilla policy. In addition, the Management Assertions must include statements indicating that each issue identified as a qualification in the prior period's audit statement has been fixed. If any qualifications or "other matters" are noted indicating that either report is not "clean", Mozilla reserves the right to require Camerfirma to perform additional audits.
2. Camerfirma's next period-of-time audit must be conducted no later than April 13, 2019 covering a period beginning on April 14, 2018. In other words, if no additional problems are discovered, Camerfirma may remain on its existing period-of-time audit cycle.

Juan: Please confirm that you understand and agree to these conditions.
Flags: needinfo?(martin_ja)
Hello Wayne,

We understand and agree these conditions.

I can also inform you that Microsoft has told us that they turn off the Code Signing trust bit in their september release for the "Chambers of Commerce Root", "Global Chambersign Root", and "Global Chambersign Root - 2008" roots. 

Best regards
Flags: needinfo?(martin_ja)
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 01-February 2019
Juan: please provide a progress report and link to the updated CPS.
Flags: needinfo?(martin_ja)
Hello,

Since WebTrust's audits we've disclose four new versions (May (2), June & July). 

http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_3.3.1_EN.pdf (May)
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_1.2.4_EN.pdf (May)
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_1.2.5_ES.pdf (June)
http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_eidas_1.2.6_EN.pdf (July)

We're going to disclose new versions before PiT audit (next week).

2018-09-28 -> CPS new versions will be disclosed 
2018-09-28 -> Finish a new full review of the OCSP DDBB and synchronization with the PKI DDBB.
2018-09-30 -> Fixed all inconsistences found. We've reviewed again the complete databases and checked the correct OCSP/PKI/CRL alignment.

Ramiro Muñoz posted an answer related with this issue at: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/Xmr13-ZK0_c

"Hi Wayne 

All problems have already been resolved from our side and we wait for the PIT audit planned for the next week. 
We will be able to provide the PIT before October 31th." 


Best Regards
Juan Angel
Flags: needinfo?(martin_ja)
Component: CA Certificate Root Program → CA Certificate Mis-Issuance
QA Contact: kwilson
I've checked the new version of the CPS [1]. Section 3.2.5.5 states:

Domain Validation is carried out by one of the methods accepted by CA/B  Forum  in  the  version  declared  in  point  1.1  Overview  at  the time of validation of the certificate

Mozilla policy section 2.2(4) states:

The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.5 it is complying with.

I do not believe the CPS complies with Mozilla policy. Mozilla policy section 2.2(2) requires this same disclosure for email validation practices, and that is also not documented in the CPS

BR 2.2 requires section 4.2 of the CPS to disclose CPS validation practices. The disclosure is not in this section, and it does not include the required documentation of recognized CAA domains.

Please update the CPS to fix these issues and confirm that it meets ALL policy requirements.


[1] https://www.camerfirma.com/publico/DocumentosWeb/politicas/CPS_EN_3.3.3.pdf
Hello,

we'll update the CPS with new versions that meets all policy requirements once the chack that's been done in the PiT audit will be finished if you think it's right.

About the BR point 4.2 issue, nowadays these info is included into 3.2.5.2. Point 4.2 musts reference it and it doesn't. We'll disclose new version with these info into 4.2 (not a reference).

Best Regards
Juan Angel
(In reply to Juan Angel Martin from comment #17)
> Hello,
> 
> we'll update the CPS with new versions that meets all policy requirements
> once the chack that's been done in the PiT audit will be finished if you
> think it's right.
> 
I do not think that is the best approach. I would expect to see a non-conformity listed in your audit report(s) if the PiT audit is performed against the current CPS because section 4.2 violates the BRs. The PiT audit is intended to confirm that all problems have been fixed, so I would recommend auditing against a corrected version of your CPS.

> About the BR point 4.2 issue, nowadays these info is included into 3.2.5.2.
> Point 4.2 musts reference it and it doesn't. We'll disclose new version with
> these info into 4.2 (not a reference).
> 
> Best Regards
> Juan Angel
Hello Wayne,

We'll be audited against the the corrected version of our CPS

Thanks,
Juan Angel
Hello,

we've disclose the new CPSs versions (PiT)

Camerfirma CPS eIDAS v1.2.9 -> https://www.camerfirma.com/publico/DocumentosWeb/politicas/CAMERFIRMA_CPS_EIDAS_EN_1.2.9.pdf
Camerfirma CPS v3.3.4 -> https://www.camerfirma.com/publico/DocumentosWeb/politicas/CAMERFIRMA_CPS_EN_3.3.4.pdf

Regards
Juan Angel
Hello
Hello, 

I've uploaded the PiT audit reports (W4CA, WBR & WEV)

Regards
Juan Angel
(In reply to Juan Angel Martin from comment #20)
> Hello,
> 
> we've disclose the new CPSs versions (PiT)
> 
> Camerfirma CPS eIDAS v1.2.9 ->
> https://www.camerfirma.com/publico/DocumentosWeb/politicas/
> CAMERFIRMA_CPS_EIDAS_EN_1.2.9.pdf
> Camerfirma CPS v3.3.4 ->
> https://www.camerfirma.com/publico/DocumentosWeb/politicas/
> CAMERFIRMA_CPS_EN_3.3.4.pdf
> 
> Regards
> Juan Angel

I am satisfied with the changes in these new versions.
Resolving as it appears that remediation for this issue has been completed.
Status: UNCONFIRMED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Whiteboard: [ca-compliance] - Next Update - 01-February 2019 → [ca-compliance]
You need to log in before you can comment on or make changes to this bug.