1693304 - FNMT: Issuance of QCP-n certificates without verifying identity

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[alain]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Comment 1

[alain]

Attachment: List of affected certificates.pdf

Comment 2

[alain]

In representation of FNMT - RCM, as a qualified provider of trust services, we inform you of an incident related to the process of issuing some “Certificate of Representatives of Legal Entities" by AC Representación.
The said incident does not imply a violation of security or loss of integrity with a significant impact on the certificate issuance service.
However, we consider it appropriate to report the incident identified, as well as the actions taken to resolve it.
Brief context description:
Due to the exceptional security and health surveillance measures caused by COVID-19, the public service offices of the AEAT (Spanish Tax Administration Agency), where one of the activities provided consists of the accreditation of the identity by physical presence of natural persons and other attributes of the applicants for certificates issued by the FNMT-RCM, have not been able to recover the rhythm of attention prior to their closure, due to the state of alarm.
The exponential accumulation of pending applications within AEAT Registry Offices began to cause great impact to the Spanish Electronic Administration and to citizens. To mitigate the effects of confinement and alleviate the pressure on the aforementioned registry office, both Entities decided to enable a procedure that would allow the accreditation of the identity of the subscribers through the use of the QCP-n certificate for citizens issued by AC FNMT Usuarios.
New AC Representación CPS (version 1.8) is approved and published on 18/08/2020 to support the new practice and on September 15th, the new procedure is enabled allowing to request the issuance of a “Certificate of Representatives of Legal Entities” issued by AC Representacion, by authenticating the applicant by means of his/her QCP-n certificate.
This procedure was implemented within the electronic office (official web site) of the AEAT (FNMT registration authority) where in addition to providing the request code obtained through the FNMT’s web application, the subscriber shall sign electronically the request and provide the documentation required to prove their legal capacity representation.
This possibility is offered only when the VAT number of the legal entities to be represented, begins with the letters A, B, C and D, since the AEAT, prior to the issuance of the certificate, performs the validation of the documentation received by consulting the corresponding official records (validation which is only available for these entities).

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.
On February the 4th, during the annual audit which took place from January 25th to February 5th, we realised that the related procedure, could not be guaranteeing in all cases compliance with article 7.6 of Spanish law 6/2020. (This article allows the use of a QCP-n for identification in the request for a new certificate, as long as the period of time elapsed since the physical identification of said means of identification was less than five years).
The control to determine whether the electronic certificate that serves as a means of identification was compliant to the said requirement, was not running correctly.

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.
• September 15th, 2020: New procedure is implemented the AEAT electronic office (official web site.
• February 4th, 2021 15:00 CET - The FNMT TSP Management Committee decides to suspend the certificate issuance service under this procedure until the reasons that have generated the possible non-compliance are found and resolved.
• February 4th, 2021 15:30 CET - The FNMT TSP Management Committee contacts the AEAT to inform about the detected incidence and request the withdrawal of the related procedure until the facts are clarified. It is also requested, complete information of the certificate applications that have been registered through the said procedure.
• February 4th, 2021 16:28 CET – We received confirmation from the AEAT Tax Informatics Department that the procedure has been effectively disabled.
• February 8th, 2021- Analysis and redesign of the required controls.
• February 9th, 2021 10:33 CET – AEAT send us complete information as requested. FNMT begins a one-by-one assessment process to identify which certificates have been issued by means of a QCP-n certificate identification obtained without physical accreditation into a 5 years period.
• February 10th, 2021 - Testing of the required controls.
• February 15th, 2021 - The analysis of the certificates issued is completed and it is determined that number of certificates affected amounts to 139.
• February 15th, 2021 12:34:15 CET – All the 139 “Certificate of Representatives of Legal Entities” have been revoked and subscribes notified. First certificate revocation: February 15th, 2021 10:59, last certificate revocation: February 15th, 2021 12:02.
• February 15th, 2021 14:30:00 CET – Services are re-activated with full compliance guarantees.

3. Whether your CA has stopped, or has not yet stopped, certificate issuance or the process giving rise to the problem or incident. A statement that you have stopped will be considered a pledge to the community; a statement that you have not stopped requires an explanation.
Yes, on February 4th, 2021 16:28 CET the procedure was disabled. It has been re-activated on February 15th once the necessary controls had been satisfactory implemented and proven.

4. In a case involving certificates, a summary of the problematic certificates. For each problem: the number of certificates, and the date the first and last certificates with that problem were issued. In other incidents that do not involve enumerating the affected certificates (e.g. OCSP failures, audit findings, delayed responses, etc.), please provide other similar statistics, aggregates, and a summary for each type of problem identified. This will help us measure the severity of each problem.
• Total number of affected certificates: 139
• Date of first affected certificate issued: 30/10/2020 10:49:46
• Date of last affected certificate issued: 04/02/2021 12:43:30

5. In a case involving certificates, 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. In other cases not involving a review of affected certificates, please provide other similar, relevant specifics, if any.
Since all the affected certificates are QCP- n “Certificate of Representatives of Legal Entities”, in order not to disclose the personal data of subscribers, instead of the crt.sh. IDs a, list of serial numbers and issuance dates for all 139 Certificates is attached.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The control that was originally established was not running correctly for all cases.
At the moment of authentication of the certificate’s applicant, the related control was not capable in all cases of calculating precisely the period of time elapsed between that moment and the date of the last physical accreditation of the subscriber's identity. This inaccuracy allowed the issuance of some certificates without full guarantees of having been requested with a QCP-n certificate obtained by means of physical accreditation of the subscriber within 5 years and making it difficult to detect the error.
Corrective measures have been established to guarantee that the issuance of all QCP-n Certificate of Representatives of Legal Entities by this procedure meet all the requirements needed. The procedure, controls the suitability of the certificate used in the applicant's identification process, during the review and validation phase of the required documentation, and rejecting requests that do not meet the requirement the said art 7.6

7. List of steps your CA is taking to resolve the situation and ensure that such situation or incident will not be repeated in the future, accompanied with a binding timeline of when your CA expects to accomplish each of these remediation steps.
Date: Action/Status:
04/02/2021: Suspension of service / Completed
04/02/2021: Review of the controls established in the procedure together with AEAT Tax Informatics Department / Completed
08/02/2021: Analysis and redesign of the established control and implementation. / Completed
09/02/2021: Collection of evidences and information for the certificates assessment. Certificate case by case compliance review. / Completed
10/02/2021: Testing of the required controls. / Completed
15/02/2021: Confirmation of the list of certificates that were not fully compliant. / Completed
15/02/2021: Revocation of all affected certificates. / Completed
15/02/2021: Certificate change status notification to subscribers. / Completed
15/02/2021: Reactivation of service guaranteeing compliance of art 7.6 Law 6/2020. / Completed
17/02/2021: Share and agree with AEAT Tax Informatics Department a common procedure for the establishment of controls and the batteries of test that shall be carried out in the event that new procedures shall be hosted in the AEAT’s website. / Completed

Comment 3

[Pedro Fuentes]

Hello,
can you please share details of the certificate profiles?
In particular, what are the EKUs on these certificates?
Thanks!

Comment 4

[alain]

Hi¡
Please find the link to the published certificate profiles (section 2.3): https://www.sede.fnmt.gob.es/documents/10445900/10575386/perfiles_certificados_ac_representacion.pdf
The affected FNMT's certificate OID is 1.3.6.1.4.1.5734.3.11.2 which has the following EKUs: email protection and client authentication.
Regards

Comment 5

[alain]

Hi¡
Please find the link to the published certificate profiles (section 2.3): https://www.sede.fnmt.gob.es/documents/10445900/10575386/perfiles_certificados_ac_representacion.pdf
The affected FNMT's certificate OID is 1.3.6.1.4.1.5734.3.11.2 which has the following EKUs: email protection and client authentication.
Regards

Comment 6

[Ryan Sleevi]

1. If this issue was detected on 2021-02-04, why was it not reported and disclosed until 2021-02-17?

2. From the description, it's unclear whether or not FNMT re-validated the organization information, or whether it simply relied upon the presence of the QCP-n. The part about the report that confuses me is this statement: "This possibility is offered only when the VAT number of the legal entities to be represented, begins with the letters A, B, C and D, since the AEAT, prior to the issuance of the certificate, performs the validation of the documentation received by consulting the corresponding official records (validation which is only available for these entities)."

Comment 7

[alain]

(In reply to Ryan Sleevi from comment #6)

1. If this issue was detected on 2021-02-04, why was it not reported and disclosed until 2021-02-17?

It is true that on 2021-02-04 we realized that something might not be working correctly and consequently, the first measure that was taken was to disable this procedure and start investigating.
It was not until 2021-02-09 when the potential incidence was fully diagnosed and the necessary corrective measures designed. Perhaps we should have reported at that precise moment, but we felt that we also had to be able to report and disclose precisely what had happened, if there were any certificates misissued and about the measures adopted to solve this problem and it never re-occur.

2. From the description, it's unclear whether or not FNMT re-validated the organization information, or whether it simply relied upon the presence of the QCP-n. The part about the report that confuses me is this statement: "This possibility is offered only when the VAT number of the legal entities to be represented, begins with the letters A, B, C and D, since the AEAT, prior to the issuance of the certificate, performs the validation of the documentation received by consulting the corresponding official records (validation which is only available for these entities)."
   The QCP-n certificate for this procedure is only used to prove the identity of the natural person applying for a QCP- n “Certificate of Representatives of Legal Entities” and signing the request together with the required documentation.

Once the identity of the applicant has been accredited, the RA (AEAT) performs the validations on the documentation received, the validation of the organization and the capacity of representation of the subscribers, checking all the information against official records.
These validations are always carried out following the procedures established for this purpose and keeping all the evidences for each of the certificates issued.
The incident detected did not affect at all to any of the validation processes in regards the organization. The 139 certificates had to be revoked because of the lack of full guarantee compliance of art. 7.6 law 6/2020 for the qcp-n certificate used as a means of authentication to request the QCP- n “Certificate of Representatives of Legal Entities”.
In relation to the statement you pointed out, it may indeed not have been clear enough.
This procedure is only enabled to issue QCP- n “Certificate of Representatives of Legal Entities” for subscribers representing legal entities whose VAT number begins with the letters A, B, C or D. These letters just identify a set of entities with a specific legal nature.
The related procedure was designed just for this group of entities, since only in these cases the RA (AEAT) is able to check online the information of the organization as well as the representation capability of the subscriber (whose identity is proven through his/her QCP-n), against the required official registry source (Registro Mercantil)
We hope we have been able to clarify the issue, it may be confusing.

Comment 8

[Ryan Sleevi]

It would sound like you're describing a flawed implementation of 3.2.5, then, is that correct?

Or are you saying that the implementation of 3.2.5 was sufficient (for the BRs), but insufficient for art. 7.6 law 6/2020?

Comment 9

[alain]

(In reply to Ryan Sleevi from comment #8)

It would sound like you're describing a flawed implementation of 3.2.5, then, is that correct?

Or are you saying that the implementation of 3.2.5 was sufficient (for the BRs), but insufficient for art. 7.6 law 6/2020?

Please be sure, the implementation is compliant with BRs.

All certificates issued by AC Representación complies 3.2.5 of BRs for which it is verified the authenticity of the Applicant Representative’s certificate request against an official registry source (Registro Mercantil). Only those natural persons registered in this official registry as legal representatives of a legal entity, are entitled to request a QCP-n “Certificate of Representatives”, and therefore the ones to whom these certificates are issued.

The issue deals with the implementation of art. 7.6 of Law 6/2020.

The related certificates also comply with ETSI EN 319 411-1 and ETSI EN 319 411-2 and in particular with REG-6.2.2-05 and REG-6.2.2-02 respectively: subject´s identity checked indirectly using means which provides equivalent assurance to physical presence. However art. 7.6 of Spanish Law 6/2020 restricts the use of a QCP-n certificate as one of these means, only to those for which it can be guaranteed that they were obtained with physical presence within the last 5 years.

In some cases, our original implementation could not guarantee compliance of this national requirement.

Comment 10

[Ryan Sleevi]

(In reply to alain from comment #9)

(In reply to Ryan Sleevi from comment #8)

It would sound like you're describing a flawed implementation of 3.2.5, then, is that correct?

Or are you saying that the implementation of 3.2.5 was sufficient (for the BRs), but insufficient for art. 7.6 law 6/2020?

Please be sure, the implementation is compliant with BRs.

Thanks for clarifying. It'd be useful to understand more how the implementation (which was not sufficient under Spanish Law) meets the BRs.

I'm struggling to understand, throughout this issue, where the bug was in issuing a QCP-n certificate, or relying on a QCP-n certificate to issue a certificate for the organization. Can you clarify?

My current understanding is that you were incorrectly relying on a QCP-n certificate, but some of the remarks make me think you were incorrectly issuing a QCP-n certificate against a lower level of identity proofing than required.

Comment 11

[Pablo Díaz]

FNMT here refers to issues affecting eIDAS qualified certificates with OID is 1.3.6.1.4.1.5734.3.11.2 (Certificate for Legal representative) and QCP-n (ETSI policy for certificates issued to natural persons). These certificates are not intended to be used for authenticating servers accessible through the Internet (BR Section 1.1 Overview).

I have been following this bug, and I wanted to jump in as I am a bit confused. In my understanding, these certificates do not fall into the scope of the BRs (also Ben clarified a "similar" situation in this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1686524#c4).

Hope this clarifies: QCP-n certificates always contain the natural person information, and can contain (or not) organization information. Law 6/2020 (article 7.6) allows relying on the already verified (by the CA) identity (face-to-face) of a QCP-n certificate to request another QCP-n certificate, as long as no more than 5 years have elapsed since the initial face-to-face identity verification of the certificate used to request.

In this case, I understand, the requester QCP-n certificate was used as a "verified identity" of the natural person, to request a QCP-n (with organization info) certificate. However, FNMT reports that at that time they did not have measures established to guarantee that no more than 5 years had elapsed since the last face-to-face identity verification. This could have permitted the issuance of QCP-n certificates reliying on the "verified identity" of a QCP-n certificate, which was also issued relying of the "verified identity" of another QCP-n (if it makes sense). This is the incident I think is being reported in this bug.

Also maybe the link to the Spanish Law 6/2020 can be useful for this discussion: https://www.boe.es/boe/dias/2020/11/12/pdfs/BOE-A-2020-14046.pdf

Pablo

Comment 12

[alain]

(In reply to Ryan Sleevi from comment #10)

(In reply to alain from comment #9)

(In reply to Ryan Sleevi from comment #8)

It would sound like you're describing a flawed implementation of 3.2.5, then, is that correct?

Or are you saying that the implementation of 3.2.5 was sufficient (for the BRs), but insufficient for art. 7.6 law 6/2020?

Please be sure, the implementation is compliant with BRs.

Thanks for clarifying. It'd be useful to understand more how the implementation (which was not sufficient under Spanish Law) meets the BRs.

I'm struggling to understand, throughout this issue, where the bug was in issuing a QCP-n certificate, or relying on a QCP-n certificate to issue a certificate for the organization. Can you clarify?

My current understanding is that you were incorrectly relying on a QCP-n certificate, but some of the remarks make me think you were incorrectly issuing a QCP-n certificate against a lower level of identity proofing than required.

Thank you Ryan for your interest. You are right. The problem was to rely (just in some cases) on a QCP-n certificate (let’s say: Certificate A) to issue the QCP- n “Certificate of Representatives of Legal Entities” (Certificate B) which is a certificate issued to the natural person who has legal capacity for representing an organization.

Please be informed that it does not mean that Certificate A was misissued nor has lower level of assurance. However, that Certificate A cannot be used to request the issuance of a new qualified certificate (i.e. Certificate B) when the last physical accreditation for Certificate A occurred more than 5 years ago.

The procedure implemented consists of:

1. The applicant request a QCP- n “Certificate of Representatives of Legal Entities” through the request application at FNMT’s website. At this phase, the applicant generates his/hers private and public keys, obtains a “request code” and sends securely the public key to FNMT’s infrastructure.
2. The applicant (legal representative of an organization whose VAT number begins by A, B, C or D) is authenticated with his/hers QCP-n certificate for citizens (Certificate A) at the AEAT’s electronic office.
3. The applicant provides the “request code” obtained, the documentation in regards the organization and his/her representation legal capacity. This request shall be signed electronically by the applicant.
4. Later, and prior to the issuance of a QCP- n “Certificate of Representatives of Legal Entities”, the RA (AEAT) verifies:
   a. That the certificate used in step 2 (Certificate A) complies with art 7.6 Law 6/2020 (maximum time elapsed since physical presence of 5 years) by checking against FNMT’s records.
   b. The organization information (name, country, address,…) for this type of certificates.
   c. The authenticity of the request checking that identity of the applicant matches with the registered legal representative of such organization.
   d. The legal capacity of representation of the applicant for the said organization.
   All validations from b. to d. are performed against registry official records (Registro Mercantil) and in accordance with BRs 3.2. Any inconsistency in the validations from a. to d. leads to the request rejection.
5. AC Representación performs the applicable pre-issuance linting controls (RFC, profiles, BRs,…). If controls are passed, the CA issues the certificate and makes it available to the subscriber through the download app on FNMT’s website.

We have tried to explain the procedure in detail in the hope that this will help to better understand the problem.

Comment 13

[alain]

(In reply to Pablo Díaz from comment #11)

FNMT here refers to issues affecting eIDAS qualified certificates with OID is 1.3.6.1.4.1.5734.3.11.2 (Certificate for Legal representative) and QCP-n (ETSI policy for certificates issued to natural persons). These certificates are not intended to be used for authenticating servers accessible through the Internet (BR Section 1.1 Overview).

I have been following this bug, and I wanted to jump in as I am a bit confused. In my understanding, these certificates do not fall into the scope of the BRs (also Ben clarified a "similar" situation in this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1686524#c4).

Hope this clarifies: QCP-n certificates always contain the natural person information, and can contain (or not) organization information. Law 6/2020 (article 7.6) allows relying on the already verified (by the CA) identity (face-to-face) of a QCP-n certificate to request another QCP-n certificate, as long as no more than 5 years have elapsed since the initial face-to-face identity verification of the certificate used to request.

In this case, I understand, the requester QCP-n certificate was used as a "verified identity" of the natural person, to request a QCP-n (with organization info) certificate. However, FNMT reports that at that time they did not have measures established to guarantee that no more than 5 years had elapsed since the last face-to-face identity verification. This could have permitted the issuance of QCP-n certificates reliying on the "verified identity" of a QCP-n certificate, which was also issued relying of the "verified identity" of another QCP-n (if it makes sense). This is the incident I think is being reported in this bug.

Also maybe the link to the Spanish Law 6/2020 can be useful for this discussion: https://www.boe.es/boe/dias/2020/11/12/pdfs/BOE-A-2020-14046.pdf

Pablo

Thank you Pablo for your contribution. We hope that we have been able to clarify the issue in comment #12 . Do we??

Comment 14

[Ryan Sleevi]

(In reply to alain from comment #12)

Thank you Ryan for your interest. You are right. The problem was to rely (just in some cases) on a QCP-n certificate (let’s say: Certificate A) to issue the QCP- n “Certificate of Representatives of Legal Entities” (Certificate B) which is a certificate issued to the natural person who has legal capacity for representing an organization.

Thanks! Yes, this is where things were breaking down - that you were describing two different QCP-n certificate types (A vs B), and was trying to understand which certificate was being spoken to in various places.

Knowing that both of these are QCP-n, which is where I was trying to parse, does make it less concerning. I have no further questions.

Comment 15

[Ben Wilson]

I will schedule this to be closed on or about next Friday, 26-Mar-2021, unless other issues or questions need to be resolved.