Closed Bug 1425805 Opened 2 years ago Closed 11 months ago

Consorci AOC: Insufficient Audit Statements

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: fferre, Assigned: fferre)

Details

(Whiteboard: [ca-compliance])

Attachments

(23 files, 2 obsolete files)

192.56 KB, application/pdf
Details
253.20 KB, application/pdf
Details
253.20 KB, application/pdf
Details
46.48 KB, application/pdf
Details
364.23 KB, application/pdf
Details
2.60 MB, application/pdf
Details
803.70 KB, application/pdf
Details
781.12 KB, application/pdf
Details
722.54 KB, application/pdf
Details
719.22 KB, application/pdf
Details
1.14 MB, application/pdf
Details
1.15 MB, application/pdf
Details
1.14 MB, application/pdf
Details
1.14 MB, application/pdf
Details
719.73 KB, application/pdf
Details
718.50 KB, application/pdf
Details
781.40 KB, application/pdf
Details
804.45 KB, application/pdf
Details
509.84 KB, application/pdf
Details
385.67 KB, application/pdf
Details
3.63 MB, application/pdf
Details
443.27 KB, application/pdf
Details
3.53 MB, application/pdf
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Attached file PSC 2017 0002 CAOC.pdf
Incident report:
 
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.
 
Via the CCADB reminder and conversations with auditors. 
 
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.
 
We've ordered an audit covering "for CA", BR SSL and EV requirements for the period not covered with any 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.
 
The issuance of certificates is working properly, wih CAA automated validation, CT implemented, OCSP whitelist working properly and proper profiles.
 
Firmaprofesional is performing the above mention audit, to provide the results within this year.
 
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.
 
The number of certificates issued during this period and still valis is 1220, being the first issued in 20/12/2015 (DD/MM/YYYY) and the last 30/01/2017
 
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.
 
6.- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
 
Taking into account that Consorci AOC is a Qualified TSP (Trust Services Providers) with a positive audit statement on several qualified electronic services according to eIDAS (attached here: https://bugzilla.mozilla.org/attachment.cgi?id=8928964), including certificate services for website authentication it was supposed that these audit would be enough and they are. But the approach, in the first audit to become and eIDAS ready provider is a Point of Time, not a "last year period of time". This is why there is a gap of time not covered by any audit.
 
It has been detected when from Mozilla asked the period of time of the audit and we asked the auditors about this issue.
 
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.
 
Consorci AOC is performing the above mention audit, to provide the results within the following weeks.
Flags: needinfo?(fferre)
Assignee: kwilson → fferre
Whiteboard: [ca-compliance]
Francesc: In your response three weeks ago regarding new audits, you stated that you would 'provide the results within this year' and 'provide the results within the following weeks'. What is the status of these audits?
Flags: needinfo?(fferre)
Dear Mr. Thayer, 

(In reply to Wayne Thayer [:wayne] from comment #8)
> Francesc: In your response three weeks ago regarding new audits, you stated
> that you would 'provide the results within this year' and 'provide the
> results within the following weeks'. What is the status of these audits?

Our new estimated delivery date is 15-March 2018. It is taking us longer given to take the audits given the extension of the periods. 

Sorry for the inconvenience.
Changing QA contact per https://bugzilla.mozilla.org/show_bug.cgi?id=1438254
QA Contact: gerv → wthayer
Reports provided.
Dear Mr. Thayer, 

Could you please update the EV audit dates in salesforce ccadb database for our CA in "https://ccadb.force.com/001o000000HshEi", please?. 

Thank you,
In all of the audit statements listed above, the root certificate that the audit apparently covered is:
""
CN=EC-ACC
Fingerprint=85:2D:52:30:77:05:D3:F2:FF:3F:7E:AC:DB:30:7C:07:79:18:C2:9A:47:68:D4:2D:47:AC:D5:44:52:7A:06:2C
subject= /C=ES/O=Agencia Catalana de Certificacio (NIF Q-0801176-I)/OU=Serveis Publics de Certificacio/OU=Vegeu https://www.catcert.net/verarrel (c)03/OU=Jerarquia Entitats de Certificacio Catalanes/CN=EC-ACC issuer= /C=ES/O=Agencia Catalana de Certificacio (NIF Q-0801176-I)/OU=Serveis Publics de Certificacio/OU=Vegeu https://www.catcert.net/verarrel (c)03/OU=Jerarquia Entitats de Certificacio Catalanes/CN=EC-ACC
""


However, the certificate at https://ccadb.force.com/001o000000HshEi is:

SHA-1 Fingerprint	
28:90:3A:63:5B:52:80:FA:E6:77:4C:0B:6D:A7:D6:BA:A6:4A:F2:E8
SHA-256 Fingerprint	
88:49:7F:01:60:2F:31:54:24:6A:E2:8C:4D:5A:EF:10:F1:D8:7E:BB:76:62:6F:4A:E0:B7:F9:5B:A7:96:87:99

which can be found at https://crt.sh/?id=298


The Fingerprints do not match.
Qualified Audit Report Webtrust  CAOC 2016-2017_v02_en
Dear Kathleen, 

New documents are provided with the right hashes corresponding to:


EC-ACC SHA1 : https://crt.sh/?id=298 
EC-SECTORPUBLIC SHA2 : https://crt.sh/?id=9975892
EC-CIUTADANIA SHA2 : https://crt.sh/?id=12721534

Sorry for the mistake, 

Thank you,
 
Francesc,
Dear Kahtleen, 

(In reply to Kathleen Wilson from comment #19)
> In all of the audit statements listed above, the root certificate that the
> audit apparently covered is:
> ""
> CN=EC-ACC
> Fingerprint=85:2D:52:30:77:05:D3:F2:FF:3F:7E:AC:DB:30:7C:07:79:18:C2:9A:47:
> 68:D4:2D:47:AC:D5:44:52:7A:06:2C
> subject= /C=ES/O=Agencia Catalana de Certificacio (NIF
> Q-0801176-I)/OU=Serveis Publics de Certificacio/OU=Vegeu
> https://www.catcert.net/verarrel (c)03/OU=Jerarquia Entitats de Certificacio
> Catalanes/CN=EC-ACC issuer= /C=ES/O=Agencia Catalana de Certificacio (NIF
> Q-0801176-I)/OU=Serveis Publics de Certificacio/OU=Vegeu
> https://www.catcert.net/verarrel (c)03/OU=Jerarquia Entitats de Certificacio
> Catalanes/CN=EC-ACC
> ""
> 
> 
> However, the certificate at https://ccadb.force.com/001o000000HshEi is:
> 
> SHA-1 Fingerprint	
> 28:90:3A:63:5B:52:80:FA:E6:77:4C:0B:6D:A7:D6:BA:A6:4A:F2:E8
> SHA-256 Fingerprint	
> 88:49:7F:01:60:2F:31:54:24:6A:E2:8C:4D:5A:EF:10:F1:D8:7E:BB:76:62:6F:4A:E0:
> B7:F9:5B:A7:96:87:99
> 
> which can be found at https://crt.sh/?id=298
> 
> 
> The Fingerprints do not match.

If you find them correct, could you please update our CCADB info with this three documents provided, please?

https://bugzilla.mozilla.org/attachment.cgi?id=8966111
https://bugzilla.mozilla.org/attachment.cgi?id=8966113
https://bugzilla.mozilla.org/attachment.cgi?id=8966115

Thank you,
Flags: needinfo?(kwilson)
Francesc, 

Please file a new Audit Case in the CCADB, with these new audit statements. 

https://ccadb.org/cas/updates#instructions

Thanks
Flags: needinfo?(kwilson) → needinfo?(fferre)
Dear Kathleen, 

First of all, sorry for the delay in creating the Cases in the CCADB after providing the audits in this bug weeks ago. 

These are the audit cases created sent for your revision:

- WT CA+BR+EV from 21st december 2015 to 20th december 2016 : case #00264 https://ccadb.force.com/5001J00000aa4AG
- WT CA+BR+EV from 21st december 2016 to 18th june 2017 : case #00265 https://ccadb.force.com/5001J00000aa4G9

IMPORTANT: I wasn't able to set the real dates of the audits in the form given that they were from before 2017. Could you please set the right dates in the case before your revision?. 

Looking forward to your comments on these cases. 

As for the 2018 audits, our plan is to create the case for them by the end of June. 

Thank you,
Flags: needinfo?(fferre)
(In reply to Francesc Ferrer from comment #30)
> Dear Kathleen, 
> 
> First of all, sorry for the delay in creating the Cases in the CCADB after
> providing the audits in this bug weeks ago. 
> 
> These are the audit cases created sent for your revision:
> 
> - WT CA+BR+EV from 21st december 2015 to 20th december 2016 : case #00264
> https://ccadb.force.com/5001J00000aa4AG
> - WT CA+BR+EV from 21st december 2016 to 18th june 2017 : case #00265
> https://ccadb.force.com/5001J00000aa4G9
> 
> IMPORTANT: I wasn't able to set the real dates of the audits in the form
> given that they were from before 2017. Could you please set the right dates
> in the case before your revision?. 


Done and processed.

Please make sure the test websites work (intermediate cert served up with the SSL cert) before submitting the Audit Case for the 2018 audits.


> 
> Looking forward to your comments on these cases. 
> 
> As for the 2018 audits, our plan is to create the case for them by the end
> of June. 
>
Whiteboard: [ca-compliance] → [ca-compliance] - Next update 30-June-2018
Francesc: thank you for supplying these documents. Please ask your Auditor to provide ENglish language versions as required by Mozilla policy section 3.1.4

Also, these reports indicate that the end of the audit period was 28-March 2018. Mozilla policy section 3.1.3 requires that reports be submitted within three months of the end of the period. Please explain why Mozilla should create an exception for these reports?
Flags: needinfo?(fferre)
I added the following Case Comment to the Audit Case in the CCADB:
~~
Created By: Kathleen Wilson (9/12/2018 2:19 PM)
1) Please explain why Mozilla should create an exception for receiving these audit reports more than 3 months after the audit period end date.
Audit Period End Date: March 28, 2018
Audit statements provided: September 12, 2018.
Reference:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#313-audit-parameters
"Audit reports ... MUST be provided to Mozilla via the CCADB within three months of ... the end date of the period."

2) Please have your auditor provide audit statements such that there are no gaps between the audit period of the previous audit and the audit period of the new audit.
Audit Period Start Date: 6/26/2017
Previous Audit Period End Date: 6/18/2017
Reference:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#313-audit-parameters
"Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually. Successive audits MUST be contiguous (no gaps)."

3) Please have your auditor issue audit statements that meet all of Mozilla's requirements as stated here:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#314-public-audit-information
~~
(In reply to Kathleen Wilson from comment #35)
> I added the following Case Comment to the Audit Case in the CCADB:
> ~~
> Created By: Kathleen Wilson (9/12/2018 2:19 PM)
> 1) Please explain why Mozilla should create an exception for receiving these
> audit reports more than 3 months after the audit period end date.
> Audit Period End Date: March 28, 2018
> Audit statements provided: September 12, 2018.
> Reference:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> policy#313-audit-parameters
> "Audit reports ... MUST be provided to Mozilla via the CCADB within three
> months of ... the end date of the period."
> 

Although the requirement is quite clear, we had been told that we had to send the report within three months after the end of the previous period (plus a year). The previous period ended on June 18th so we understood that we could send the report until the 18th of September.
Additionally, we received the draft report on July the 27th (more than three months after the March 28, 2018) and we had some doubts that were solved during holidays.

> 2) Please have your auditor provide audit statements such that there are no
> gaps between the audit period of the previous audit and the audit period of
> the new audit.
> Audit Period Start Date: 6/26/2017
> Previous Audit Period End Date: 6/18/2017
> Reference:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> policy#313-audit-parameters
> "Full-surveillance period-of-time audits MUST be conducted and updated audit
> information provided no less frequently than annually. Successive audits
> MUST be contiguous (no gaps)."
> 

After conversations with the auditors, an error in dates has been identified, since the first draft of the first audit report (issued in 2017) had the right dates, the final version added a week, and the mistake was propagated to this year's audit statement.
Auditors are going to issue new audit statement, urgently so we think that we will be able to send the Spanish version by the end of next week.
Apologies for the inconveniences.


> 3) Please have your auditor issue audit statements that meet all of
> Mozilla's requirements as stated here:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> policy#314-public-audit-information
> ~~

After doing a checkup with auditors, the audit statement meet Mozilla's requirements except "SHA256 fingerprint of each root". Instead, there is the SHA1 fingerprint, pursuant what ENAC (Entidad Nacional de Acreditación, Spanish National Entity of Accreditation, the one that audits and appoints Conformity Assessment Body -CAB-)approved for Spanish CAB's. Nevertheless, the inclusion of SHA256 fingerprint is under discussion with ENAC and the next year, the audit statement will contain the SHA256 fingerprint, pursuing Section 4.3 ETSI TS 119 403-2.
(In reply to Francesc Ferrer from comment #36)
> (In reply to Kathleen Wilson from comment #35)
> > I added the following Case Comment to the Audit Case in the CCADB:
> > ~~
> > Created By: Kathleen Wilson (9/12/2018 2:19 PM)
> > 1) Please explain why Mozilla should create an exception for receiving these
> > audit reports more than 3 months after the audit period end date.
> > Audit Period End Date: March 28, 2018
> > Audit statements provided: September 12, 2018.
> > Reference:
> > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> > policy#313-audit-parameters
> > "Audit reports ... MUST be provided to Mozilla via the CCADB within three
> > months of ... the end date of the period."
> > 
> 
> Although the requirement is quite clear, we had been told that we had to
> send the report within three months after the end of the previous period
> (plus a year). The previous period ended on June 18th so we understood that
> we could send the report until the 18th of September.


That was under the assumption that the audit period for the new audit statements would be for 1 year.

Why is the audit period only 9 months this time?



> Additionally, we received the draft report on July the 27th (more than three
> months after the March 28, 2018) and we had some doubts that were solved
> during holidays.


Why did your auditor take so long to get you the draft report?


> 
> > 2) Please have your auditor provide audit statements such that there are no
> > gaps between the audit period of the previous audit and the audit period of
> > the new audit.
> > Audit Period Start Date: 6/26/2017
> > Previous Audit Period End Date: 6/18/2017
> > Reference:
> > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> > policy#313-audit-parameters
> > "Full-surveillance period-of-time audits MUST be conducted and updated audit
> > information provided no less frequently than annually. Successive audits
> > MUST be contiguous (no gaps)."
> > 
> 
> After conversations with the auditors, an error in dates has been
> identified, since the first draft of the first audit report (issued in 2017)
> had the right dates, the final version added a week, and the mistake was
> propagated to this year's audit statement.
> Auditors are going to issue new audit statement, urgently so we think that
> we will be able to send the Spanish version by the end of next week.
> Apologies for the inconveniences.
> 
> 
> > 3) Please have your auditor issue audit statements that meet all of
> > Mozilla's requirements as stated here:
> > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> > policy#314-public-audit-information
> > ~~
> 
> After doing a checkup with auditors, the audit statement meet Mozilla's
> requirements except "SHA256 fingerprint of each root". Instead, there is the
> SHA1 fingerprint, pursuant what ENAC (Entidad Nacional de Acreditación,
> Spanish National Entity of Accreditation, the one that audits and appoints
> Conformity Assessment Body -CAB-)approved for Spanish CAB's. Nevertheless,
> the inclusion of SHA256 fingerprint is under discussion with ENAC and the
> next year, the audit statement will contain the SHA256 fingerprint, pursuing
> Section 4.3 ETSI TS 119 403-2.


Also:
+ the date the report was issued
+ An authoritative English language version of the publicly-available audit information MUST be supplied by the Auditor.
(In reply to Francesc Ferrer from comment #36)
> > 3) Please have your auditor issue audit statements that meet all of
> > Mozilla's requirements as stated here:
> > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> > policy#314-public-audit-information
> > ~~
> 
> After doing a checkup with auditors, the audit statement meet Mozilla's
> requirements except "SHA256 fingerprint of each root". Instead, there is the
> SHA1 fingerprint, pursuant what ENAC (Entidad Nacional de Acreditación,
> Spanish National Entity of Accreditation, the one that audits and appoints
> Conformity Assessment Body -CAB-)approved for Spanish CAB's. Nevertheless,
> the inclusion of SHA256 fingerprint is under discussion with ENAC and the
> next year, the audit statement will contain the SHA256 fingerprint, pursuing
> Section 4.3 ETSI TS 119 403-2.

This is most concerning to me, and I would like to suggest that if this is accepted as resolved, there are several things to consider:

- If we expect the CA to be responsible for ensuring audit letters meet the necessary requirements, then waiting a year, for the next audit, to resolve this issue suggests that CAs don’t actually need to be responsible. This would be a dangerous precedent to set, as it would mean that new requirements couldn’t be guaranteed for up to 23 months (depending on when the new requirements are introduced). Requiring that Consorci AOC produce a new audit before resolution is one way to ensure that CAs are appropriately responsible for ensuring audit letters comply.
- If we say that the auditor is responsible - in this case, because it is suggested that ENAC must approve before the auditor can comply - then we’re also abdicating assurance that the information will be present. For example, if Mozilla were to start requiring CAs disclose nonconformities during the period of evaluation in the report, or requiring auditors to, organizations like ENAC could block such additions or be used to delay including such information. If the auditor is responsible, then choosing an audit scheme subject to ENAC’s approval is insufficient for recognition by Mozilla, and the auditor needs to ensure the schemes they offer are ones that can comply. Similarly, I think a note should be added for the current auditor for not having started those conversations sooner and not having already addressed them.

I just find it deeply troublesome to use ENAC as a potential explanation for the non-compliance. Either the CA or the auditor is responsible, and the resolution for this issue should reflect that.
(In reply to Kathleen Wilson from comment #37)
> (In reply to Francesc Ferrer from comment #36)
> > (In reply to Kathleen Wilson from comment #35)
> > > I added the following Case Comment to the Audit Case in the CCADB:
> > > ~~
> > > Created By: Kathleen Wilson (9/12/2018 2:19 PM)
> > > 1) Please explain why Mozilla should create an exception for receiving these
> > > audit reports more than 3 months after the audit period end date.
> > > Audit Period End Date: March 28, 2018
> > > Audit statements provided: September 12, 2018.
> > > Reference:
> > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> > > policy#313-audit-parameters
> > > "Audit reports ... MUST be provided to Mozilla via the CCADB within three
> > > months of ... the end date of the period."
> > > 
> > 
> > Although the requirement is quite clear, we had been told that we had to
> > send the report within three months after the end of the previous period
> > (plus a year). The previous period ended on June 18th so we understood that
> > we could send the report until the 18th of September.
> 
> 
> That was under the assumption that the audit period for the new audit
> statements would be for 1 year.

Yes. This was our mistake.

> 
> Why is the audit period only 9 months this time?
> 
> 

Before EIDAS, we performed WebTrust audits, with its own periods of an entire year. When eIDAS came into force, we performed the eIDAS audit, when we were ready (eIDAS audit covers much more than just SSL and SSL EV certificates, in our case, natural person electronic signature and legal person electronic seal) and the periods did not match the WebTrust ones. In fact, last year we tried to use the eIDAS audit instead of the WebTrust, but taking into account that was the first eIDAS audit with the ETSI approach it was a Point-of-Time audit, so we had to perform the corresponding WebTrust audit. 

This year we audited from the end period of the last WebTrust audit, until the moment on the eIDAS audit had to be performed.

Next year the audit will be again of an entire year, from March to March, and it is very clear for us the periods for making the audit report publicly available.



> 
> > Additionally, we received the draft report on July the 27th (more than three
> > months after the March 28, 2018) and we had some doubts that were solved
> > during holidays.
> 
> 
> Why did your auditor take so long to get you the draft report?
> 

We are now and the following days working very closely with auditors to find what the problem was.

> 
> > 
> > > 2) Please have your auditor provide audit statements such that there are no
> > > gaps between the audit period of the previous audit and the audit period of
> > > the new audit.
> > > Audit Period Start Date: 6/26/2017
> > > Previous Audit Period End Date: 6/18/2017
> > > Reference:
> > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> > > policy#313-audit-parameters
> > > "Full-surveillance period-of-time audits MUST be conducted and updated audit
> > > information provided no less frequently than annually. Successive audits
> > > MUST be contiguous (no gaps)."
> > > 
> > 
> > After conversations with the auditors, an error in dates has been
> > identified, since the first draft of the first audit report (issued in 2017)
> > had the right dates, the final version added a week, and the mistake was
> > propagated to this year's audit statement.
> > Auditors are going to issue new audit statement, urgently so we think that
> > we will be able to send the Spanish version by the end of next week.
> > Apologies for the inconveniences.
> > 
> > 
> > > 3) Please have your auditor issue audit statements that meet all of
> > > Mozilla's requirements as stated here:
> > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> > > policy#314-public-audit-information
> > > ~~
> > 
> > After doing a checkup with auditors, the audit statement meet Mozilla's
> > requirements except "SHA256 fingerprint of each root". Instead, there is the
> > SHA1 fingerprint, pursuant what ENAC (Entidad Nacional de Acreditación,
> > Spanish National Entity of Accreditation, the one that audits and appoints
> > Conformity Assessment Body -CAB-)approved for Spanish CAB's. Nevertheless,
> > the inclusion of SHA256 fingerprint is under discussion with ENAC and the
> > next year, the audit statement will contain the SHA256 fingerprint, pursuing
> > Section 4.3 ETSI TS 119 403-2.
> 
> 
> Also:
> + the date the report was issued

This information is going to be added in the new report version that our auditor is going to issue soon. 

> + An authoritative English language version of the publicly-available audit
> information MUST be supplied by the Auditor.

Yes, we already knew this but since we had the final version very late and we still have to do the sworn translation, we preferred to upload the Spanish version while the translation is being done. 

We propose to stop the translation since auditors have to issue a new report amending the issues.


(In reply to Ryan Sleevi from comment #38)
> (In reply to Francesc Ferrer from comment #36)
> > > 3) Please have your auditor issue audit statements that meet all of
> > > Mozilla's requirements as stated here:
> > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> > > policy#314-public-audit-information
> > > ~~
> > 
> > After doing a checkup with auditors, the audit statement meet Mozilla's
> > requirements except "SHA256 fingerprint of each root". Instead, there is the
> > SHA1 fingerprint, pursuant what ENAC (Entidad Nacional de Acreditación,
> > Spanish National Entity of Accreditation, the one that audits and appoints
> > Conformity Assessment Body -CAB-)approved for Spanish CAB's. Nevertheless,
> > the inclusion of SHA256 fingerprint is under discussion with ENAC and the
> > next year, the audit statement will contain the SHA256 fingerprint, pursuing
> > Section 4.3 ETSI TS 119 403-2.
> 
> This is most concerning to me, and I would like to suggest that if this is
> accepted as resolved, there are several things to consider:
> 
> - If we expect the CA to be responsible for ensuring audit letters meet the
> necessary requirements, then waiting a year, for the next audit, to resolve
> this issue suggests that CAs don’t actually need to be responsible. This
> would be a dangerous precedent to set, as it would mean that new
> requirements couldn’t be guaranteed for up to 23 months (depending on when
> the new requirements are introduced). Requiring that Consorci AOC produce a
> new audit before resolution is one way to ensure that CAs are appropriately
> responsible for ensuring audit letters comply.

We agree and we are now and the following days working very closely with auditors to issue a new report solving the arisen issues.


> - If we say that the auditor is responsible - in this case, because it is
> suggested that ENAC must approve before the auditor can comply - then we’re
> also abdicating assurance that the information will be present. For example,
> if Mozilla were to start requiring CAs disclose nonconformities during the
> period of evaluation in the report, or requiring auditors to, organizations
> like ENAC could block such additions or be used to delay including such
> information. If the auditor is responsible, then choosing an audit scheme
> subject to ENAC’s approval is insufficient for recognition by Mozilla, and
> the auditor needs to ensure the schemes they offer are ones that can comply.
> Similarly, I think a note should be added for the current auditor for not
> having started those conversations sooner and not having already addressed
> them.
> 

Again, we agree and our and auditors' aim is to solve the arisen issues within the following days.
Francesc, Please provide an update in this bug.
Whiteboard: [ca-compliance] - Next update 30-June-2018 → [ca-compliance] - Next update 30-Sept-2018
Dear all, 

We will attach the new reports to this bug next Monday. 

Sorry for the inconvenience,
New and digitally signed original for QCPW.
Attachment #9008377 - Attachment is obsolete: true
English sworn translation of the QCPW audit.
New and digitally signed original for OV.
Attachment #9008376 - Attachment is obsolete: true
English sworn translation of the OV audit.
Dear All, 

Please find attached new versions of the reports fixing the issues identified. Apologies for the inconvenience. Now it is absolutely clear for us and the auditors the deadlines and requirements on the report and also the dates of the audits are already align, after the period of adaptation from WebTrust to ETSI/eIDAS audits: 

- 2018 AENOR Anexo 1 ETSI al certificado PSC-20170002 - CAOC-corregido.pdf : New and digitally signed original for QCPW. 
- 2018 AENOR Anexo 1 ETSI al certificado PSC-20170002 - CAOC-EN-Traduccion_jurada.pdf : English sworn translation of the QCPW audit.
- 2018 AENOR Anexo 2 ETSI al certificado PSC-20170002 - CAOC-corregido.pdf : New and digitally signed original for OV. 
- 2018 AENOR Anexo 2 ETSI al certificado PSC-20170002 - CAOC-EN-Traduccion_jurada.pdf : English sworn translation of the OV audit.


I have also uploaded them into the existing 2018 case for your revision: https://ccadb.force.com/5001J00000bvPRp

Thank you, 

Francesc,
Flags: needinfo?(fferre)
The new audit reports result in a gap in audit coverage from 12/20/2016 to 6/18/2017. No further remediation is possible for the gap, so I am closing this incident.

Refer to bug #1496616 for information regarding exceptions noted in these audit reports.
Status: UNCONFIRMED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Whiteboard: [ca-compliance] - Next update 30-Sept-2018 → [ca-compliance]
You need to log in before you can comment on or make changes to this bug.