1559342 - Add AC RAIZ FNMT-RCM SERVIDORES SEGUROS root

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[alain]

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

Steps to reproduce:

N/A
Root Inclusion

Actual results:

N/A
Root Inclusion

Expected results:

N/A
Root Inclusion

Comment 1

[alain]

Please find herewith the FNMT root inclusion request for:
ROOT 1: AC RAIZ FNMT-RCM SERVIDORES SEGUROS / 554153B13D2CF9DDB753BFBE1A4E0AE08D0AA4187058FE60A2B862B2E4B87BCB
INTERMEDIATE 1.1: AC SERVIDORES SEGUROS TIPO1 / 1EDB6BD91274882DB795BFC514F8AABE10AD955CBCCFD3FD5A5B5FEBB2CE5B68
INTERMEDIATE 1.2: AC SERVIDORES SEGUROS TIPO2 / 9FF23CB9387B9E0083BD5AA1954EEDDF792890AA8E67CD4D38DD28AF4A439AD8

All the related information for this root inclusion request can be found in:

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000418

Comment 2

[Kathleen Wilson]

The link below shows the CA information that has been verified. Search in the page for the word "NEED" to see where further clarification is requested.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000418

In particular:

1. Please attach this CA's latest BR Self Assessment to this bug
   https://wiki.mozilla.org/CA/BR_Self-Assessment

2. Perform testing when the EV test websites are available
   a) Test with http://certificate.revocationcheck.com/ make sure there aren't any errors.
   b) Resolve or explain lint testing errors.
   I put the cert chain from https://testactivetipo2.cert.fnmt.es/ into the 'Certificate Linter' at https://crt.sh/?a=1
   end-entity cert: zlint ERROR Checks that a QC Statement that contains at least one of the ETSI ESI statements, also features the set of mandatory ETSI ESI QC statements.
   no errors for the intermediate and root certs.
   c) Provide successful output from EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 3

[alain]

Attachment: BR self assessment AC Servidores Seguros.pdf

Please find attached BR Self Assessment for AC RAIZ FNMT-RCM SERVIDORES SEGUROS

Comment 4

[Kathleen Wilson]

(In reply to alain from comment #3)

Created attachment 9072771 [details]
BR self assessment AC Servidores Seguros.pdf

Please find attached BR Self Assessment for AC RAIZ FNMT-RCM SERVIDORES SEGUROS

Thanks!

Please add another comment to this bug when the EV test websites are available and the tests have been successfully performed. (per item 2 of comment 2).

Comment 5

[alain]

(In reply to Kathleen Wilson from comment #2)

The link below shows the CA information that has been verified. Search in the page for the word "NEED" to see where further clarification is requested.>
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000418

In particular:

2. Perform testing when the EV test websites are available
   a) Test with http://certificate.revocationcheck.com/ make sure there aren't any errors.
   b) Resolve or explain lint testing errors.
   I put the cert chain from https://testactivetipo2.cert.fnmt.es/ into the 'Certificate Linter' at https://crt.sh/?a=1
   end-entity cert: zlint ERROR Checks that a QC Statement that contains at least one of the ETSI ESI statements, also features the set of mandatory ETSI ESI QC statements.
   no errors for the intermediate and root certs.
   c) Provide successful output from EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Please be informed we have already uploaded the EV test websites:
https://testactivetipo1.cert.fnmt.es/
https://testrevokedtipo1.cert.fnmt.es/
https://testexpiredtipo1.cert.fnmt.es/
No errors found.
Output from EV Testing: ev-checker exited successfully

Comment 6

[Kathleen Wilson]

Alain,

1. Please provide an Incident Report and status for the non-comformities listed in this audit statement. (I noticed that the audit statement for this root inclusion request is not the same as the audit statement discussed in Bug #1544586.)

https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019%200003%20-%20FNMT-v2.2.pdf

2. https://certificate.revocationcheck.com/testactivetipo1.cert.fnmt.es shows a timeout error for me.

Comment 7

[alain]

Kathleen,

1. Please find herewith incident report for the following findings referred to audit report https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019%200003%20-%20FNMT-v2.2.pdf.
   (Please be aware that some of the findings have been already reported to bug 1544586 and bug 1495507)

Findings:
#1 - In the case of the QCP-w certificates that will be issued by "AC SERVIDORES SEGUROS TIPO1" with the new validation platform, evidence has been found during the tests…..,
#2 We could not find evidence of the formal definition and assignment of the validation
specialist profile, as ……– Please refer to bug 1544586 (topic 3#)
#3 The incidents that have an impact on the availability of the services are not classified as security incidents…..– Please refer to bug 1544586 (topic 4#)
#4 We have not been able to find evidence of the TSP’s monitorization procedure of the status of the QSCD certification…..
#5 We have evidence qualified certificates issued with errors:

• (QCP-n) 1.3.6.1.4.1.5734.3.3.4.4.2: Certificates with organizationName or organizationUnitName bigger than 64 characters…..– Please refer to bug 1495507.
  #6 Although follow-up and actions are performed aimed at improving the level of compliance of the public website with regards to accessibility standards, … – Please refer to bug 1544586 (topic 6#)
  #7 The entity makes available the CPS and CP, including adherence to the requirements of the CA / B Forum, although the adherence to the EVCGs requirements in the general CPS are not included. It should be noted that we have not been able to find evidence of the availability of test sites for the new hierarchy "AC RAIZ FNMT-RCM SERVIDORES SEGUROS".

Incident report

1. How your CA first became aware of the problem.
   Topic #1 (validation and the approval of the certificate request)
   During the face-to-face review by the auditors, it was evidenced the existence of a bug in the application developed to manage the dual roles for approving the issuance of a QCP-w. To date only test certificates have been issued.
   Topic #4 (monitorization procedures of the status of the QSCD certification)
   During the face-to-face review by the auditors, it has not been possible to demonstrate how the TSP monitors the status of the QSCD certifications for the QCP-n-remote certificates or the appropriate measures in the DPC in case of loss of status as QSCD.
   Topic #7 (adherence to the EVCGs requirements in the general CPS)
   During the documental review by the auditors, it was pointed out that only the specific CP included the required reference to the EVCGs requirements. Also, at that time on ly the OVCP test websites for AC Servidores Seguros were available.
2. A timeline of the actions your CA took in response..
   Topic #1 (validation and the approval of the certificate request)
   After the meeting about the results of the Audit, which took place on February 8th, the software development team proceed to review and correct of the app code in order to prevent a validator from approving the issuance of the same certificate in accordance with EVCG 14.1.3.
   Topic #4 (monitorization procedures of the status of the QSCD certification)
   On March 5, 2019 took place an extraordinary TSP Management Committee meeting, agreeing to include the following controls in the agenda of the ordinary call of its quarterly meetings:
3. Establish a periodic check at least every 3 months in order to confirm the status of the QSCD certification. Specifically evidence will be collected from

• Trusted list of the European Commission of qualified signature / stamp creation devices
• communications of any from the manufacturer itself as well as from the supervisory body.

2. Include in the agenda of the ordinary (quarterly) calls of the TSP Management Committee, the results of the controls established in relation to the monitoring of the certifications. In case of loss, the TSP Management Committee will be called as soon as the event is known to execute the corresponding actions.

3. Include in the General CPS the form of action in case of loss of the QSCD certification (CPS section 9.17, paragraph 430)
   Topic #7 (adherence to the EVCGs requirements in the general CPS)
   Version 5.4 of the General CPS approved and published on 05/03/2019, states in section 9.17. OTHER STIPULATIONS, paragraph 428, the required statement
   EVCP test websites for AC Servidores Seguros were available on July 11th 2019.

4. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem
   Topic #1 (validation and the approval of the certificate request)
   The problem has been solved in time so no certificates have been issued with this problem. To date, only test certificates have been issued.
   Topic #4 (monitorization procedures of the status of the QSCD certification)
   The only certificates that could have been affected are the qcp-n remote certificates. No certification had undergone any variation and therefore there is no certificate affected by this problem
   Topic #7 (adherence to the EVCGs requirements in the general CPS)
   The specific certificate policy for AC Servidores Seguros have always stated the required adherence to EVCGs. (CP Section 9.6.1. CA's obligations – paragraph 217: “In addition, the FNMT-RCM undertakes to comply, with regard to the issue of EV Certificates (Website certificate, EV Certificate and SAN EV Certificate), all requirements established by the entity CA/Browser for these types of Certificates, and which can be consulted at https://cabforum.org/extended-validation/)”
   Therefore no EV certificates have been issued with this problem. To date only test certificates have been issued.

5. A summary of the problematic certificates.
   Topic #1 (validation and the approval of the certificate request)
   The problem has been solved in time so no certificates are involved.
   Topic #4 (monitorization procedures of the status of the QSCD certification)
   The monitoring controls have been implemented and no certificates are involved.
   Topic #7 (adherence to the EVCGs requirements in the general CPS)
   No certificates involved.

6. The complete certificate data for the problematic certificates.
   Topic #1 (validation and the approval of the certificate request)
   The problem has been solved in time so no certificates are involved.
   Topic #4 (monitorization procedures of the status of the QSCD certification)
   The monitoring controls have been implemented and no certificates are involved.
   Topic #7 (adherence to the EVCGs requirements in the general CPS)
   No certificates involved.

7. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   Topic #1 (validation and the approval of the certificate request)
   Only when using the Internet Explorer browser, the technical control that prevents a validator from approving the request for issuing the same certificate was not applied.
   Topic #4 (monitorization procedures of the status of the QSCD certification)
   The monitorization procedures of the status of the QSCD certification were not documented at that moment.
   Topic #7 (adherence to the EVCGs requirements in the general CPS)
   The adherence to the EVCGs was only expressly indicated in the particular CP. In regards the EV test websites, at that moment, we were updating the EV profiles to the latest version of EV guidelines (removal of OrganizationIdentifier field)

8. 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.
   Topic #1 (validation and the approval of the certificate request)
   The bug in the app code has been already fixed and the correct functioning of the tool has been verified for all supported browsers. Evidences were already forwarded to the audit team within the corrective action plan.
   Topic #4 (monitorization procedures of the status of the QSCD certification)
   The monitorization procedures of the status of the QSCD certification results have been integrated in the agenda of the ordinary (quarterly) calls of the TSP Management Committee
   Topic #7 (adherence to the EVCGs requirements in the general CPS)
   A new and updated version of the general CPS (v5.4 – 05/03/2019) has been published in order to resolve this problem. EV test websites made available on July 11th.

9. As in regards the timeout error within the revocation check, I’m afraid we are not able to reproduce it...
   Kathleen, could you please send us further details?

Comment 8

[Kathleen Wilson]

(In reply to alain from comment #7)

Kathleen,

1. Please find herewith incident report for the following findings referred to audit report https://www.aenor.com/Certificacion_Documentos/eiDas/2019%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019%200003%20-%20FNMT-v2.2.pdf.
   (Please be aware that some of the findings have been already reported to bug 1544586 and bug 1495507)

Thanks

2. As in regards the timeout error within the revocation check, I’m afraid we are not able to reproduce it...
   Kathleen, could you please send us further details?

The timeout has gone away.
I will not the warning:
"http://ocspfnmtss1.cert.fnmt.es/ocspss1/OcspResponder (UNKNOWN)
Certificate status is 'Revoked' expecting 'Unknown' "
But I don't think that's an actual violation...
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#OCSP

• OCSP Responders SHALL NOT respond “Good” for Unissued Certificates. (section 4.9.10)

Comment 9

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000418

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

Comment 10

[Brox]

On 30/03/2019 we received the audit reports for the period from January 13, 2019 until January 12, 2020. We are working on the incident report for the findings which will be attached to this bug asap.
Please find herewith links to annual audit report and to our updated CPS:

ETSI EN 319 411-2 (AC SERVIDORES SEGUROS TIPO 1)
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v0.1%20-%20rev4.pdf

ETSI EN 319 411-1 (AC SERVIDORES SEGUROS TIPO 2)
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v0.1%20-%20rev4.pdf

UPDATED GENERAL CPS
https://www.sede.fnmt.gob.es/documents/10445900/10536309/dgpc_english.pdf

UPDATED CPS AC SERVIDORES SEGUROS
https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf

Comment 11

[Kathleen Wilson]

(In reply to Brox from comment #10)

On 30/03/2019 we received the audit reports for the period from January 13, 2019 until January 12, 2020. We are working on the incident report for the findings which will be attached to this bug asap.

I have filed Bug #1626805 for the minor non-conformities that are listed in the 2020 audit statement. Please provide the incident in that bug.

Comment 12

[Kathleen Wilson]

Attachment: AENOR Audit Memo FNMT.pdf

Audit Memorandum provided by the auditor which says:
"The audit was carried out as a period audit and covered the period from the January 13th, 2019 (2019-01-13) until January 12th, 2020 (2020-01-12) resulting in the following audit reports:
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%201%20ETSI%20319%20411-2%20PSC-2019-003%20-%20FNMT-v0.1%20-%20rev4.pdf
https://www.aenor.com/Certificacion_Documentos/eiDas/2020%20AENOR%20Anexo%202%20ETSI%20319%20411-1%20PSC-2019-003%20-%20FNMT-v0.1%20-%20rev4.pdf
During the audit, we verified that the QCP-w profiles indicated below are intended only for legal persons and, therefore, the required controls of the EVCP profile of the ETSI EN 319 411-1 standard were audited as established in the ETSI EN 319 411-2 standard (Control OVR-5.1-03)."

Comment 13

[Ben Wilson]

FNMT Certification Practice Statements

Documents Reviewed: This is a review of:

Root CPS, version 5.7 (Declaración General de Prácticas de Certificación – “DGPC) https://www.sede.fnmt.gob.es/documents/10445900/10536309/dgpc_english.pdf , and

CPS for EV and OV Certificates (Política y Prácticas de Certificación particulares de los certificados de Servidores Seguros – “DPPP”), version 1.3, English translation - https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf.

Good

Generally

Both CPSes (DGPC and the DPPP) are formatted according to RFC 3647, as required by section 2.2 of the Baseline Requirements.

There is a Document History table for the DGPC and the DPPP. This is good because it shows change management by the CA’s Policy Authority and demonstrates annual review / revision of the CPS.

Specifically (sections refer to the DPPP unless otherwise indicated)

1.3.1 – 20

The PKI hierarchy is presented in the DGPC and there is a separate PKI hierarchy for server certificates under the “Servidores Seguros” root certificate.

1.4.2 - 23

This section of the DPPP prohibits the use of server certificates for interception of communications and man-in-the-middle attacks.

1.5.4 – 30

CPS is updated and re-versioned annually, even if no other changes are made. Mozilla Root Store Policy, section 3.3 (subsection 4), requires that the CPS be reversioned and re-dated, even if there are no changes. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses

3.1.1 – 42

“FNMT-RCM complies with X.500, RFC 5280 and CA/Browser Forum requirements for naming.”

3.2.2.4 - 62

“[B]efore issuing a Website authentication certificate, it is verified that the domain to be included in the Certificate is public (i.e. it is not an internal domain)” (Per section 3.2.2.5 – 63, FNMT does not issue certificates to IP addresses)

3.2.4 – 69

All information in the certificate is verified. There is no unverified information in the certificate.

4.2.1 – 86

“Reuse of previous validation data or documentation obtained from a source specified under section 3.2 may be used no more than 13 months after such data or documentation was validated.”

4.2.2 – 87

“The RA that acts in the process of issuing Website authentication certificates is shall always be that of the FNMT-RCM itself, and, therefore, the validation of domains will never be delegated to any other AR.”

This is good because third parties are not allowed to perform domain verification. See Baseline Requirements section 1.3.2 - “With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”

4.2.2 – 93

CAA record processing is specified, as required by section 2.2 of the Baseline Requirements.

4.3.1 – 96

“Once the application for the Certificate has been approved by the RA of the FNMT-RCM's, the system then performs pre-issuance linting to check compliance with RFC 5280 and CA/Browser Forum (BRs and EVGs). Only where no errors are found, FNMT-RCM proceeds to issue the Certificate according to the profile approved for each corresponding type of Certificate.”

4.3.1 – 98

“The processes related to the issuance of electronic Certificates guarantee that all the accounts that interact with them include multi-factor authentication.” Subsection 3 of section 2.1 of the Mozilla Root Store Policy requires that any accounts capable of certificate issuance use multi-factor authentication.

4.9.1.1 – 141

Reasons for Revoking a Subordinate CA follow those in section 4.9.1.1 of the Baseline Requirements.

4.9.2 – 145

“Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate”

4.9.5 – 152

“All revocation requests for end entity Certificates, are processed within a maximum of 24 hours of receipt.”

4.9.7 – 155

“Revocation lists (CRLs) for end-entity Certificates are issued at least every 12 hours, or whenever there is a revocation; they have a 24-hour validity period”

5.7.3 – 236 (of the DGPC)

In the event of a key compromise, FNMT will “3) Execute the Communication Plan to notify of the events affected parties and to the browsers in whose root programs the FNMT-RCM certificates are included.”

6.1.1.3 – 226

“The Private keys for the Website authentication certificates are generated and guarded by the Subscriber of the Certificate.” Section 5.2 of the Mozilla Root Store Policy prohibits key generation for the Subscribers of server certificates.

6.1.5 – 231

FNMT only allows ECC P-384.

9.6.1 – 318

“In the event of any inconsistency between this DPPP and the aforementioned version, said requirements shall prevail over those contained in this document.” Section 2.2 of the Baseline Requirements and section 8.3 of the EV Guidelines say that the CA must include in the CPS such statements.

Section 9.10.2 of the DGPC – 428

The FNMT- RCM undertakes to subject the CPS to an annual review process.

Meh

1.5.2 - 27

This section should also mention “revocation requests”. Currently it only says, “To report security issues such as suspected key compromise, certificate misuse, fraud or other matters, contact [e-mail]”

4.9.13 – 161

CPS states, “The suspension of certificates is not covered.” Does this mean that suspension is not an option, not provided?

4.10

I couldn’t see where the validity period of an OCSP response was specified. Section 6 of Mozilla Root Store Policy provides,

For end-entity certificates, if the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service:

• it MUST update that service at least every four days; and
• responses MUST have a defined value in the nextUpdate field, and it MUST be no more than ten days after the thisUpdate field; and
• the value in the nextUpdate field MUST be before or equal to the notAfter date of all certificates included within the BasicOCSPResponse.certs field or, if the certs field is omitted, before or equal to the notAfter date of the CA certificate which issued the certificate that the BasicOCSPResponse is for.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation

6.3.2 – 249

The maximum validity for OV certificates should be clarified as 397 days (instead of 24 months).

9.5 - 315

References the corresponding section of the DGPC. Note that while section 9.5 of the DGPC states, “382. The FNMT-RCM holds all rights, title and interest to all intellectual and industrial property and knowledge related to this DGPC, the statements (policies and practices) specifying or completing this DGPC, the services provided and the computer programs or hardware used to provide them,” Mozilla Root Store Policy 3.3.3 provides that CPs and CPSes are made available under a Creative Commons license (or a set of equally permissive licensing terms).

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses

Certificate Profiles

I didn’t see a certificate profile for end entity certificates. Is there a mechanism to ensure that serial numbers are non-sequential, greater than zero (0), and contain at least 64 bits of output from a CSPRNG?

I also didn’t see where you acknowledge that any CN value in the subject DN of an end entity certificate must also be in one of the SANs. Some CAs include that in the Naming section or elsewhere in their CPS, but I couldn't find it in your CPS.

Also note that any certificates must contain an EKU and not the “anyEKU” EKU. Mozilla Policy section 5.2 states, “Effective for certificates with a notBefore date of July 1, 2020 or later, end-entity certificates MUST include an EKU extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.”

Bad

3.2 – 49 and 50 and 3.2.2.4 – 60

Section 2.3 of the Baseline Requirements says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements." Subsection 3 of section 2.2 of the Mozilla Root Store Policy 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.4 it is complying with.” See - https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Baseline_Requirements ("It is not sufficient to simply reference section 3.2.2.4 of the CA/Brower Forum's Baseline Requirements (BR)")

FNMT asserts that it will use the following Baseline Requirements methods: “3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact”, “3.2.2.4.4 Constructed Email to Domain Contact” or “3.2.2.4.7 DNS Change”. It is good that “For each method FNMT-RCM will follow a documented process and maintain records noting the method(s) used for each issuance.”

While one might argue that the FNMT CPS meets the very minimum requirements of Baseline Requirements and the Mozilla Policy, the provisions are just too short and abbreviated. For instance, it is clear that FNMT will only use those 3 methods for domain validation, but most CPSes provide a little more detail for how these procedures are accomplished. Similarly, for Extended Validation, the following language is an inadequate statement of validation procedures followed by FNMT to issue Extended Validation certificates because it does not provide any specifics on how several practices are actually performed by FNMT:

“In addition, the FNMT-RCM, before issuing an EV Certificate, SAN EV Certificate or Electronic Venue certificate, ensures that all information included in these types of Certificates relative to the Subscriber, is in accordance with (and is verified according to) the requirements defined by the entity CA/Browser forum in its “guide for the issuance and management of Extended Validation Certificates” and that can be consulted at the address https://cabforum.org/extended-validation/”

For instance, how does FNMT determine what qualifies as a QIIS? And how can FNMT be fully and fairly audited if its CPS doesn’t contain all of the BR/EV requirements? Are its auditors fully familiar with both standards? Are detailed checklists used to ensure compliance? Are there separate and additional sets of controls and lists of controls that FNMT maintains and provides to its auditors? These and other related questions remain to be answered in the CPS or other public document. Transparency is missing without more details regarding FNMT's specific practices to demonstrate that it follows and complies with the BR and EV requirements.

Comment 14

[Brox]

We thank you for your thorough CPS review. We are currently evaluating your feedback and will provide a response in Bugzilla ASAP.

Comment 15

[Brox]

We have just approved and published a new version for CPS for EV and OV Certificates (Política y Prácticas de Certificación particulares de los certificados de Servidores Seguros – “DPPP”), version 1.4, English translation - https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf.
This update improves and provides more detail on the following sections:
1.5.2. - 27 : To report security issues such as suspected key compromise, certificate misuse, fraud, revocation requests or other matters, contact [e-mail]
4.9.13 – 161: The suspension of certificates is not provided
6.3.2 – 255: The Website authentication certificates and their set of Keys: the maximum period of validity of the OV Certificate, SAN OV Certificate, Wildcard OV Certificate, EV Certificates, SAN EV Certificates and Electronic Venue certificate EV is 12 months.
In order to provide more details of our validation procedures, we have include the following into our CPS:
3.1. NAMING
42. In addition, for EV Certificates, the FNMT-RCM shall meet the requirements of Section 9.2 of the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates.
3.1.2. Need for names to be meaningful
46. The Subject Distinguished Name fields are also subject to the requirements of Section 9.2 of the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates. Wildcard Certificates are not allowed for EV Certificates
3.2. INITIAL IDENTITY VALIDATION
52. In addition, the FNMT-RCM, before issuing an EV Certificate, SAN EV Certificate or Electronic Venue certificate, ensures that all information included in these types of Certificates relative to the Subscriber, is in accordance with (and is verified according to) the requirements defined by the entity CA/Browser forum in its “guide for the issuance and management of Extended Validation Certificates”, (section 11) and that can be consulted at the address https://cabforum.org/extended-validation/
53. The FNMT-RCM records all confirmations performed in this section for both internal an independent audits processes.
3.2.2.1 Identity
61. If an Applicant requests an Extended Validation (EV), the FNMT-RCM shall conform to the CAB Forum’s respective EV Guidelines.
3.2.2.2 DBA/Tradename
63. For EV Certificate requests extensive identity verification as defined in the CAB Forum’s EV Guidelines section 11.3 are required.
3.2.2.4 Validación de la autorización y control sobre el dominio
65. In order validate Website authentication certificate domains, 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.4 Constructed Email to Domain Contact” or “3.2.2.4.7 DNS Change “. For each method FNMT-RCM will follow a documented process and maintain records noting the method(s) used for each issuance. The rest of methods described in the CA/Browser Forum's Baseline Requirements document are not used.
• 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact:
Confirming the Applicant’s control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value must be sent to an email address identified as a Domain Contact.
Each email may confirm control of multiple Authorization Domain Names.
FNMT-RCM may send the email identified under this section to more than one recipient provided that every recipient is identified by the Domain Name Registrar as representing the Domain Name Registrant for every FQDN being verified using the email.
The Random Value shall be unique in each email.
FNMT-RCM may resend the email in its entirety, including re-use of the Random Value, provided that the communication’s entire contents and recipient(s) remain unchanged.
The Random Value shall remain valid for use in a confirming response for no more than 30 days from its creation.
• 3.2.2.4.4 Constructed Email to Domain Contact:
Confirm the Applicant’s control over the requested FQDN by (i) sending an email to one or more addresses created by using ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ as the local part, followed by the at-sign (“@”), followed by an Authorization Domain Name, (ii) including a Random Value in the email, and (iii) receiving a confirming response utilizing the Random Value.
Each email may confirm control of multiple FQDNs, provided the Authorization Domain Name used in the email is an Authorization Domain Name for each FQDN being confirmed.
The Random Value shall be unique in each email.
The email may be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipients shall remain unchanged.
The Random Value shall remain valid for use in a confirming response for no more than 30 days from its creation.
• 3.2.2.4.7 DNS Change:
Confirming the Applicant’s control over the requested FQDN by confirming the presence of a Random Value in a DNS TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character.
FNMT-RCM shall provide a Random Value unique to the certificate request and shall not use the Random Value after (i) 30 days.
3.2.5. Validation of Authority
77. For Extended Validation requests, FNMT-RCM shall verify this authority using the procedures described in the EV Guidelines. (sections 11.8 y 11.11)
4.1.1. Who can submit a certificate application
83. In addition, for EV Certificates, the FNMT-RCM shall meet the requirements of Section 11 of the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates
4.2.2. Approval or rejection of certificate applications
98. Both OV and EV certificate requests shall be processed by FNMT-RCM Trusted Role personnel. The approval system for issuing EV Certificates requires the action of at least two Trusted Role personnel belonging to the RA of the FNMT-RCM, one with the role of validating and the other with the role for approving the requests.
In regards your comments for 4.10 (OSCP) and 9.5 – 315 (Creative Commons license), please be informed that we will need to update such information in the next version of our DGPC (Root CPS, version 5.8 (Declaración General de Prácticas de Certificación – “DGPC) https://www.sede.fnmt.gob.es/documents/10445900/10536309/dgpc_english.pdf) since both issues are common and applicable to all our CAs.

Comment 16

[alain]

We have just approved and published a new version of DGPC (general CPS) in order to provide more detailed information in regards our OCSP service and concerning the intellectual property rights of our CPSs as suggested. (https://www.sede.fnmt.gob.es/documents/10445900/10536309/dgpc_english.pdf)

The changes made are:
4.10.1. Operational features
130. The OCSP supports the GET Method for retrieval of validation information for Certificates issued, in accordance with RFC 6960 and the requirements established by CA/Browser Forum (https://cabforum.org/baseline-requirements-documents/). FNMT-RCM OCSP responses have validity interval of 8 hours and the information provided via OCSP updates constantly by acceding directly to the database of each AC. The OCSP responder that receives a request for status of a certificate which has not been issued, shall not respond with a “good” status.
9.5. Intellectual Property Rights
383. The FNMT-RCM holds all rights, title and interest to all intellectual and industrial property and knowledge related to this DGPC, the statements (policies and practices) specifying or completing this DGPC, the services provided and the computer programs or hardware used to provide them. Any other use other than viewing, including the reproduction, redistribution and / or modification of this DGPC as well as the declarative documents (policies and practices) that specify and complete this DGPC, is prohibited without the express authorization of the FNMT-RCM.

Comment 17

[Ben Wilson]

FNMT Certification Practice Statements

I have completed my review of the following CPSes:

Root CPS, version 5.8 (Declaración General de Prácticas de Certificación – “DGPC) https://www.sede.fnmt.gob.es/documents/10445900/10536309/dgpc_english.pdf

(As noted in Comment #16 above)

CPS for EV and OV Certificates (Política y Prácticas de Certificación particulares de los certificados de Servidores Seguros – “DPPP”), version 1.4, English translation - https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf.

I noticed the following improvements to the DPPP:

1.5.2

This section now includes “revocation requests” for issue reporting.

3.1, 3.1.2, 3.2, 4.1.1, passim

Cross-references have been added specifying the EV Guidelines.

3.2.2.4

Specifically identifies and explains domain validation processes from sections 3.2.2.4 of the CA//Browser Forum's Baseline Requirements:

​ 3.2.2.4.2 - random value sent via email to domain contact

​ 3.2.2.4.4 - random value sent via email to ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ as the local part,

​ 3.2.2.4.7 - DNS change

4.2.1

Reuse of information limited to 12 months

4.9.13 – 4.9.16

CPS is clarified to state that certificate suspension is not provided.

6.3.2

CPS states maximum validity period of server certificates is 12 months

I will now review the body of the inclusion request again to determine whether this application is ready for public discussion.

Comment 18

[Brox]

Attachment: BR Self Assessment update OCT2020.pdf

updated BR Self Assessment

Comment 19

[Brox]

Please find attached updated BR Self Assessment for AC RAIZ FNMT-RCM SERVIDORES SEGUROS

Comment 20

[Ben Wilson]

Public discussion began yesterday – https://groups.google.com/g/mozilla.dev.security.policy/c/T5bYrPznCXQ/m/1Cn0I31EAgAJ –
and is scheduled to close on Wednesday, 9-December-2020. According to the root inclusion process, https://wiki.mozilla.org/CA/Application_Process, the CA's representative is responsible for responding to questions or concerns directly within the discussion being held on the m.d.s.p. list.

Comment 21

[Brox]

Attachment: CA's BR Self Assessment Nov2020.pdf

We have updated our BR Self Assessment following the generation of a new CPS version (1.6)

Comment 22

[Ben Wilson]

Hi Kathleen,
The three-week public discussion period for this request to include FNMT in the root store concluded last week. Today, I provided notice of Mozilla's intent to approve this request on the mdsp list, https://groups.google.com/g/mozilla.dev.security.policy/c/T5bYrPznCXQ/m/QMOZ0lHHAQAJ. According to Step 10 in the process description, https://wiki.mozilla.org/CA/Application_Process#Process_Overview, "After one week, if no further questions or concerns are raised, then a representative of Mozilla may approve the request, by stating so in the bug."
Thanks, Ben

Comment 23

[Kathleen Wilson]

As per Comment #22, and on behalf of Mozilla I approve this request from Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) to include the following root certificate:

** 'AC RAIZ FNMT-RCM SERVIDORES SEGUROS' (Websites); EV

I will file the NSS and PSM bugs for the approved changes.

Comment 24

[Kathleen Wilson]

I have filed bug #1683738 against NSS and bug #1683761 against PSM for the actual changes.