Closed Bug 1544586 Opened 5 years ago Closed 5 years ago

FNMT: Findings in 2019 Audit Statement, including domain validation methods, CAA, etc.

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: alain)

Details

(Whiteboard: [ca-compliance] [uncategorized])

This bug is to track resolution to the items that were identified as "findings" in this CA's 2019 audit statement.

~~
Audit statement:
https://bug435736.bmoattachments.org/attachment.cgi?id=9057798

#1 We have identified evidence in the sample of the web authentication certificates issued by "AC Administración Pública" and "AC Componentes Informáticos", cases in which the ownership of the domain is not adequately checked according to the methods established in section 3.2.2 of BRG. It should be noted that methods not allowed in the applicable CPS are included.
Likewise, for the certificates of public organizations, the verified information is relied upon when registering the organization but there are not enough controls in place to ensure that the data or documents used to verify certificate information are not older than 825 days.
Finally, it should be noted that it has not been possible to find evidence that CAA records are being checked for all issued web authentication certificates.

#2 In the case of OVCP certificates issued by "AC Administración Pública" and "AC Componentes Informáticos", although the suspension of web authentication certificates according to CPs is not allowed, the suspension of other types of certificates issued by these subordinates is allowed according to CPs. It has been verified that suspended certificates are included in the CRLs of these subordinates and, therefore, is not compliant with section 4.9.13 of the BRGs.

#3 We could not find evidence of the formal definition and assignment of the validation specialist profile, as specified in BRG, even though there are individuals performing the validation functions as a matter of course.
In addition, we could not find evidence that the personnel that are currently performing the functions of validation specialist have received specific training during the audit period.

#4 The incidents that have an impact on the availability of the services are not classified as security incidents and, as a result, they do not follow the same management and notification processes as the rest of the security incidents.

#5 -- Bug #1495507 already has the incident report for this item (organizationName or organizationUnitName bigger than 64 characters), so do not need to discuss it here. --

#6 Although follow-up and actions are performed aimed at improving the level of compliance of the public website with regards to accessibility standards, aspects of improvement have been identified for the compliance with WCAG 2.0 level AA of accessibility for people with disabilities in the websites requesting certificates.

#7 We have not been able to find evidence of the availability of test sites for the new hierarchy "AC RAIZ FNMT-RCM SERVIDORES SEGUROS".
~~

Rafa, please do the following as soon as possible:

  1. Provide further explanation about item #1, such as which methods of domain validation were being used that were not documented in the CP/CPS? And what is currently being done in regards to CAA?

  2. Provide a timeline for when each of these items will be resolved.

  3. Provide an Incident Report for these areas of non-compliance.
    https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Assignee: wthayer → rafamdn
Flags: needinfo?(rafamdn)
Whiteboard: [ca-compliance]

Hello, Kathleen.
I’m working for FNMT and I’m answering about this bug because I’m in charge of these matters now.

I’m answering about the “cases in which the ownership of the domain is not adequately checked according to the methods established in section 3.2.2 of BRG, and that methods not allowed in the applicable CPS are included” topic. We think that this is the most important topic. I propose to answer about the rest of topics the next week (unless it is necessary).

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.

FNMT became aware of the problem via the periodic Audit. This Audit was carried out between January 21st, 2019 and February 6th, 2019, with additional checks performed until March 26th 2019. https://www.aenor.com/certificacion/tecnologias-de-la-informacion/prestadores-servicios-confianza/organizaciones-certificadas-en-eidas

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

February 8th: In the meeting about the results of the Audit, we were informed that the “3.2.2.4.1 Validating the Applicant as a Domain Contact” method was not allowed since august 2018. We knowed this situation, so we were using this method complementarily with other methods, as the previous versión ofDPC expressed: 3.2.2.4.1, 3.2.2.4.2 and/or 3.2.2.4.3.
However, some evidences of the 3.2.2.4.2 or 3.2.2.4.3 methods were not stored in the registry proccess of some issued certificates.
In order to avoid this problem, we decided eliminate the 3.2.2.4.1 as complementary method, to approve new validation methods and to strengthen the evidence registration process of the aproved methods.
So, the registry procedures and DPC were updated in order to stop using the method 3.2.2.4.1, even as complementary method.

March 5th: FNMT approved and put into practices new methods, as the new version of DPC express: “
In order to validate the domain of the Certificate for website authentication, the FNMT-RCM uses one of the following methods described in the CA/Browser Forum's Baseline Requirements document: “3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact”, “3.2.2.4.3 Phone Contact with Domain Contact”, “3.2.2.4.4 Constructed Email to Domain Contact” or “3.2.2.4.6 Agreed-Upon Change to Website”.
The new versions of CPS (General DPC v5.4, Administracion Publica v3.3 and Componentes DPC v1.8) were approved on March 5th, although they have not been published until today. So, new validation methods have been incorporated to theses CPS (3.2.2.4.4 and 3.2.2.4.6).

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.

Really, FNMT only uses the validation methods included in the DPC version approved on March 5th and all the evidence registration process of the aproved methods are stored.

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.

We are analyzing if there are still active certificates that have been issued between August 1st 2018 and March 5th 2019, using the complementary method 3.2.2.4.1 and we have not stored evidence about the use of the other methods contemplated in the previous DPC version (3.2.2.4.2 and 3.2.2.4.3).

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.

We are analyzing what certificates have been issued between August 1st 2018 and March 5th 2019, using the complementary method 3.2.2.4.1 and we have not stored evidence about the use of the other methods contemplated in the previous DPC version (3.2.2.4.2 and 3.2.2.4.3).

6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
After the invalidation of the 3.2.2.4.1 method we incorporated other validation methods according to the baseline requirements in order to complement these practices.

However, the registry proccess that implemented these new methods did not store enough evidences in all of cases. This problem was detected by the Audit process on February.
The problem was not that FNMT use exlusively validation methods that have been deprecated. The problem was really that in some cases there was not enough evidence of use of any of the validation method, because any of those evidences were not beeing stored. But the registry procces included el use of valid methods in all of cases.
So, we have improved the procedure of accumulation of evidence in order to guarantee compliance with the requirements.

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 3.2.2.4.1 complementary validation method has been eliminated of our practices.
New validation methods have been aproved.
We have estrengthned the evidence registration process of the aproved methods.
Registry procedures and DPC have been updated in order to stop using the method 3.2.2.4.1, even as complementary method.
At present, we use new registy procedures that store enough evidences about the validation method used.

We will update the information of this bug with the additional information in order to answer all the topics.

Alain: thank you for this information. I will look forward to your update next week.

Assignee: rafamdn → alain
Flags: needinfo?(rafamdn) → needinfo?(alain)
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 23-April 2019

As a continuation of the previous information, I provide the following information:

In regards the following finding: topic #1 “Likewise, for the certificates of public organizations, the verified information is relied upon when registering the organization but there are not enough controls in place to ensure that the data or documents used to verify certificate information are not older than 825 days.
Finally, it should be noted that it has not been possible to find evidence that CAA records are being checked for all issued web authentication certificates.” Please find herewith the required 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.

During the on-site audit, which took place during the first week of February, we were informed that we should implement additional controls to ensure that the information collected during the registry process of the public organizations in our infrastructure is not older than 825 days and to improve the related custody management of evidences.
In regards the CAA records, during the on-site audit, the additional CAA record control implemented in the request application for “CA Servidores Seguros”, which is not yet issuing certificates, failed and evidences could not be collected at this stage. (Please be informed that “CA Servidores Seguros” has two CAA records controls implemented, one at the application request phase and the other at the issuance CA software, prior to the issuance of any certificate.)

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.

A new version of the internal procedure for the validation of website authentication certificates was approved on March 5th, in order to improve the custody management of evidences collected and that we do not use any information of our infrastructure older than 825 days for the validating process.
The FNMT implemented the CAA checking controls for all the CAs issuing website authentication certificates within the CA software prior to the issuance (DnsCaaEvent). These controls were implemented and operative for the expedition of any certificate issued by “CA Administración Pública” and “CA Componentes Informáticos” in May 2017. For the “CA Servidores Seguros” this control was implemented in its creation in December 2018 (This new hierarchy has not been yet communicated to the CCADB and its not issuing certificates yet).
In addition to the already implemented controls in the CA software, we implemented CAA checking controls within the Requests Applications for the certificates issued by “CA Servidores Seguros”. These additional controls aim to improve the user experience and avoid efforts for non-compliant requests.
The bug in the Request Application for certificates of “CA Servidores Seguros” was solved on January 28th.

  1. 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 information concerning the registered organization in our infrastructure is always revalidated against official public records, and accordingly updated when necessary. Any certificate is issued in accordance with the new measures adopted.
We have stopped issuing certificates with the problem.

  1. 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 no certificates issued without CAA record checking.

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

There are no certificates issued without CAA record checking.

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

In regards the information older than 825 days, please note that the sole information that is validated against the records collected when registering a public organization is the applicant organization, in order to confirm that it is entitled to apply for such certificate.
There are two requirements to be met by a public entity in order to apply for a website authentication certificates issued by “AC Administración Pública”. 1 - to be previously registered in our infrastructure and 2 – to have a signed contract in force that expressly indicate the number of website authentication certificates that is entitle to apply for.
In addition, the subscribers are obligated and responsible for communicating in time any change of the information requested for the registry process in our infrastructure, by forwarding the related signed form. Upon reception of this communications, and following the internal validation procedure, our registry officers validate the updated information upon the public official records.
Once it is confirmed that the applicant organization is entitled to request such certificate, a request application form, duly completed and signed, shall be forwarded to the FNMT registry office. All the information in the application form related to the certificate, is always validated following the approved procedures and in conformity to the BRs.
We considered that these controls were sufficient for all cases, since there is always an application form to be validated for each certificate. Nevertheless, in some cases there were no enough evidences saved in order to prove the exact moment in time in which those verifications were made.
In regards de CAA checking, the finding refers to the failure of the additional control implemented in the Request Application for “CA Servidores Seguros”, not to the CAA checking implemented prior to the issuance within the CA software.

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

We have strengthened the evidence registration process by implementing custody management solutions with date and time records.
A new version of the internal procedure for the validation of website authentication certificates was approved on March 5th
The bug in the Request Application for certificates of “CA Servidores Seguros” was solved on January 28th.

Flags: needinfo?(alain)

Regarding to topic #2: In the case of OVCP certificates issued by "AC Administración Pública" and "AC Componentes Informáticos", although the suspension of web authentication certificates according to CPs is not allowed, the suspension of other types of certificates issued by these subordinates is allowed according to CPs. It has been verified that suspended certificates are included in the CRLs of these subordinates and, therefore, is not compliant with section 4.9.13 of the BRGs.

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.

FNMT became aware of the problem via the periodic Audit. This Audit was carried out between January 21st, 2019 and February 6th, 2019, with additional checks performed until March 26th 2019. https://www.aenor.com/certificacion/tecnologias-de-la-informacion/prestadores-servicios-confianza/organizaciones-certificadas-en-eidas

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

February 8th: During the meeting about the results of the Audit, we were informed that the requirement about the publication in revocation list of the suspended certificates affects also to the signature certificates.
In order to avoid this problem, we decided to eliminate the suspension practices for all type of certificates because the number of suspended certificates was almost nil. In fact, only five out of six million active certificates were published as suspended in that moment.
March 2019: the suspension practices have been eliminated (and the changes have been incorporated into the related CPS).
April 13th: Suspended certificates don’t exist anymore.

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

We have stopped issuing certificates with the problem. .

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.

There were five suspended signature certificates of natural person. All of them have been revoked. This problem does not affect directly to website certificates issued.

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

This problem does not affect directly to website certificates issued.

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

Our interpretation about this requirement was that it affected only to suspended website certificates, but not to signature certificates

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 suspension practices have been eliminated (and the changes have been incorporated into the CPS).
It has been verified that there are no more suspended certificates.

Regarding to the rest of the topics that they don’t have direct relation with issuing website certificates, we consider that they can be explained as follows:

Topic #3 We could not find evidence of the formal definition and assignment of the validation specialist profile, as specified in BRG, even though there are individuals performing the validation functions as a matter of course.
In addition, we could not find evidence that the personnel that are currently performing the functions of validation specialist have received specific training during the audit period.

Personnel performing the validation functions have enough experience with these procedures and they have received the necessary training. However, there is no evidence about that the training received. Further evidences will be registered for the next annual training course. Additionally, specialist profile has been defined and they are being assigned by HR management.

Topic #4 The incidents that have an impact on the availability of the services are not classified as security incidents and, as a result, they do not follow the same management and notification processes as the rest of the security incidents.

The document that describes the management of security incidents is being updated so that availability of the services follow the same management and notification processes as the security incidents.

Topic #6 Although follow-up and actions are performed aimed at improving the level of compliance of the public website with regards to accessibility standards, aspects of improvement have been identified for the compliance with WCAG 2.0 level AA of accessibility for people with disabilities in the websites requesting certificates.

We have made an analysis of the required actions in order to improve the level of compliance of the public website with regards to accessibility standards. Specific personnel for developing this activity are being hired and we hope to solve this topic by September.

Topic #7 We have not been able to find evidence of the availability of test sites for the new hierarchy "AC RAIZ FNMT-RCM SERVIDORES SEGUROS".

This new hierarchy (AC RAIZ FNMT-RCM SERVIDORES SEGUROS) still has not been communicated to CCADB (we will do it in the next days) and, of course, it is still not issuing certificates.
We will make available the test sites when communicating this new hierarchy to CCADB.

Additionally, we are in contact with the Auditor team in order to comply the corrective action plan. We are sending the evidences of the developed measures to them as planned.

Alain: thank you for providing this information.

Our interpretation about this requirement was that it affected only to suspended website certificates, but not to signature certificates

I am concerned about this statement. The Mozilla Root Store policy [1] makes it clear that any certificates that are technically capable of being used for TLS are in scope, and that BR compliance is required. Has FNMT reviewed all policies to ensure compliance with Mozilla policies and the BRs, regardless of the intended usage of the certificate?

[1] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Status: NEW → ASSIGNED
Whiteboard: [ca-compliance] - Next Update - 23-April 2019 → [ca-compliance]

Dear Wayne,
We are sorry for this misunderstanding. Effectively, it was a not very appropriate statement…
Please be assured that the FNMT is aware of the Mozilla Root Store policy to comply with all policies and BRs for all certificates.

The document that describes the management of security incidents is being updated so that availability of the services follow the same management and notification processes as the security incidents.

Alain: has this update been completed?

Flags: needinfo?(alain)

(In reply to undefined from comment #undefined)

Yes, we have updated the document regarding the security incident management procedure, to indicate the way we had been managing the alerts on the availability of services as security incidents. Evidence of this update has been sent to the audit team.

In regards the certificates for which the evidences concerning the ownership of the domain were not adequately kept (topic #1), we inform you that the certificates affected amounts to 20 and that we are revalidating each of them in order to keep full evidences in our files.

Flags: needinfo?(alain)

Alain: please update this bug when the revalidation of the 20 certificates noted in topic #1 has been completed. Please include details of any certificate that could not be revalidated.

Flags: needinfo?(alain)

Today we have been able to complete the revalidation for all the 20 certificates afected and evidences have been filed accordingly.

Flags: needinfo?(alain)

Can you please provide the 20 certificates? Comment #0 merely indicated that you did not yet know the scope, and Comment #9 did not provide the list (e.g. crt.sh IDs)

Flags: needinfo?(alain)
Flags: needinfo?(wthayer)

It appears that all questions have been answered and remediation is complete.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
Product: NSS → CA Program
Summary: Government of Spain FNMT: Findings in 2019 Audit Statement, including domain validation methods, CAA, etc. → FNMT: Findings in 2019 Audit Statement, including domain validation methods, CAA, etc.
Whiteboard: [ca-compliance] → [ca-compliance] [uncategorized]
You need to log in before you can comment on or make changes to this bug.