--- title: CERTIFICATION PRACTICES AND POLICIES STATEMENT ON WEBSITE AUTHENTICATION CERTIFICATES subtitle: Version 1.18 author: FNMT-RCM date: 12-March-2026 Document Classified as: Public ---
Historic
Version

Date

 Description
1.0 5/03/2019 Certification Practices and Policies Statement on website authentication certificates, under the hierarchy of the FNMT Root AC Raíz Servidores Seguros
1.1 30/05/2019 Update domain validation methods according to CA / Browser Forum Baseline Requeriments.
1.2 12/12/2019 General review and improvement update
1.3 16/06/2020 General review in accordance to Mozilla Root Store Policy v.2.7., Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates v.1.7.0. and EV Guidelines v.1.7.2
1.4 31/08/2020 Reduction of the validity period of OV SSL certificates to 12 months. Improvements in several sections
1.5 01/10/2020 Incorporation of the EKU "Client Authentication" to the website authentication certificates.
1.6 26/11/2020 Incorporation of information from the DGPC for greater clarity. General review in accordance with Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates v.1.7.3. and EV Guidelines v.1.7.4
1.7 18/02/2021

Inclusion of the URL where the list of Incorporating Agencies or Registration Agencies was published.

Compliance review to Law 6/2020.

Reference to the maximum period between revisions of the Information Security Policy is documented
1.8 28/04/2021 General review and Mozilla Policy review v2.7.1. - Information is included in relation to the methods to communicate a compromise of keys.
1.9 30/09/2021 General review in accordance to Mozilla Root Store Policy v.2.7.1, Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates v.1.8.0. and EV Guidelines v.1.7.8. Clarifications are included in regards ballot SC48
1.10 02/03/2022 Inclusion of information for third parties relying on qualified certificates.
1.11 02/03/2023 General review in accordance to Mozilla Root Store Policy v.2.8, Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates v.1.8.6 y EV Guidelines v.1.8.0. Modifications about new RD 51/2023
1.12 07/02/2024 General review
1.13 11/04/2024 Update to the 'Certificate Policies' extension
1.14 03/02/2025 General review in accordance to Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates v.2.1.2 y EV Guidelines v.2.0.1. Modification of the methods used for validating the Applicant’s ownership or control of the domain.
1.15 26/03/2025 General review in accordance to Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
1.16 28/11/2025

General review.

Added new subsection 5.7.1.1 Incident Response and Disaster Recovery Plans and 5.7.1.2 Mass Revocation Plans. Section 5.7 re-structured.

Removal of validation method 3.2.2.4.4 Constructed Email to Domain Contact

The following section are updated, extended and/or clarified: 2.2 / 3.1.2 / 3.2 / 3.2.2 / 3.2.2.8 / 3.2.2.9 / 4.2.1 / 4.2.2 / 4.3.1 / 4.4.1 / 4.5.1 / 4.9.1 / 4.9.7 / 4.9.9 / 4.10.1 / 4.10.2 / 5.1.8 / 5.2.1 / 5.2.4 / 5.3.6 / 5.4.1 / 5.4.8 / 6.1.1.3 / 6.3.2 / 7.2.2 / 8.1 / 8.2 / 8.7 / 9.6.1 / 9.6.3 / 9.14 / 9.16.3.

Removal of redundant text in section 9.17.
1.17 18/12/2025 Inclusion of new hierarchy G2R and new G2 Subordinates.
1.18 12/03/2026 New validity periods in 4.2.1 and 6.3.2. Section 3.2.2.4 updated and section 3.2.2.8.1 added. General review.
\ # 1. Introduction 1. The Fábrica Nacional de Moneda y Timbre - Real Casa de la Moneda (*The National Currency and Stamp Factory – Spanish Royal Mint*), hereinafter the FNMT-RCM, bearer of tax identification number Q2826004-J, is a public business corporation regulated by Act 40/2015 (1 October) on the Public Sector Legal Regime. As a public body, the FNMT-RCM has a separate public legal personality, its own assets and treasury, and is managed independently in the terms of the said law. 2. It is attached to the Ministry of Finance, which, through the Under-Secretary’s Office for Finance, will be responsible for strategic management and control of the FNMT-RCM’s efficiency in the terms of the aforementioned Act 40/2015. 3. The FNMT-RCM has been engaged in its industrial activities, backed by the State, for a long period of time. Since Article 81 of Act 66/1997 (30 December) on Tax, Administrative and Labour Matters and its amendments came into force, the FNMT-RCM's authorised services have been expanded and it has achieved recognition in the provision of trust services. ## 1.1. Overview 4. The FNMT-RCM, through the CERES (Spanish Certification) Department, has been given the status of Qualified Trust Service Provider, in accordance with Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market, and repealing Directive 1999/93/EC, through an independent entity and within the framework of a certification scheme, in compliance with the European standard ETSI EN 319 401 “General Policy Requirements for Trust Service Providers”. 5. The purpose of this document is to provide public information on the conditions and features of the trust services offered to users of *Website authentication certificates* provided by the FNMT-RCM as a *Trust Service Provider,* specifically the obligations the FNMT-RCM must fulfil in connection with: - the management of the said *Certificates,* the conditions applicable to the application, issuance, use and cancellation of the validity thereof, and - the provision of the *Certificate* validity checking service, as well as the conditions applicable to the use of the service and guarantees offered. 6. This document (CP/CPS) aims to comply with the latest version of: - CA/Browser Forum’s “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” () - CA/Browser Forum’s “Guidelines for the Issuance and Management of Extended Validation Certificates” (), - the following policies: 1. CCADB Policy. 2. Chrome Root Program Policy. 3. Mozilla Root Store Policy. 4. Microsoft Trusted Root Program. 5. Apple Root Certificate Program. ## 1.2. Document name and identification 7. This document is called “*Certification Practices and Policies Statement on Website Authentication Certificates*”, and will hereafter be cited in this document and with the scope described therein as “*Certification Practice and Policy Statement”* or by its acronym "*CP/CPS*" as a combined *Certificate Policy* *"CP*" and *Certification Practice Statement "CPS"* document. **Version**: 1.18 **Issue date:** 12/03/2026 **Location**: 8. A *Website authentication certificate* is a type of certificate aimed at ensuring that the domain name of the website to which Internet users are connected is authentic, by using protocols that provide data encryption and authentication between applications and servers (TLS/SSL). 9. Within the scope of this *CP/CPS*, the FNMT-RCM issues the following types of *Website authentication certificates,* the description of which is found in the section “1.6.1 Definitions” of this document: - *Website authentication certificates* which are considered to have the condition of qualified[^1]: | **Type of *Certificate*** | **Policy Reference/OID** [^2] | |-----------------------------------|-------------------------------| | *Electronic Venue certificate EV* | 1.3.6.1.4.1.5734.3.16.1.1 | | *EV Certificate* | 1.3.6.1.4.1.5734.3.16.1.2 | | *EV SAN Certificate:* | 1.3.6.1.4.1.5734.3.16.1.3 | Policy Reference OIDType of certificate EV This qualified certificates have the following associated policies: Extended Validation Certificate Policy (EVCP) OID: 0.4.0.2042.1.4 Extended Validation (EV) guidelines certificate policy OID: 2.23.140.1.1 QCP-w: certificate policy for European Union (EU) qualified website authentication certificates OID: 0.4.0.194112.1.4 - *Website authentication certificates,* under Organisation Validation Policies (OV): | **Type of *Certificate*** | **Reference / Policy OID** | |---------------------------|----------------------------| | *OV Certificate* | 1.3.6.1.4.1.5734.3.16.2.1 | | *OV Wildcard Certificate* | 1.3.6.1.4.1.5734.3.16.2.2 | | *OV SAN Certificate* | 1.3.6.1.4.1.5734.3.16.2.3 | Policy reference OIDType of certificate OV These OV certificates have the following associated policies: Organizational Validation Certificate Policy (OVCP) OID: 0.4.0.2042.1.7 Organization identity Validation OID: 2.23.140.1.2.2 ## 1.3. PKI participants 10. The following parties are involved in the management and use of the *Trust Services* described in this *Policies and Practices Statement*: 1. Certification Authority 2. Registration Authority 3. *Certificate* subscribers or holders 4. Trusting parties 5. Other participants ### 1.3.1. Certification Authority 11. The FNMT-RCM is the *Certification Authority* that issues the electronic Certificates included in the present *CP/CPS*. *Certification Authorities* are as follows: 1) Root Certification Authority. This authority exclusively issues *Certificates* for Subordinate Certification Authorities. This CA’s root certificate is identified by the following information:

Table 1 - AC RAIZ FNMT-RCM SERVIDORES SEGUROS Certificate
AC RAIZ FNMT-RCM SERVIDORES SEGUROS Certificate
Subject CN = AC RAIZ FNMT-RCM SERVIDORES SEGUROS, ORG_ID = VATES-Q2826004J, OU = Ceres, O = FNMT-RCM, C = ES
Issuer CN = AC RAIZ FNMT-RCM SERVIDORES SEGUROS, ORG_ID = VATES-Q2826004J, OU = Ceres, O = FNMT-RCM, C = ES
Serial number (hex) 62:F6:32:6C:E5:C4:E3:68:5C:1B:62:DD:9C:2E:9D:95
Validity

Not before: 20 December 2018

Not after: 20 December 2043
Public key length ECC P-384 bits
Signature algorithm Sha384ECDSA
Key identifier 01 B9 2F EF BF 11 86 60 F2 4F D0 41 6E AB 73 1F E7 D2 6E 49
2) Subordinate Certification Authorities: Issue the end entity *Certificates* covered by this *CP/CPS.* The certificates of these Authorities are identified by the following information:

Table 2 - Subordinate AC SERVIDORES SEGUROS TIPO1 Certificate (EV certificates)
Subordinate AC SERVIDORES SEGUROS TIPO1 Certificate (EV certificates)
Subject CN = AC SERVIDORES SEGUROS TIPO1, ORG_ID = VATES-Q2826004J, OU = Ceres, O = FNMT-RCM, C = ES
Issuer CN = AC RAIZ FNMT-RCM SERVIDORES SEGUROS, ORG_ID = VATES-Q2826004J, OU = Ceres, O = FNMT-RCM, C = ES
Serial number (hex) 50:89:86:CD:B4:17:0E:FE:5C:1B:6B:D5:C8:24:EB:5B
Validity

Not before: 20 December 2018

Not after: 20 December 2033
Public key length ECC P-384 bits
Signature algorithm Sha384ECDSA
Key identifier 8C 42 32 40 F9 79 3F 6B 13 C1 75 C6 5D EE 86 22 44 39 6F 77

Table 3 - Subordinate AC SERVIDORES SEGUROS TIPO2 Certificate (OV certificates)
Subordinate AC SERVIDORES SEGUROS TIPO2 Certificate (OV certificates)
Subject CN = AC SERVIDORES SEGUROS TIPO2, ORG_ID=VATES-Q2826004J, OU = Ceres, O = FNMT-RCM, C = ES
Issuer CN = AC RAIZ FNMT-RCM SERVIDORES SEGUROS, ORG_ID = VATES-Q2826004J, OU = Ceres, O = FNMT-RCM, C = ES
Serial number (hex) 13:8E:6B:BE:DF:20:F5:94:5C:1B:6C:F6:29:B4:2F:4A
Validity

Not before: 20 December 2018

Not after: 20 December 2033
Public key length ECC P-384 bits
Signature algorithm Sha384ECDSA
Key identifier C5 F2 05 4E F4 37 72 E4 EA 4F 02 57 03 FD 86 96 05 AE 50 8F

Table 4 – Subordinate AC SERVIDORES SEGUROS TIPO 1 G2 (EV certificates)
Subordinate AC SERVIDORES SEGUROS TIPO 1 G2 (EV certificates)
Issuer CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS,ORG_ID=VATES-Q2826004J,OU=Ceres,O=FNMT-RCM,C=ES
Serial number (hex) 13:0B:09:E0:F3:C7:40:39:77:07:B9:6F:9C:FB:3F:38:E8:57:31:79
Validity

Not before: 16 December 2025

Not after: 14 December 2035
Public key length ECC P-384 bits
Signature algorithm Sha384ECDSA
Key identifier 73 9A 95 1C 31 89 30 5B 8C 37 18 AC 72 BD 40 76 92 C5 DF B7
Subject CN=AC SERVIDORES SEGUROS TIPO1 G2, ORG_ID=VATES-Q2826004J,O=FNMT-RCM,C=ES

Table 5 – Subordinate AC SERVIDORES SEGUROS TIPO 2 G2 (OV certificates )
Subordinate AC SERVIDORES SEGUROS TIPO 2 G2 (OV certificates)
Subject CN=AC SERVIDORES SEGUROS TIPO2 G2,ORG_ID=VATES-Q2826004J,O=FNMT-RCM,C=ES
Issuer CN = AC RAIZ FNMT-RCM SERVIDORES SEGUROS, ORG_ID = VATES-Q2826004J, OU = Ceres, O = FNMT-RCM, C = ES
Serial number (hex) 68:7B:08:83:1A:DD:AC:39:CC:28:23:F0:40:1B:32:E7:FD:A0:11:56
Validity

Not before: 16 December 2025

Not after: 14 December 2035
Public key length ECC P-384 bits
Signature algorithm Sha384ECDSA
Key identifier 42 4A 37 E8 44 AC EC 39 6D 35 98 E1 AA 16 2F D8 08 A7 DA 31
3) G2R Root Certification Authority. This authority exclusively issues *Certificates* for Subordinate Certification Authorities. This CA’s root certificate is identified by the following information:

Table 6 –AC RAÍZ FNMT-RCM SERVIDORES SEGUROS G2R
AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R
Subject CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R,O=FNMT-RCM,C=ES
Issuer CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R,O=FNMT-RCM,C=ES
Serial number (hex) 2A:0E:1C:A4:D4:B6:84:F8:A8:5A:03:C0:7F:48:41:74:E6:69:CF:40
Validity

Not before: 16 December 2016

Not after: 12 December 2040
Public key length RSA 4096 bits
Signature algorithm Sha384 with RSA
Key identifier 23 82 54 54 30 61 4C A0 4E 81 B9 83 88 F2 CA 05 F6 19 B8 9B
4) G2R Subordinate Certification Authorities: Issue the end entity *Certificates* covered by this *CP/CPS.* The certificates of these Authorities are identified by the following information:

Table 7 –Subordinate AC SERVIDORES SEGUROS TIPO 2 G2R (OV certificates)
Subordinate AC SERVIDORES SEGUROS G2R (OV certificates)
Issuer CN=AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R, O=FNMT-RCM, C=ES
Serial number (hex) 7C:B7:F3:E7:FC:87:5B:54:76:5C:06:21:FB:55:FB:8D:2E:84:C7:D1
Validity

Not before: 16 December 2025

Not after: 14 December 2035
Public key length RSA 4096 bits
Signature algorithm Sha384 with RSA
Key identifier 1E 47 88 D6 39 AB 38 CD D6 C1 B1 7B 4C 35 91 DA 10 0E 16 A9
Subject CN=AC SERVIDORES SEGUROS TIPO2 G2R, ORG_ID =VATES-Q2826004J, O=FNMT-RCM, C=ES
### 1.3.2. Registration Authority 12. The FNMT-RCM is the only *Registry Authority* that acts in the process of issuing these types of *Certificates.* It performs identification and verification tasks, with the main purpose of ensuring that the *Certificate* is issued to the *Subscriber* with control of the domain name that is incorporated into the *Certificate.* None of the verifications on identity or domain validation will be delegated. ### 1.3.3. Subscribers 13. *Subscribers* are the legal entities to whom this type of *Certificate* is issued and who are legally bound by an agreement that describes the terms of use of the *Certificate.* 14. For *Electronic Venue certificates,* the *Subscriber* would be the public administration, group, public body or legal public entity that has control of the domain name of the *Electronic Venue*. ### 1.3.4. Relying parties 15. Trusting parties are those Internet users who establish connections to websites through the use of TLS/SSL protocols that incorporate these types of *Certificates* and decide to trust them. ### 1.3.5. Other participants 16. Not stipulated. ## 1.4. Certificate usage ### 1.4.1. Appropriate certificate Uses 17. Certificates issued under this *Certification Policy* are considered valid as a means by which the person who visits a website is guaranteed of the fact that exists an authentic and legitimate entity, the FNMT-RCM, that supports the existence of said website. 18. Additionally, *Electronic Venue certificates* are a subset of *Website authentication certificates*, which are issued as identification systems for *Electronic Venues* and that guarantees secure communication with it, under the terms defined in Act 40/2015 of 1 October, of Legal Regime of the Public Sector and in Act 18/2011, of 5 July, governing the use of information and the communication technologies in the Department of Justice. 19. All *Website authentication certificates* with Extended Validation (EV) policies issued under this *Certification Policy* are considered to be *Qualified Certificates* in accordance with Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 2014 relating to electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93 (eIDAS Regulation) and in accordance with the requirements established in the European standards ETSI EN 319 411-2 “Requirements for trust service providers issuing EU certificates” and ETSI EN 319 412-4 “Certificate profile for web site certificates”. ### 1.4.2. Prohibited certificate uses 20. If a *User Entity* or a third party wishes to rely on these *Certificates* without accessing the *Information and consultation service* regarding the validity status of the certificates issued under this *Certification Policy,* coverage of these *Particular Certification Practices and Policies* shall not apply, and there will be no grounds to make any type of claim or take legal action against the FNMT-RCM for damages, loss, or conflicts arising from the use of or reliance on a *Certificate.* 21. The FNMT-RCM prohibits the use of the *Certificates* issued under this *CP/CPS* for the illegal interception or decryption of encrypted communications (MITM), deep packet inspection (DPI), etc. 22. These types of *Certificates* may not be used to: - Sign a different *Certificate*, unless specific prior authorisation is obtained. - Sign software or components. - Generate *time stamps* for *electronic dating* procedures. - Provide services for free or for consideration, unless specific prior authorisation is obtained, that include but are not limited to: - Provision of *OCSP* services. - Generation of *Revocation Lists*. - Provision of notification services ## 1.5. Policy administration ### 1.5.1. Organization administering the document 23. The Fábrica Nacional de Moneda y Timbre - Real Casa de la Moneda, bearer of tax identification number Q2826004-J, is the *Certification Authority* issuing the certificates to which this *Statement of Certification Practices and Policies* applies*, and is* responsible for its maintenance ### 1.5.2. Contact person 24. The FNMT-RCM’s contact address as a *Trust Service Provider* is as follows: > Fábrica Nacional de Moneda y Timbre - Real Casa de la Moneda > > Directorate of Information Systems - CERES Department > > C/ Jorge Juan, 106 > > 28071 – MADRID > > E-mail: > > Telephone: +34 91 740 69 82 25. To report security issues such as suspected key compromise, certificate misuse, fraud or other matters, send us Certificate Problem Report to ### 1.5.3. Person determining General Statement suitability for the policy 26. The FNMT-RCM's Management has capacity to specify, revise and approve the review and maintenance procedures both for the Specific Certification Practices and the relevant Certification Policy. ### 1.5.4. General Statement approval procedure 27. The FNMT-RCM manages its certification services and issues certificates in accordance with the latest version of the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”, established by the CA/Browser forum, which can be viewed at the following address: [https://cabforum.org/baseline-requirements-documents.](https://cabforum.org/baseline-requirements-documents/) 28. The FNMT-RCM reviews its certification policies and practices and annually update this Statement of Certificates Policy in order to keep it in line with the latest version of those requirements, increasing the version number and adding a dated change log entry, even if no other changes were made to the document. 29. Updates to CP or CPS documents are made available by publishing new versions at https:// ## 1.6. Definitions and acronyms ### 1.6.1. Definitions 30. For the purposes of this *CP/CPS*, when the terms begin with a capital letter and are in italics, the definitions in the following section shall be taken into account: - *CAA records:* Certification Authority Authorisation (CAA) Domain Name System (DNS) resource record. This allows a DNS domain name holder to specify the Certification Authorities (CA) authorised to issue certificates for that domain. The publication of the CAA resource records allows a domain name holder to implement additional controls in order to reduce the risk of unauthorised issuance of a *Website Authentication Certificate* for their domain name. *- Certificate Transparency (CT):* this is an open framework for the supervision of *Website authentication certificates*, so that when one of these *Certificates* is issued, it is published in CT registry, thus enabling domain owners to monitor the issuance of them for their domains and detect erroneously issued *Certificates.* *- Certification Practices Statement (DPC):* Declaration made available to the public in an easily accessible form, electronically and free of charge by the FNMT-RCM. This is considered a security document in which, within the eIDAS framework, the obligations that *Trust Service Providers* undertake to comply with in relation to the management of the *Signature creation and verification data* and the *Electronic certificates* are detailed, as well as conditions applicable to the application, issuance, use and termination of the validity of the Certificates, the technical and organizational security measures, the profiles and the information mechanisms on the validity of the *Certificates.* - *Certificate Problem Report (CPR)*: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates. - *Electronic Venue:* *Website* available to citizens through telecommunication networks, whose ownership corresponds to a Public Administration, or to one or several public bodies or entities of Public Law in the exercise of the powers granted to them. - *Electronic Venue certificate EV:* EV certificate that identifies an Electronic Venue, guaranteeing secure communication with it under the terms defined in Act 40/2015 of 1 October, on the Legal Regime of the Public Sector. > *- EV Certificate: Website authentication certificate* that contains > validated information of its *Holder* in accordance with the procedure > of exhaustive validation as outlined in the requirements of the “Guide > for the issuance and management of Extended Validation Certificates” > established by the CA/Browser Forum entity, and that can be found at > the following address > > \- *EV SAN Certificate: EV certificate* that incorporates a set of > domains independent of each other. - *Multi-Perspective Issuance Corroboration*: A process by which the determinations made during domain validation and CAA checking by the Primary *Network Perspective* are corroborated by other *Network* *Perspectives* before *Certificate* issuance. - *Network Perspective*: Related to *Multi-Perspective Issuance Corroboration*. A system (e.g., a cloud-hosted server instance) or collection of network components (e.g., a VPN and corresponding infrastructure) for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a *Network Perspective* is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective. > \- *Non-Reserved LDH Label:* From RFC 5890: “The set of valid LDH > labels that do not have ‘–’ in the third and fourth positions.” > > *- OV Certificate: Certificate of web site authentication* issued > according to the Organisation Validation Policy (OVCP), reasonably > guaranteeing to users of Internet browsers that the owner of the > website that they are accessing matches with the Organisation > identified by the *OV Certificate.* This *Certificate* complies with > the requirements of the European standard ETSI EN 319 411-1 “Policy > and security requirements for Trust Service Providers issuing > certificates; Part 1: General requirements”. > > \- *OV SAN Certificate: OV certificate* that incorporates a set of > domains independent from each other. > > \- *OV Wildcard Certificate: OV Certificate* that incorporates a set > of unlimited subdomains, starting from the third level, with a unique > *Website Authentication Certificate.* > > *- P-Label:* A XN-Label that contains valid output of the Punycode > algorithm (as defined in RFC 3492, Section 6.3) from the fifth and > subsequent positions*.* - *Representative of the Registry Office (only applicable for Electronic Venue certificates):* Individual appointed by the representative of the Public Administration, public body or public legal entity, under whose responsibility the tasks assigned to the *Registry Office* are performed with the obligations and responsibilities assigned in these *Special Certification Policies and Practices*. - *Representative of the Subscriber*: the legal person, or person authorised by the Subscriber, of the *Subscriber* organisation of the *Website Authentication Certificate,* for the request and use of said *Certificate.* > *- Certification Practices and Policies Statement (CPS):* Private CPS > that applies to the issuance of a specific set of *Certificates* > issued by the FNMT-RCM under the particular conditions included in > said Declaration, and that are subject the particular Policies defined > therein. > > \- *Supervisory body*: body designated by a Member State as being > responsible for supervisory functions in the provision of trust > services, in accordance with the provisions contained in Article 17 of > the eIDAS Regulation. In Spain, this is currently the Ministry for > Digital Transformation and Public Service.. - *Staff serving the Public Administration:* Officials, staff, statutory staff and authorised personnel, at the service of the Public Administration, group, public body or legal public entity. - *Subscriber:* Legal entity, group or public body that is the recipient of the activities of the FNMT-RCM as Trust Service Provider, which subscribes to the terms and conditions of the service. Under the current *Certification Policies*, this service consists of the issuance of *Website authentication certificates.* The *Subscriber* is referenced in the *Subject* field of the *Certificate* and is the owner and responsible for its use, and maintains exclusive control and the decision-making capacity over it. > *- Website Authentication Certificate:* This is a Certificate that > allows for the authentication of a website and links it with the > individual or legal entity to whom the *Certificate* has been issued. ### 1.6.2. Acronyms 31. For the purposes of the provisions contained in this *CP/CPS*, the following acronyms shall be applicable, with meaning is in accordance with the European standard ETSI EN 319 411 “Policy and security requirements for Trust Service Providers issuing certificates”: > **CA:** Certification Authority > > **RA:** Registration Authority > > **ARL:** Certification Authority Revocation List > > **CN:** Common name > > **CRL:** *Certificate* Revocation List > > **DN**: Distinguished name > > **DPC**: Certification Practices Statement > > **ECDSA:** **Elliptic Curve Digital Signature Algorithm** > > **elDAS:** Regulation 910/2014 of the European Parliament and of the > Council of 23 July 2014 on electronic identification and trust > services for electronic transactions in the internal market and > repealing Directive 1999/93/EC. > > **EV:** Extended validation > > **ETSI:** European Telecommunications Standards Institute > > **FQDN**: Fully-Qualified Domain Name > > **HSM:** Hardware security module. This is a security device that > generates and protects cryptographic keys. > > **OCSP:** Online Certificate Status Protocol > > **OID**: Object Identifier > > **OV:** Organisational validation > > **PDS:** PKI disclosure statement > > **PIN**: Personal identification number > > **PKCS:** Public key cryptography standards > > **PKI:** Public Key Infrastructure > > **TLS**/**SSL**: Transport Layer Security/Secure Socket Layer protocol > TSP: > > **UTC**: Coordinated Universal Time # 2. Publication and repositories responsibilities ## 2.1. Repository 32. The FNMT-RCM, as a *Trust Service Provider*, has a repository of public information available 24x7, every day of the year, with the characteristics indicated in the following sections and with access using the address: ## 2.2. Publication of information 33. The information regarding the issuance of electronic *Certificates* subject to this *CP/CPS* which is accessible through , includes the following information: - Certification Practices and Policies Statement - *Certificate profiles* and *Revocation lists*. - PKI Informative statements (PDS). - The terms and conditions of use of the *Certificates*, as a legally binding instrument. 34. This “Certification Practices and Policies Statement” is structured in accordance with RFC 3647 and include all material required by RFC 3647. 35. The FNMT-RCM conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates and the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates both published at . In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document. 36. The FNMT-RCM host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. The FNMT-RCM host separate Web pages using Subscriber Certificates that are i. valid, ii. revoked, and iii. expired. 37. In addition, it is possible to download of the Root Certificates and subordinate CAs of the FNMT-RCM, as well as additional information, at the following address: [https://www.sede.fnmt.gob.es/descargas](https://www.sede.fnmt.gob.es/descargas/) ## 2.3. Time of frequency of publication 38. The FNMT-RCM will review its certification policies and practices and annually review and update the present *CP/CPS*, following the guidelines established in section “1.5.4. DPC Approval Procedure” of this *CP/CPS* document. 39. Any amendment to the *Certification Policies and Practices* will be immediately published in the URL where they may be accessed. ## 2.4. Access controls on repositories 40. All the above-mentioned repositories are freely accessible for information consultation and, if applicable, download purposes. Moreover, the FNMT-RCM has put in place controls to prevent unauthorised persons from adding, altering or deleting information included in its repositories and to protect the authenticity and integrity of the information. # 3. Identification and authentication ## 3.1. Naming 41. The coding of *Certificates* follows the RFC 5280 standard “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”. All the fields defined in the profile of the *Certificates* profile in the *Special Certification Policies and Practices* use UTF8String coding, except in fields that specifically express otherwise. 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.1. Types of names 43. End-user electronic *Certificates* as covered in this *CP/CPS* contain a distinguished name (DN) in the Subject Name field, composed in accordance with the information relating to the Certificate profile (section 7.1 of this document). FNMT-RCM complies with X.500, RFC 5280 and CA/Browser Forum requirements for naming. 44. The Common Name field specifies the holder of the *Certificate.* ### 3.1.2. Need for names to be meaningful 45. All distinguished names (DN) of the Subject Name field are denotative. Names in the *Certificates* identify respectively the *Subject* and the *Issuer*.The description of the attributes associated with the *Certificate Subscriber* is provided in human-readable form (see section 7.1.4 Name format of this document). 46. Wildcard Certificates are not allowed for EV Certificates ### 3.1.3. Anonymity or pseudonymity of subscribers 47. The FNMT - RCM does not permit the use of pseudonyms under this *Certification Policy.* ### 3.1.4. Rules used to interpreting various name forms 48. The requirements defined by the X.500 reference standard apply in the ISO/IEC 9594 standard. ### 3.1.5. Uniqueness of names 49. The distinguished name (*DN*) assigned to the *Certificate Subscriber* inside the *Trust Service Provider’s* domain will be unique. ### 3.1.6. Recognition, authentication, and role of trademark 50. Subscribers may not request Certificates with any content that infringes the intellectual property rights of a third party*.* 51. The FNMT–RCM makes no commitment whatsoever regarding the use of distinctive signs, whether registered or otherwise, in the issuance of *Certificates.* *Certificates* including distinctive signs may only be requested when the *Holder* owns the right of use or is authorised to use the sign. The FNMT–RCM is not obligated to previously verify the ownership or registration of the distinctive signs before issuing the *Certificates,* even if they are entered in public registers. ## 3.2. Initial identity validation 52. The FNMT-RCM performs the validation process on the information included in the *Website authentication certificate* in accordance with the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”, established by the CA/Browser forum, which may be viewed at the following address: https://cabforum.org/baseline-requirements-documents. 53. In addition, the FNMT-RCM, before issuing an *EV Certificate, SAN EV Certificate* or *Electronic Venue* c*ertificate*, 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/](https://cabforum.org/extended-validation/%20) 54. The FNMT-RCM records all confirmations performed in this section for both internal an independent audits processes. ### 3.2.1. Methods to prove possession of the private key 55. The FNMT-RCM receives a C*ertificate* request, in PKCS \#10 format, digitally signed by the *Private key* generated by the *Subscriber's Representative* in its environment. Prior to proceeding with the issuance of the *Certificate*, the FNMT-RCM verifies this signature, guaranteeing that the *Public key* included in the request corresponds to the *Private key* generated by the *Party responsible for the certificate.* ### 3.2.2. Authentication of Organization and domain identity 56. This section disclosures the FNMT-RCM’s processes during the Identification and Authentication steps within the Registration. All the documentation mentioned here will be inspected to avoid any indication of alteration or falsification. #### 3.2.2.1 Identity 57. The FNMT-RCM verifies the legal existence, address and identity of the Certificate’s subscribing organisation through different methods, depending on the type of organisation (private, public or business). 58. In cases where the *Subscriber* is a private entity, its identity and address, which is legally recognised, active at that moment, and formally registered, will be verified by direct consultation by the RA of the FNMT-RCM using service that the Mercantile Registry provides for this purpose. 59. For cases of public entities, such verifications will be carried out by direct consultation of the RA of the FNMT-RCM of the inventory of public sector entities contained at the General Intervention Board of the State Administration, under the Ministry of Finance, or in the corresponding Official Gazette. 60. If the nature of the *Subscriber* is different from the two previous examples, verifications related to its legal capacity, identity and address will be made by direct consultation with the corresponding official registry. 61. The list of Incorporating Agencies or Registration Agencies is published in the Legal Repository on FNMT-RCM’s website (https://www.cert.fnmt.es/registro/utilidades). 62. The FNMT-RCM does not issue *Website authentication certificates* for *Subscribers* who are individuals. 63. The FNMT-RCM verifies that the name, address and tax identification number of the subscribing organisation of the *Certificate* included in the request matches with the name, address and tax identification number formally registered in the records consulted as described in the previous sections. 64. 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 65. If the Subject Identity information includes a DBA or tradename, the FNMT-RCM will use the same verification procedures and criteria as in Section 3.2.2.1 to verify the Applicant’s right to use the DBA/tradename. 66. For *EV Certificate* requests extensive identity verification as defined in the CAB Forum’s EV Guidelines section 11.3 are required. #### 3.2.2.3 Verification of country 67. The countryName is verified using any method in Section 3.2.2.1 #### 3.2.2.4 Validation of Domain Authorization or Control 68. In order to validate *Website authentication certificate* domains (FQDN), the FNMT-RCM uses the following method described in the CA/Browser Forum's Baseline Requirements document: “3.2.2.4.7 DNS Change “. For this method, FNMT-RCM will follow a documented process and maintain records noting the method used for each issuance, including the version number of CA/Browser Forum's Baseline Requirements version used for the validation process. The rest of methods described in the CA/Browser Forum's Baseline Requirements document are not used. - 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. Performed in accordance with the CA/Browser Forum's Baseline Requirements Section 3.2.2.4.7, including Multi-Perspective Corroboration. FNMT-RCM shall provide a Random Value unique to the certificate request and shall not use the Random Value after (i) 30 days. 69. The FNMT-RCM confirms that the *Subscriber's Representative* has control over the full domain names, or FQDN (Fully Qualified Domain Name) that are incorporated into the *Website authentication certificates* that it issues. For such purpose, the FNMT-RCM consults the identity of the *Subscriber's Representativ*e and the name of the aforementioned FQDN, through the program that registers the applications of these Certificates. Next, it is verified that the request originates from the contact with control over said domain (according to the methods defined in the previous section), or has received authorisation from it. Additionally, it is verified that the request for the *Certificate* has been made subsequent to its registration in the corresponding registries. 70. As specified in the CA/Browser Forum's Baseline Requirements, DNSSEC validation back to the IANA DNSSEC root trust anchor is performed on all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with the validation of domain authorization or control by the Primary Network Perspective: 1. performs DNSSEC validation using the algorithm defined in RFC 4035 Section 5; and 2. supports NSEC3 as defined in RFC 5155; and 3. supports SHA-2 as defined in RFC 4509 and RFC 5702; and 4. properly handles the security concerns enumerated in RFC 6840 Section 4. 71. FNMT-RCM does not use any local policy to disable DNSSEC validation on any DNS query associated with the validation of domain authorization or control. 72. DNSSEC validation back to the IANA DNSSEC root trust anchor is considered outside the scope of the logging requirements of Section 5.4.1 73. Furthermore, before 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) and public records are consulted to verify that it is not a high risk domain (for example, the Google registry created for this purpose, or the Safe Browsing site status). #### 3.2.2.5 Authentication for an IP address 74. *Certificates* that identify IP addresses are not issued under these policies. #### 3.2.2.6 Wildcard domain validation 75. The entire Domain Namespace in wildcard *Certificates* must be rightfully controlled by the *Subscriber* 76. If a wildcard *Certificate* would fall within the label immediately to the left of a registry-controlled or public suffix, the FNMT-RCM will refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace (e.g. CAs MUST NOT issue “\*.co.uk” or “\*.local”, but MAY issue “\*.example.com” to Example Co.). To perform such verification, the AR will use the public list of suffixes available in https://publicsuffix.org/ which will be retrieved regularly. #### 3.2.2.7 Data source accuracy 77. Prior to using any data source as a Reliable Data Source, the RA shall evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. #### 3.2.2.8 CAA records 78. FNMT-RCM checks to confirm that there is a CAA Record for each domain name that it includes in any Website authentication certificate, in accordance with the procedure established under the terms of RFC 8659 and following the processing instructions set forth in RFC 8659 for any record may be found. In the event that such CAA Record exists, the "issue", "issuewild" and “iodef” fields are processed. The domain identifier recognized as its own associated with the FNMT Certification Authority is set to "fnmt.es". The FNMT will not issue the Certificate if a label from another FNMT Certification Authority appears in the aforementioned fields or if there is an unrecognized property tag with the critical flag set. FNMT-RCM supports only the URL schemes “mailto:” and “https:” in the “iodef” record. The applicant must modify the data in the CAA record of its domain so that FNMT-RCM can issue the certificate. 79. After processing a CAA record, FNMT-RCM will issue the *Certificate* in less than 8 hours. 80. FNMT-RCM will document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CA/Browser Forum. #### 3.2.2.8.1 DNSSEC Validation of CAA Records 81. As specified in the CA/Browser Forum's Baseline Requirements, DNSSEC validation back to the IANA DNSSEC root trust anchor is performed on all DNS queries associated with CAA record lookup performed by the Primary Network Perspective. The DNS resolver used for all DNS queries associated with CAA record lookup performed by the Primary Network Perspective: 1. performs DNSSEC validation using the algorithm defined in RFC 4035 Section 5; and 2. supports NSEC3 as defined in RFC 5155; and 3. supports SHA-2 as defined in RFC 4509 and RFC 5702; and 4. properly handles the security concerns enumerated in RFC 6840 Section 4. 82. FNMT-RCM does not use any local policy to disable DNSSEC validation on any DNS query associated with CAA record lookup. 83. FNMT-RCM will not treat DNSSEC-validation errors observed by the Primary Network Perspective as permission to issue. 84. This DNSSEC validation is considered outside the scope of self-audits of section 8.7. #### 3.2.2.9 Multi‑Perspective Issuance Corroboration 85. *Multi-Perspective Issuance Corroboration* attempts to corroborate the determinations (i.e., domain validation pass/fail, CAA permission/prohibition) made by the Primary *Network* *Perspective* from multiple remote *Network Perspectives* before *Certificate* issuance. 86. FNMT-RCM uses the same set of *Network Perspectives* when performing *Multi-Perspective Issuance Corroboration* for the required 1) Domain Authorization or Control and 2) *CAA Record* checks. 87. The set of responses from the relied upon *Network Perspectives* provides FNMT-RCM with the necessary information to allow it to affirmatively assess: 1. The presence of the expected Random Value, as required by the relied upon validation method specified in Section 3.2.2.4 of this *CP/CPS*; and 2. the FNMT-RCM’s authority to issue to the requested domain(s), as specified in Section 3.2.2.8. 88. A Network Perspective may use a recursive DNS resolver that is not co-located with the Network Perspective but fall within the same Regional Internet Registry service region as the Network Perspective relying upon it. Furthermore, for any pair of DNS resolvers used on a Multi-Perspective Issuance Corroboration attempt, the straight-line distance between the two DNS resolvers is at least 500 km. 89. FNMT-RCM rely upon networks implementing measures to mitigate BGP routing incidents. 90. For more information, see the CA-Browser Forum TLS Baseline Requirements. ### 3.2.3. Authentication of the individual identity 91. The RA of the FNMT-RCM verifies that the *Subscriber Representative* matches with the individual requesting a *Website authentication certificate*, by means of the electronic signature of the application form using a verified Certificate of electronic signature, thus guaranteeing the authenticity of their identity. ### 3.2.4. Non-verified subscriber information 92. All the information incorporated into the electronic *Certificate* is verified by the *Registration Authority,* therefore, it does not include unverified information in the “Subject” field of the certificates issued. ### 3.2.5. Validation of Authority 93. The RA of the FNMT-RCM verifies that the *Applicant* has been granted sufficient representation capacity through the electronic signature of the application form, as described in section 3.2.3 of this *CP/CPS*, accepting the use of a qualified *Certificate* of sole or joint administrator representative of the subscribing legal person or a qualified *Certificate* of *Personnel at the service of the Public Administration*, for whose issuance the capacity of representation has been accredited. 94. When the aforementioned form is signed by a qualified *Certificate* different from those mentioned in the previous section, the RA of the FNMT-RCM is able to verify the power of representation of the signatory of the request by consulting official records (Commercial Registry, Official Gazettes, etc., depending on the nature of the representation). In the event that the results of these consultations do not provide sufficient evidence of representation, the RA of the FNMT-RCM will contact the *Subscriber* to collect such evidence. 95. For Extended Validation requests, FNMT-RCM shall verify this authority using the procedures described in the EV Guidelines. (sections 3.2.2.8 and 3.2.2.11) ### 3.2.6. Criteria for interoperation or certification 96. There are no interoperational relationships with Certification Authorities external to FNMT-RCM. ## 3.3. Identification and authentication for re-key requests ### 3.3.1. Identification and authentication for routine re-key 97. *Certificate* Subscribers should request any corresponding re-key prior to the expiration of their period of validity. The authentication conditions for renewal requests are covered in the section of this *CP/CPS* corresponding to *Certificate* renewal processes (see section 4.6 of this document). ### 3.3.2. Identification and authentication for re-key after revocation 98. The FNMTRCM do not renew Certificates that have been revoked. The process for the re-key of a *Certificate* after its revocation is the same as that which is followed in the initial issuance of said *Certificate.* ## 3.4. Identification and authentication for revocation requests 99. The conditions for authentication of a revocation request are covered in the section of this *CP*/*CPS* corresponding to the *Certificate* revocation process (see section 4.9 of this document). # 4. Certificate life-cycle operational requirements ## 4.1. certificate Application ### 4.1.1. Who can submit a certificate application 100. Only *Subscriber* representatives *or* individual duly authorized to request *Certificates* on behalf of the applicant, who have demonstrated control over the name of the domain to be included in the *Certificate* are able to request *Website authentication certificates.* The aforementioned control over the domain name will be verified by the FNMT-RCM as described in section “3.2 Initial Validation of Identity” contained in this *CP/CPS*. 101. 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.1.2. Enrolment process and responsibilities 102. The FNMT-RCM require each Applicant to submit a Certificate request and application information prior to issuing a Certificate. The FNMT-RCM authenticates all communication from an Applicant and protects communication from modification. 103. The enrollment process includes: - Submitting a complete Certificate application and agreeing to the applicable subscription agreement. By executing the subscription agreement, *Subscribers* warrant that all of the information contained in the Certificate request is correct. - Generating a key pair, - Delivering the public key of the key pair to the CA and - Paying any applicable fees. 104. The RA of the FNMT-RCM performs the verification of the identity of the subscribing Organisation and of the *Subscriber Representative*, and verifies that the application for the Certificate is both correct and duly authorised, in accordance with the requirements contained in section “3.2 Initial Validation of identity” of this document. The FNMT-RCM may carry out additional verification on the validation processes described in the aforementioned section. 105. FNMT-RCM will collect the evidence corresponding to the verifications made, which will be stored in a repository. 106. Section 9.6 “Representation and warranties” of this document establishes the responsibilities of the parties involved in this process. ## 4.2. Certification application processing ### 4.2.1. Performing identification and authentication functions 107. The *Subscriber Representative* sends a form to the RA of the FNMT-RCM, electronically signed with a qualified electronic *Certificate*, which contains all of the information to be included in the *Website authentication certificate.* Based on this information, the RA of the FNMT-RCM performs all of the checks described in the section "3.2 Initial Validation of Identity,” of this *CP/CPS,* such as*:* 1. Verify whether the *Applicant* is authorized to obtain the *Certificate*. 2. Corroborate the Applicant’s identity, and, if needed, the associated organization’s identity, including name, address and DBA/commercial name, according to sections 3.2.2.1 and 3.2.2.2. 3. Obtain the *public* *Key* and verify the possession of the *Private* *key* created by the *Applicant* 4. Verify that any agent who submits a *Certificate* application is duly authorized to request these *Certificates* 108. The FNMT-RCM will verify the accuracy of the data included in the application and, if applicable, the capacity of the *Representative* by means of the corresponding verifications and by providing the appropriate evidence. 109. The electronic signature generated to sign contract will be verified by the FNMT-RCM. 110. Applicant information will include, but not be limited to, at least one Fully-Qualified Domain Name to be included in the Certificate’s subjectAltName extension**.** 111. Reuse of previous validation data or documentation obtained from a source specified under section 3.2 may be used no more than 398 days after such data or documentation was validated. In no case may a prior validation be reused after this period. 112. Reuse of previously completed domain validation checks (DNS validation) obtained from sources and methods specified under section 3.2.2.4 may be used no more than 200 days after such data or documentation was validated. In no case may a prior validation be reused after this period. ### 4.2.2. Approval or rejection of certificate applications 113. 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. 114. The RA of the FNMT-RM performs all checks related to proof of possession of the *Private key* by the *Subscriber Representative*, authentication of the identity of the Organisation and of the person requesting the *Certificate,* as well as the validation of the domain, as described in the section "3.2 Initial Validation of Identity" of this *CP/CPS*, which will then result in the approval or rejection of the request in question. 115. The FNMT-RCM maintains an internal database of all revoked *Certificates* and all requests for *Certificates* that were previously rejected due to suspected phishing or other forms of fraudulent use. This information is then taken into account to identify subsequent requests for suspicious certificates before proceeding with the approval of the issuance thereof. 116. In addition, the FNMT-RCM also drafts, maintains, and implements documented procedures that identify and require additional verification activity for applications for high-risk Certificates prior to approval of the issuance of a *Certificate*, to the extent that is reasonably necessary to ensure that such requests are properly verified, in accordance with these requirements. 117. If it is not possible confirm any of these validations, the FNMT-RCM will deny the Certificate request, reserving the right not to disclose the reasons for such denial. The *Subscriber Representative* whose request has been denied may appear to present their request in the future. 118. 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. 119. In addition, the FNMT-RCM checks to confirm that there is a CAA Record for each domain name that it includes in any *Website authentication certificate,* in accordance with the procedure established under the terms of RFC 8659 and following the processing instructions set forth in RFC 8659 for any record may be found. In the event that such *CAA Record* exists, no Certificate will be issued unless it is determined that the Certificate request is consistent with the applicable CAA resource record group. The domain identifier recognized for the certification authority of the FNMT is "fnmt.es". 120. The FNMT-RCM does NOT issue certificates containing Internal Names. ### 4.2.3. Time to process certificate applications 121. The amount of time spent processing a Certificate application depends to a large extent on the *Subscriber Representative* providing all necessary information and documentation in the manner specified in the procedures approved by the FNMT-RCM for this purpose. However, this Entity will make all necessary efforts so that the validation process resulting in the acceptance or denial of the request does not exceed a total of two (2) business days. 122. This time period may occasionally be exceeded for reasons beyond the control of the FNMT-RCM. In these cases, the best option is to contact the *Subscriber Representative* who made the request and inquire as to the causes of such delays. ## 4.3. Certificate issuance ### 4.3.1. CA actions during certificate issuance 123. 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.* 124. Likewise, the FNMT-RCM periodically monitors possible deviations in the certificates issued. 125. The FNMT-RCM uses linting tools, such as pkimetal among others, on the certificates and precertificates to prevent or/and reduce the issuance of certificates that fail to comply with the regulations. 126. The processes related to the issuance of electronic *Certificates* guarantee that all the accounts that interact with them include multi-factor authentication. 127. Certificate issuance by the Roots CAs requires an individual authorized by the FNMT-RCM, to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation. ### 4.3.2. Notification of certificate issuance 128. Once the *Certificate* is issued, the FNMT-RCM sends a notice to the e-mail address recorded on the request form signed by the *Subscriber Representative*, stating that the *Certificate* is available for download. ## 4.4. Certificate acceptance ### 4.4.1. Conduct constituting certificate acceptance 129. *Certificate* acceptance is understood when the *Subscriber's* representative: 1. Explicitly accepts the terms of use and expresses their willingness to obtain the *Certificate* during the application process, as a necessary and mandatory condition for its issuance, thereby formally accepting the conditions associated with the applicable certification policy; and 2. Downloads and/or installs the certificate, making it technically available for use ### 4.4.2. Publication of certificate by the CA 130. All *Certificates* drafted are stored in a safe FNMT-RCM storage facility. ### 4.4.3. Notification of certificate issuance by the CA to other entities 131. Prior to the issuance of *Website authentication certificates* a “pre-certificate” is sent for the records of the *Certificate Transparency* service used by those providers with whom the FNMT-RCM maintains an agreement for this purpose. ## 4.5. Key pair and certificate usage ### 4.5.1. Subscriber’s private key and certificate usage 132. The FNMT-RCM does not generate or store any *Private Keys* associated with the *Certificates* issued under this *Certification Policy.* 133. The condition of custody and control of the *Certificate* keys correspond to the *Head of Registry Operations* in the case of the *Electronic Venue certificate* and, for the rest of the *Website authentication certificates*, to the *Subscriber's Representative*s that have demonstrated that they hold control over the name of the domain to be included in the *Certificate.* 134. Therefore, the *Private Key* associated with the *Public Key* will be kept under the responsibility of said custodian, who will act as representative of the Entity with rights to ownership, management and administration of the corresponding electronic address. 135. The Subscriptor will guarantee the Certificate installation/use in the servers or systems accessible by means of the names included in the Certificate’s subjectAltName, and exclusively use the Certificate for the allowed purposes in compliance with this CP/CPS, the deal signed with the FNMT-RCM and legislation applicable. ### 4.5.2. Relaying party public key and certificate usage. 136. Users and relying parties must use software that is compatible with applicable standards for the use of electronic *Certificates* (X.509, IETF, RFCs ...). In the event that any connection to the website requires additional insurance measures, these measures must be obtained by the user entities. 137. Third parties that rely on the establishment of a secure connection guaranteed by a *Website authentication certificate* must make sure that such connection was created during the period of validity of the *Certificate*, that said *Certificate* is being used for the purpose for which it was issued, in accordance with this *CP/CPS,* as well as to verify that the *Certificate* is active at that time, by checking its revocation status in the form and conditions that are expressed in section "4.10 Information services for the status of certificates" of the present document. ## 4.6. Certificate renewal 138. The renewal of a *Certificate* involves the issuance of a new Certificate without changing any information regarding the *Signatory, Public Key* or any other information that appears in it. 139. Under these *Certification Policies*, the FNMT-RCM does not renew *Certificates* keeping the same *Public key,* but, rather, the renewal of Certificates is performed by renewing the *Cryptographic keys*, as defined in section of this document titled “4.7 Renewal with regeneration of the certificate keys”. ### 4.6.1. Circumstances for certificate renewal 140. FNMT-RCM does not renew *Certificates* under these *Certification Policies* maintaining their *Public key*. ### 4.6.2. Who may request renewal 141. FNMT-RCM does not renew *Certificates* under these *Certification Policies* maintaining their *Public key*. ### 4.6.3. Processing certificate renewal requests 142. FNMT-RCM does not renew *Certificates* under these *Certification Policies* maintaining their *Public key*. ### 4.6.4. Notification of new certificate issuance to subscriber 143. FNMT-RCM does not renew *Certificates* under these *Certification Policies* maintaining their *Public key*. ### 4.6.5. Conduct constituting acceptance of a renewal certificate 144. FNMT-RCM does not renew *Certificates* under these *Certification Policies* maintaining their *Public key*. ### 4.6.6. Publication of the renewal certificate by the CA 145. FNMT-RCM does not renew *Certificates* under these *Certification Policies* maintaining their *Public key*. ### 4.6.7. Notification of certificate issuance by the CA to other other entities 146. FNMT-RCM does not renew *Certificates* under these *Certification Policies* maintaining their *Public key*. ## 4.7. certificate re-keys 147. Renewal of *Website authentication certificates* with key regeneration is always done by issuing new public and private keys, following the same process as described for the issuance of a new *Certificate.* ### 4.7.1. Circumstances for certificate re-key 148. *Certificates* shall be re-keyed in the following events: - Where the current keys will expire soon, upon request by the renewal requestor. - Due to key compromise or any other circumstance set out in section “*4.9 Certificate revocation and suspension”* of this *CP/CPS.* ### 4.7.2. Who may request re-key 149. The same process described for the issuance of a new *Certificate* will be followed. ### 4.7.3. Processing certificate re-keying requests 150. The same process described for the issuance of a new *Certificate* will be followed. ### 4.7.4. Notification of certificate re-key 151. The same process described for the issuance of a new *Certificate* will be followed. ### 4.7.5. Conduct constituting acceptance of a re-keyed certificate 152. The same process described for the issuance of a new *Certificate* will be followed. ### 4.7.6. Publication of the re-keyed certificate 153. The same process described for the issuance of a new *Certificate* will be followed. ### 4.7.7. Notification of certificate re-key to other entities 154. The same process described for the issuance of a new *Certificate* will be followed. ## 4.8. Certificate modification 155. No amendments may be made to *Certificates* issued. Consequently, a new *Certificate* must be issued in order for changes to be made. ### 4.8.1. Circumstance for certificate modification 156. The modification is not stipulated. ### 4.8.2. Who may request certificate modification 157. The modification is not stipulated. ### 4.8.3. Processing certificate modification requests 158. The modification is not stipulated. ### 4.8.4. Notification of new certificate issuance to subscriber 159. The modification is not stipulated. ### 4.8.5. Conduct constituting acceptance of modified certificate 160. The modification is not stipulated. ### 4.8.6. Publication of the modified certificate by the CA 161. The modification is not stipulated. ### 4.8.7. Notification of the certificate issuance by the CA to other entities 162. The modification is not stipulated. ## 4.9. Certificate revocation and suspension 163. *Website Authentication certificate*s issued by the FNMT-RCM will cease to be valid in the following cases: 1) Termination of the *Certificate*’s validity period. 2) Discontinuance of the FNMT-RCM’s activities as a *Trust Service Provider* unless, upon express previous consent of the *Subscriber*, the *Certificates* issued by the FNMT-RCM are transferred to a different *Trust Service Provider.* > In these two cases \[a) and b)\], the loss of the *Certificate*’s > effectiveness will occur as soon as the circumstances arise. 3) Revocation of the *Certificate* due to any of the causes stipulated in this document. 164. The revocation of the *Certificate*, i.e. the termination of its validity, will take effect as of the date on which the FNMT-RCM is in possession of certain knowledge of any of the determining events, and such events are recorded by its *Certificate status information and consultation service.* 165. The FNMT-RCM makes trusting third parties, software suppliers, and third parties available to Subscribers by means of communication through the electronic headquarters of the FNMT-RCM with clear instructions, to allow them to report any matter related to this type of Certificates, regarding a supposed compromise of a Private Key, improper use of the Certificates or other types of fraud, compromise, misuse or inappropriate behavior. 166. The FNMT-RCM, as a Trust Service Provider, reserves the right not to issue or to revoke these type of *Certificates* in the event that *Subscribers* with control of the domain name of the website included in the *Certificate* do not make proper use thereof, violating industrial or intellectual property rights of third parties with regard to applications, websites or *Electronic Venues* that are to be protected with such *Certificates*, or in cases where their use is deceptive or confusing as to the ownership of such applications, websites or *Electronic Venues* and, Therefore, of its contents. In particular, such reservation of rights may be carried out by the FNMT-RCM in cases where the use of such *Certificates* is contrary to the following principles: 1) The safeguarding of public order, criminal investigation, public security and national defence. 2) The protection of public health or of individuals who have the status of consumers or users, even when acting as investors. 3) Respect for the dignity of the individual and the principle of non-discrimination based on race, sex, religion, opinion, nationality, disability or any other personal or social circumstance, and 4) Protection of children and youth 167. The FNMT-RCM will be kept harmless by the holders of or those responsible for any equipment, applications, websites or *Electronic Venues* that fail to comply with the provisions of this section and that are related to the *Certificate*, and shall be considered as exempt from any claim or complaint arising from the improper use of such Certificates. ### 4.9.1. Circumstances for Revocation #### 4.9.1.1 Reasons for Revoking a Subscriber Certificate 168. In addition to these provisions, the following will be causes for revocation of a *Website authentication certificate.* 169. Circumstances for revocation will be executed complying with periods of time set in this Certification Practices, taking into account at the same time the upper limits established by the CA/Browser Forum’s Requirements. 170. Also, FNMT-RCM will include in its revocation lists the CRLReason code in compliance with section 7.2.2 CA/Browser Forum. 171. FNMT-RCM shall revoke the Certificate without undue delay and, in any case, within a maximum period of twenty-four (24) hours form the receipt, verification, or identification of any of the following events: 1) The request for revocation by authorised individuals, even if no specific reason is stated. This request may be initiated, among others, for the following case: - Loss of support of the *Certificate.* - Use of the *Private Key* associated with the *Certificate* by a third party. - Any violation or endangerment of the details of the *Private Key* associated with the *Certificate.* - The non-acceptance of new conditions that may imply the issuance of new *Certification Practices Statement*, during the period of one month subsequent to its publication. 2) Judicial or administrative resolution ordering such request. 3) Termination, deletion, or closure of the website identified by the *Certificate.* 4) Extinction or dissolution of the legal personality of the *Subscriber.* 5) Termination of the form of representation of the *Certificate Subscriber* representative. 6) Total or partial supervening lack of capacity of the *Subscriber's* representative. 7) Inaccuracies in the data provided by the *Subscriber's Representative* in order to obtain the *Certificate*, or alteration of any of the data provided to obtain the *Certificate,* or modification of the verified information relating to the issuance of the *Certificate,* so that it is no longer in accordance with reality. 8) Violation of a subst*antial obligation of this Certification Practices Statement by the Subscriber, the Subscriber Representative* or a *Registry Office*, in the event that, in the latter case, this might have potentially affected the procedure for issuing the *Certificate.* 9) Use of the Certificate to create confusion regarding the origin of products or services, including specifically the use of a Wildcard Certificate to authenticate misleading subordinate domains. To do this, the criteria will be followed related to activity in violation of the rules on consumers and users, trade, competition and advertising. 10) Applying, for the Certificate Subject, for distinctive signs, names or other industrial or intellectual property rights where the Subscriber is not their title holder or licensee or is not authorized for their use. 11) Termination of the contract entered into between the *Subscriber* or their *Representative*, and the FNMT-RCM, or any non-payment for services rendered. 12) Violation or endangerment of the secrecy of the FNMT-RCM *Signature/Seal Creation Data*, with which it signs/seals the *Certificates* it issues. 13) Failure to comply with the requirements defined by the audit schemes to which the *Certification Authority* that issues the *Certificates* covered by this *CP/CPS* determines, with special attention to those of algorithms and key sizes, which pose an unacceptable risk to the interests of parties that rely on these *Certificates* 14) Awareness of a demonstrated or proven method that could expose the Subscriber’s Private Key to compromise, including flaws in the key generation method. 15) Notification that the original Certificate request was not authorized and retroactive authorization is not granted. 16) Evidence that the domain authorization or control validation for any Fully-Qualified Domain Name (FQDN) included in the Certificate should not be relied upon. 172. Under no circumstances may it be understood that the FNMT-RCM assumes any obligation whatsoever to verify the factors mentioned in letters c) to i) of this section. 173. FNMT-RCM should revoke a certificate within 24 hours and must revoke a Certificate within 5 days and use the corresponding CRLReason if one or more of the following occurs:: 17) The Certificate no longer meets the cryptographic requirements specified in sections 6.1.5 and 6.1.6 of the CA/B Forum Baseline Requirements. 18) Material non-compliance by the Subscriber with the Subscriber Agreement, Terms of Use, or obligations under this CP/CPS, not involving immediate risk of key compromise or fraud. 19) FNMT-RCM’s right to issue Certificates covered by this CP/CPS expires, is suspended, or revoked, unless continuity of OCSP/CRL services is ensured. 20) External factors beyond the control of the Subscriber or FNMT-RCM (including force majeure, severe technical failure, or security breach) prevent safe use of the Certificate and pose a risk to third parties, without involving direct compromise of the Private Key. 174. The FNMT-RCM shall only be responsible for consequences arising from failure to revoke a Certificate in the following cases: - That the revocation has been requested by the *Subscriber's Representative* following the procedure established for these types of *Certificates*. - That the revocation should have been performed due to the termination of the contract entered into with the *Subscriber.* - That the revocation request or the cause that gives rise to it has been notified by judicial or administrative resolution. - That these facts are convincingly demonstrated in causes c) to g) of this section, prior to identification of the revocation *Applicant.* 175. Any acts constituting a crime, or the lack thereof, of which FNMT-RCM has no knowledge of, committed involving the data contained in a *Certificate, any* inaccuracies regarding the data, or lack of diligence in its communication to the FNMT-RCM, shall result the FNMT-RCM being exempted from any liability. 176. All requests for revocation of end entity *Certificates*, are processed within a maximum period of 24 hours from receipt of the application. #### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate 177. The Issuing CA shall revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs: 1) The Subordinate CA requests revocation in writing; 2) The Subordinate CA notifies the Issuing CA that the original Certificate request was not authorized and does not retroactively grant authorization; 3) The Issuing CA obtains evidence that the Subordinate CA’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of sections 6.1.5 and sections 6.1.6, 4) The Issuing CA obtains evidence that the Certificate was misused; 5) The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with the Baseline Requirements, EV Guidelines, Minimum Requirements for Code Signing or this CP/CPS; 6) The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading; 7) The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate; 8) The Issuing CA’s or Subordinate CA's right to issue Certificates under the Baseline Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; or 9) Revocation is required by the Issuing CA’s CP/CPS. ### 4.9.2. Who can request revocation 178. *CAs, RAs* and *Subscribers* may initiate revocation. 179. Revocation of a *Website authentication certificate* may only be requested by the person with powers of representation of the *Subscriber* to whom the *Certificate* has been issued. 180. In the case of an *Electronic Venue certificate*, the FNMT-RCM shall accept the authority and capacity of the *Applicant* when this corresponds to the *Registry Operations Manager.* In addition, the following shall be considered qualified to request the revocation of said *Certificate:* - The governing body, body or public entity *Subscriber* of the *Certificate,* or the individual delegated for such purpose. - The *Registry Office*, through its representative designated for this purpose, either by the Administration, public entity or body, *Subscriber* of the *Certificate* to be revoked, in such event that it detects that any of the data included in the *Certificate* - is incorrect, or that there is a discrepancy between it and that pertaining to the *Certificate,* or - the individual acting as holder of the *Certificate* does not correspond with the responsible party or that designated for the management and administration of the e-mail address contained in the *Certificate* object of the revocation. always within the framework of the terms and conditions applicable to the revocation of these types of *Certificates.* 181. 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 182. Nevertheless, the FNMT-RCM may officially revoke *Website authentication certificates* in cases included in this *Certification Practices and Policies Statement.* ### 4.9.3. Procedure for revocation request 183. There is a 24/7 service available at phone numbers +34 917406848 and +34 913878337, to which applications for the revocation of *Website authentication certificates* can be addressed. The communication will be recorded and registered, to be used as support and guarantee of the acceptance of the requested revocation request. 184. Additionally, it is possible to submit the revocation request to the Registration Area of the FNMT-RCM, adhering to the following procedure: 1. *Subscriber* request > The *Subscriber's Representative* will submit the revocation request > form the FNMT-RCM, completed and electronically signed with any of the > *Certificates* admitted for the application and by the electronic > channels enabled by this Entity. 2. Processing of the request by the FNMT-RCM > The registrar of the FNMT-RCM will receive the revocation contract, > and will carry out the same checks regarding the identity and capacity > of the *Subscriber's Representative* as would be performed for cases > of issuance requests and, if approved, will process the revocation of > the *Certificate.* 185. For cases of *Electronic Venue certificate EV,* the FNMT-RCM will always accept the actions and report made by the *Registry Office* designated to request the revocation of these types of Certificates by the Administration, whose procedure is as follows: 1. *Applicant's* identity contained at a *Registry Office.* In order to revoke the *Certificate*, the *Applicant* with sufficient capacity and competence, will appear before a *Registry Offic*e designated for that purpose by the body, group or entity *Subscriber* of the *Certificate* to be revoked, or, otherwise, it will be performed directly by the Registry Operations Manager. 2. Appearance and documentation. The *Applicant* will provide all data required, and which demonstrate: - their personal identity - its status as Personnel at the service of the *Public Administration, Subscriber* of the *Certificate* and holder of the e-mail address through which the *Website* covered by the *Certificate* or status as *Registry Operations Manager* is accessed. - their status as individual designated for the management of the e-mail address through which the *Website c*overed by *Certificate* to be revoked is accessed, or of personnel assigned to the *Registry Office* designated by the body or entity Subscriber of the Certificate to revoke or this purpose. In the event that the above points are not demonstrated, the *Registry Office* will not proceed with the request for revocation of the *Certificate.* 1. Submission of the request for revocation to the FNMT-RCM and its processing. In the absence of evident causes of lack of authorisation of the *Registry Operations Manager* and/or once the identity of the *Applicant* has been confirmed, validity of the conditions demanded of the latter and the revocation request document subscribed, the *Registry Office* will proceed to validate the data and send it FNMT-RCM for the effective revocation of the *Certificate.* The personal data and its treatment shall be subject to specific legislation governing this matter. Said submission will only occur in the event that the *Registry Office* has the power to act as such on behalf of the body, group or Public Administration entity acting as *Subscriber* of the *Certificate,* and if the latter is the holder of the e-mail address through which the Website covered by the *Certificate* is accessed. This transmission of information to the FNMT-RCM will be carried out through secure communications established for such purpose between the *Registry Office* and the FNMT-RCM. 186. If the Applicant cannot provide the required data or it is resolved that this person does not fulfill the requirements to ask for a revocation, the revocation request will be dismiss. 187. Once the FNMT-RCM has proceeded with the revocation of the *Website authentication certificate*, the corresponding *List of Revoked Certificates* will be published in the secure *Directory,* containing the serial number of the revoked *Certificate,* in addition to the date, time, and cause of revocation. The *Subscriber's Representative* will receive notification of the change of the validity status of the *Certificate* through the e-mail address included in the request. ### 4.9.4. Revocation request grace period 188. There is no grace period associated with this process, since revocation is immediate upon verified receipt of the revocation application. ### 4.9.5. Time within which CA must process the revocation request 189. Within 24 hours after receiving a *CPR*, the CA will investigate the facts and circumstances related to the *CPR* and provide a preliminary report to both the Subscriber and the entity who filed the *CPR*. 190. After reviewing the facts and circumstances, the CA will work with the Subscriber and any entity reporting the *CPR* or other revocation-related notice to establish whether or not the Certificate will be revoked, and if so, a date which the CA will revoke the Certificate. The period from receipt of the *CPR* or revocation-related notice to published revocation will not exceed the timeframe set forth in section 4.9.1.1. 191. The date selected by the CA will consider the following criteria: 1. The nature of the alleged problem(scope, context, severity, magnitude, risk of harm); 2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties); 3. The number of CPRs received about a particular Certificate or Subscriber; 4. The entity making the complaint; and 5. Relevant legislation. 192. The FNMT – RCM proceeds with the immediate revocation of the Website authentication certificate at the time of performing the checks described above or, where applicable, once the veracity of the request resulting from judicial or administrative resolution has been verified. ### 4.9.6. Revocation checking requirement for relying parties 193. Third parties that place their trust in and accept the use of *Certificates* issued by the FNMT- RCM are obligated to verify: - the *Advanced Electronic Signature or Advanced Electronic Stamp of the Trust Service Provider* that issues the *Certificate;* - that the Certificate is still valid and active; - the status of *Certificates* included in the *Certification Chain*. ### 4.9.7. CRL issuance frequency 194. *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. 195. *CRLs* of *Authority* certificates are issued at least every six months, or whenever there is a revocation by a *Certification Authority*; they have a 6-month validity period. 196. CAs will continue issuing CRLs until one of the following is true: 1. all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR 2. the corresponding Subordinate CA Private Key is destroyed. 197. The FNMT-RCM will ensure the compliance of the will ensure the compliance of the Baseline (and Extended Validation, for EV certificates) Requirements of the CA/Browser Forum. ### 4.9.8. Maximum latency for CRLs 198. *Revocation lists* are published at the time they are generated, so the latency period between CRL generation and publication is zero. ### 4.9.9. On-line revocation/Status checking availability 199. Information on the status of certificates will be available online 24 hours a day, seven days a week. In the event of system failure, the business continuity plan will be implemented to resolve the incident as soon as possible. 200. The Certification status information and consultation service works as follows: 1. The FNMT-RCM's OCSP server receives an OCSP request made by an OCSP Client and checks the status of the Certificates included in it. If the request is valid, an OCSP response will be issued on the status at that moment of the Certificates included in the request. 2. Each OCSP response is signed using the Signature/Seal Creation Data associated with the OCSP server specific to each CA, thus guaranteeing the integrity and authenticity of the information supplied. 3. The OCSP responses are signed by a separated OCSP Responder, that is signed by the issuer CA and containing the extension id-pkix-ocsp-nocheck in accordance with RFC 6960. 201. OCSP responses for End-Entity Subscriber Certificates will have a validity period equal to or greater than eight (8) hours and less than or equal to ten (10) days. The validity interval of an OCSP response is the difference in time between the thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds. 202. For the status of a Subscriber Certificate or its corresponding Precertificate: 1. FNMT-RCM guarantees that an authoritative OCSP response will be available starting no more than 15 minutes after the Certificate or Precertificate is first published or otherwise made available. 2. For OCSP responses with validity intervals less than sixteen hours, the FNMT-RCM provides an updated OCSP response prior to one-half of the validity period before the nextUpdate. 203. For the status of a Subordinate CA Certificate, the FNMT-RCM provides an updated OCSP response at least every twelve months, and within 24 hours after revoking the Certificate. 204. If the OCSP responder receives a request for the status of a certificate serial number that is “unassigned”, then the responder will not respond with a “good” status. 205. The OCSP responders supports the GET Method, in accordance with RFC 6960 and RFC 5019. Optionally, they can process the Nonce extension in accordance with RFC 8954. ### 4.9.10. Online revocation checking requirements 206. On-line verification of the revocation status of the *Website Authentication Certificate* may be performed through the *Certificate status information service,* which is provided through OCSP as described in section 4.10 of this document. Persons wishing to use this service must: - verify the address contained in the *Certificate*’s AIA (Authority Information Access) extension. - check that the OCSP response is signed/stamped. ### 4.9.11. Other forms of revocation advertisements available 207. Not defined. ### 4.9.12. Special requirements related to key compromise 208. The FNMT-RCM will use reasonable means of communication to inform *Subscribers* that their private key may have been compromised. Whenever a compromise of the key is confirmed, the FNMT-RCM will revoke the affected *Certificates* as described in section 4.9 of this *DGPC* and, where appropriate, the *Specific Certification Policy Statements* dependent on it. 209. The communication to the FNMT-RCM about the compromise of a private key through the contact information indicated in section 1.5.2, must in any case include proof of said compromise and indicate in the subject of the email “Key compromise”. To demonstrate this, the parties may use the following methods: • Submission of the private key compromised or a challenge response signed by the private key and verifiable by the public key, as well as the public key itself. • Providing references to vulnerabilities and / or sources of security incidents from which the key compromise is verifiable. 210. The FNMT-RCM may accept other types of evidences that adequately prove the compromise of keys. ### 4.9.13. Circumstances for suspension 211. The suspension of certificates is not provided. ### 4.9.14. Who can request suspension 212. The suspension of certificates is not provided. ### 4.9.15. Procedure for suspension request 213. The suspension of certificates is not provided. ### 4.9.16. Limits on the suspension period 214. The suspension of certificates is not provided. ## 4.10. Certificate status services 215. The *Certification status information and consultation service* works as follows: the OCSP server receives an OCSP request made by an OCSP Client and checks the validity status of the Certificates included in it. If the request is valid, an OCSP response will be issued on the status at that moment of the *Certificates* included in the request. This OCSP response is signed/stamped using the *Signature/Stamp Creation Data* of the FNMT-RCM, thus guaranteeing the integrity and authenticity of the information supplied on the revocation status of Certificates consulted. 216. The User entity will be responsible for acquiring an OCSP *Client* to operate with the OCSP server made available by the FNMT-RCM. 217. The FNMT-RCM operates and maintains the maintenance capabilities of its CRLs and OCSP service with sufficient resources to provide a maximum response time of ten seconds under normal operating conditions. 218. Access to these information services: - Certificate Revocation Lists: AC RAIZ FNMT-RCM “SERVIDORES SEGUROS”: Subordinate CA “SERVIDORES SEGUROS TIPO 1” (*EV Certificates)*: Subordinate CA “SERVIDORES SEGUROS TIPO 2” (*OV Certificates)*: AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R: - Certificate status verification service (OCSP): AC RAIZ FNMT-RCM “SERVIDORES SEGUROS”. Subordinate CA “SERVIDORES SEGUROS TIPO 1” (*EV Certificates)*. Subordinate CA “SERVIDORES SEGUROS TIPO 2” (*OV Certificates)*. ### 4.10.1. Operational characteristics 219. Revocation entries on a CRL or OCSP Response will include all revoked Certificates, including the expired ones. Under no circumstances these revocation entries will be removed until after the Expiry Date of the revoked Certificate. ### 4.10.2. Service availability 220. The FNMT-RCM guarantees access to this service, 24/7, for all Certificate users, holders and trusting parties, securely, quickly and free of charge. 221. The FNMT-RCM operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions 222. In the event that the service is unavailable as a result of maintenance operations, the FNMT-RCM will post a notification stating this at at least forty-eight (48) hours in advance, if possible, and will attempt to resolve the issue within twenty-four (24) hours. ### 4.10.3. Optional features 223. No stipulation. ## 4.11. End of subscription 224. The subscription will at the time of expiration of the validity of the *Website authentication certificate*, either as a result of expiration of the validity period or by revocation thereof ## 4.12. Key escrow and recovery ### 4.12.1. Key escrow and recovery policies and practices 225. Since the FNMT-RCM does not generate the P*rivate keys* of the *Website authentication certificates,* it does not maintain them, and is not able to recover them. ### 4.12.2. Session key encapsulation and recovery policies and practices 226. Not stipulated. # 5. Management, operational and physical controls 227. The FNMT-RCM, as a *Trust Service Provider*, maintains all critical assets used in trusted services in secure zones, physically, logically and functionally protected. 228. Likewise, it has segmented networks for the administration of its systems and for the operation of trusted services. The systems used for the administration of the implementation of the security policy are not used for other purposes. Production systems for trusted services are separated from the systems used in development and testing. 229. The FNMT-RCM has physical, logical, personnel and operating control procedures in place to guarantee the necessary security in the management of the systems under its control and involved in the provision of trust services. The FNMT-RCM will also log all events related to its services that could be relevant so as to check that all the internal procedures required to perform the activities comply with applicable legislation in order to be able to determine the causes of anomalies detected. 230. All the controls implemented by the FNMT-RCM as a *Trust Service Provider* are listed below, using as work models the document *RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework* and the European standards *ETSI* EN 319 401 “General Policy Requirements for Trust Service Providers”, ETSI EN 319 411 “Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates” and the CAB Forum’s Network Security and Certification System Requirements, excluding confidential and secret controls that are not disclosed for security reasons. ## 5.1. Physical security controls 231. The FNMT-RCM guarantees that it complies with legislation applicable to all aspects of physical security, which are described in this chapter. 232. Security perimeters are in place around critical or sensitive activities, including security barriers and appropriate entry controls equipped with security control mechanisms to reduce the risk of unauthorised entry or damage to IT resources. ### 5.1.1. Site location and construction 233. The building in which the *Trust Service Provider*’s infrastructure is located is equipped with access control security measures so that the activities and services may be carried out with sufficient guarantees of *Confidentiality* and security. #### 5.1.1.1 Data Processing Centre location 234. The *Trust Service Provider*’s data centre has been built taking into account the following physical requirements: - In an apartment, away from exhaust ducts to avoid any damage in the event of a fire in the stories above. - Absence of windows providing access from outside the building. - Intrusion detectors and surveillance cameras in the restricted access areas during time periods in which the systems are unattended. - Access control based on a card and a password. - Fire protection and prevention systems: fire detectors, extinguishers, fire-fighting training for operators, etc. - Transparent partitions separating zones and allowing rooms to be observed from access corridors so as to detect intrusion or illicit activities inside the Data Centre. - All cabling will be protected against damage, electromagnetic interception and interception of data transfers and telephone calls. 235. The facilities employed to provide trust services are located in a high-security environment, separate from the Entity’s other activities. ### 5.1.2. Physical access #### 5.1.2.1 Physical security perimeter 236. Once the security areas in which the FNMT-RCM’s activities as a *Trust Service Provider* are conducted have been defined, suitable physical access control measures are put in place, without forgetting that the FNMT-RCM's premises have an advanced physical perimeter security system comprising various rings equipped with the appropriate technical and human resources, protection and surveillance by State security forces and corps, and specialised security services. 237. In addition to the access controls, there are various internal control mechanisms in rooms and facilities, such as access control using card readers, video surveillance cameras, intrusion detectors, fire detectors, etc., as well as human resources controlling access outside and inside the premises. #### 5.1.2.2 Physical entry controls 238. There is a comprehensive system of physical controls for people entering and leaving the premises, in a number of security rings. 239. All the *Trust Service Provider*’s critical operations are carried out inside physically secure premises with various levels of security controlling access to critical machines and applications. 240. These systems will be physically separate from other FNMT-RCM systems so that only the Department's authorised personnel may access them, thus guaranteeing independence from other general-purpose networks. #### 5.1.2.3 Work in secure areas 241. Work in secure areas is protected by access controls and, when required, is monitored by the FNMT-RCM’s Security Department. Unless specifically authorised by Management, photographic, video, audio or other recording devices are not permitted in these areas. #### 5.1.2.4 Visits 242. Access by non-FNMT-RCM personnel to the facilities must previously be communicated to the Security Department and authorised by Ceres Department management. Visitors must wear a visible identification card and be accompanied at all times by FNMT-RCM personnel. #### 5.1.2.5 Separate loading and unloading areas 243. Loading and unloading are carried out in separate areas under permanent technical and human surveillance. ### 5.1.3. Power and air conditioning 244. The rooms housing the *Trust Service Provider*’s infrastructure machines has an adequate electricity supply and air-conditioning to create a favourable operating environment. This production infrastructure is protected against power outages or any anomaly in the power supply by means of an independent auxiliary power line from the main supply centre, as well as an autonomous power generator. 245. Mechanisms are also in place to keep heat and humidity at suitable levels for the *Trust Service Provider’*s system. 246. Where necessary, the systems have uninterruptible power supply units, a dual power supply and a generator. #### 5.1.3.1 Cabling security 247. Cabling is located in false ceilings or floors and is adequately protected by fire detectors in the floor and ceiling, and humidity sensors for fast leak protection. ### 5.1.4. Water exposures 248. The necessary steps have been taken to prevent water exposure in relation to equipment and cabling. ### 5.1.5. Fire prevention and protection 249. The rooms are suitably equipped (detectors) to protect their content against fire. ### 5.1.6. Media storage 250. The FNMT-RCM, as a *Trust Service Provider*, has the necessary procedures in place to back up all the information in its production infrastructure. All media are handled securely in accordance with requirements of the information classification scheme as described by the Standard of "Classification and control of information resources" developed by the Information Security Policy of the FNMT-RCM. Media containing sensitive data are securely disposed of when no longer required. #### 5.1.6.1 Information recovery 251. The FNMT-RCM has backup plans covering all sensitive information and data deemed to be necessary for the Department's business to continue. There are various preparation and recovery procedures depending on the sensitivity of the information and of the installed media. ### 5.1.7. Waste disposal 252. A waste management policy is in place to guarantee the destruction of any material that may contain information, as well as a policy for the management of removable media. ### 5.1.8. Off-site backup 253. FNMT-RCM maintains backup and archiving systems in an alternative secure location of its property, independent of the main Datacenter and far enough to prevent damage in case of disaster. 254. At least three authorized people are required to access to the removal or inclusion of physical backup storage. ## 5.2. Procedure controls 255. The FNMT-RCM possess an Information Security Policy, approved by its Director General, ratified by the Information Security Committee and the Management Committee, and is subject to a process of periodic review and permanent updating, in order to guarantee its adaptation to the needs of the organization, current legislation and continuous technological advances. The maximum period between revisions of the Information Security Policy is one year. The participation of a member of the TSP Management Committee in the Information Security Committee guarantees the adequacy of the provision of trust services to said Policy and participation in the aforementioned process of updating it. 256. The FNMT-RCM seeks to assure that all management of both operating and administrative procedures is carried out in a trustworthy manner as stipulated in this document; audits are performed to avoid any defect that could lead to a loss of trust (see the section 8 “Compliance audits”). - Audits are carried out to verify the fulfilment of security measures and technical and administrative requirements. - Functions are segregated to avoid the same person obtaining control over the entire infrastructure. To this end, multiple profiles are defined and assigned to infrastructure personnel to distribute tasks and responsibilities. 257. The FNMT-RCM outsources certain activities, such as the *Certificate* user service unit. These activities are carried out as stipulated in the FNMT-RCM’s *Certification Policies and Practices* and in contracts and agreements with the relevant entities. In these cases, third-party access to information owned by the FNMT-RCM is subject to the protocol defined in the Security Policy as regards the identification of risks, establishment of security controls to protect access to information, the relevant confidentiality agreements and, if applicable, an agreement on personal data processing in compliance with prevailing legislation. 258. The FNMT-RCM will implement supervision and control programmes to assure that the entities that carry out delegated functions related to the provision of certification services comply with the FNMT-RCM’s policies and procedures. 259. The FNMT-RCM has an up-to-date inventory of all the information and system assets employed to process information, detailing their owner or person responsible, nature, classification and any other relevant data to prevent and react to incidents. Information processing systems are categorised to put in place security controls in accordance with the National Security Scheme. 260. The FNMT-RCM, through its Code of Conduct Review Committee, oversees compliance with the Code to avoid situations that could result in a conflict of interest. Additionally, the specific regulations[^3] that apply to trust roles, as civil servants, guarantee the impartiality of the operations in the activity of the FNMT-RCM, in its activity as Trust Services Provider. ### 5.2.1. Trusted Roles 261. People who perform “Trusted roles” are suitably trained and have the knowledge and experience necessary to execute the work related to each role. Where necessary, the FNMT-RCM has provided suitable technical and security training for personnel involved in the management of its trustworthy systems. 262. The following trusted roles are defined: Security Officer, System Administrator, System Operator, System Auditor and Validation Specialist. People are selected for these roles applying the principle of least privilege and taking into account training, experience and the Personnel Security controls described below. The people holding these roles will be designated by the CSP's Management Committee 263. The list of personnel assigned to Trusted Roles is maintained and reviewed each time there is a change or, at least, once per year. ### 5.2.2. Number of Individuals Required per Task 264. The tasks assigned, depending on the trusted role, are set out in the internal document of the FNMT-RCM’s Information Systems Department entitled “Trusted roles and security profiles”. 265. The FNMTs Private Key are backed up, stored, and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment. ### 5.2.3. Identification and Authentication for Trusted Roles 266. Trusted roles, tasks assigned and security profiles are identified in the internal document of the FNMT-RCM’s Information Systems Department entitled “Trusted roles and security profiles”. ### 5.2.4. Roles Requiring Separation of Duties 267. The functions and duties performed by persons in Trusted Roles are defined in section 5.2.1. Each person can hold only one role. 268. In the case of *EV Certificates*, once the validation is done, a FNMT-RCM Validation Specialist, different from the first one who has done the review and verification of the application’s documents will verify all the information and approve issuance of the EV *Certificate*. ## 5.3. Personnel controls 269. The FNMT-RCM has internal procedures establishing all the controls necessary to identify the activities performed by users in critical information systems that affect the provision of Trust Services so as to log incidents and assure traceability. There is an auditable log for each access or failed access attempt in both the system and the system assets. All activities relating to security functions are logged. 270. There is a policy on the management of access privileges for information and information systems, as well as user password management. Privileges granted in the system to each user are reviewed periodically by the person responsible for each information system or asset. Consequently, the FNMT-RCM administers access for system operators, administrators and auditors, with sufficient logical security controls to guarantee the separation of the trusted roles identified in its trust service practices, such that privileges related to access to critical applications in the *Trust Service Provider*’s infrastructure are afforded special treatment, previously identifying and authenticating personnel authorised to access and equipping them with electronic certificates in cryptographic cards. 271. In the course of their work for the FNMT-RCM, or whenever they use the FNMT-RCM’s media and/or materials, its employees, in accordance with their employment contracts and/or applicable legislation, exclusively assign to the FNMT-RCM all exploitation rights that may be applicable to intellectual property, to the fullest extent and for the maximum duration envisaged in the Law, worldwide and, in particular, for illustrative, non-restrictive purposes, rights of reproduction, distribution, transformation and public communication, as well as other industrial property rights or semiconductor topography rights, and rights to projects, works, inventions and creations that they may originate and/or develop. The employees, as a result of the exclusive assignment of the said rights to projects, works, inventions and creations prepared or created as a result of their employment relationship with the FNMT-RCM or as a result of the use of the FNMT-RCM's material and/or technical resources, will not be entitled to exploit the said works and/or creations in any way, even if this would not harm the exploitation or use of the same by the FNMT-RCM. 272. In order to comply with the FNMT-RCM’s internal rules, applicable laws and regulations, and assure its employees’ security, the FNMT-RCM reserves the right to inspect, at any time, and monitor all the FNMT-RCM’s computer systems. 273. The computer systems subject to inspection include, but are not limited to, e-mail archives, personal computer hard drive archives, voice mail archives, print queues, fax machine documents, desk draws and storage areas. These inspections will be carried out after having been approved by the Security and Legal Affairs Departments, following the procedures laid down in applicable legislation and involving trade union representatives, if appropriate. The FNMT-RCM reserves the right to remove from its computer systems any material that it considers to be offensive or potentially illegal or fraudulent. 274. The FNMT-RCM’s management reserves the right to revoke the system privileges of any user at any time. No conduct will be permitted that interferes with the normal and adequate functioning of the FNMT-RCM's computer systems, prevents others from using the systems or is dangerous or offensive. 275. The FNMT-RCM will not be responsible for opinions, acts, transactions and/or underlying businesses that the users may express or carry out using the FNMT-RCM’s certification systems, all without affecting the FNMT-RCM's obligation to report any matter to the competent authority, if applicable. 276. Unless the relevant authorisation is granted by the FNMT-RCM’s Information Systems Department, the FNMT-RCM’s employees must not acquire, possess, trade or use hardware or software tools that could be employed to evaluate or compromise the IT security systems. Some examples of such tools are those that ignore software protection against unauthorised copies, detect secret passwords, identify vulnerable security points and decode archives. Moreover, employees are prohibited, without suitable permission, from using trackers or other types of hardware or software that detects traffic in a networked system or a computer's activity, barring cases in which their use is necessary to conduct system testing and after informing the head of the department in question. 277. Users must not verify or try to compromise the security measures in place in a communication machine or system unless this action has previously been approved in writing by the FNMT-RCM's Information Systems Management. Incidents related to computer piracy, password discovery, archive decoding, unauthorised copying of software, personal data protection and other activities representing a threat to the security measures, or which are illegal, will be deemed serious infringements of the FNMT-RCM’s internal rules. The use of bypass systems to avoid protection measures and other archives that may compromise protection systems or resources is also absolutely forbidden. 278. All these infringement of regulations, system intrusions, malicious software infections and other conditions that jeopardise the FNMT-RCM's information or computer systems must be immediately reported to Information Systems Management. ### 5.3.1. Qualifications, Experience, and Clearance Requirements 279. All the personnel involved in the activity of the FNMT-RCM, as a Trusted Service Provider, and especially the managerial staff, possess necessary experience and knowledge to manage said activity. These requirements are guaranteed by the corresponding criteria in the personnel selection processes, verifying the identity and trustworthiness of such person and that the employee's professional profile is as appropriate as possible to the characteristics of the tasks to be developed. The trustworthiness and suitability of the assigned trusted roles are reviewed periodically. 280. Procedures followed to manage infrastructure personnel will promote competence and know-how, as well as the fulfilment of their obligations. 281. Trusted positions within the scope of this document will be those that entail access to or control of components that could directly affect the management of systems that implement the services related to *Certificates* and information on the status of *Certificates.* ### 5.3.2. Background Check Procedures 282. The terms and conditions of the employment relationship are included in both the relevant contract and in the Collective Agreement on work relations between the FNMT-RCM and its employees, as well as in legislation applicable by virtue of the Statute. ### 5.3.3. Training Requirements and Procedures 283. The FNMT-RCM manages the Annual Training Plan, through its Training Centre attached to the Human Resources Department, on the basis of the Entity's general needs and each department's specific needs. All employees, whether on the payroll or subcontracted, who have access to or control of the trustworthy systems on which the trusted third-party services are based are covered by the annual Training Plan focused on information security training and awareness building needs, as laid down in the internal document “Information security training and awareness raising standard”. 284. For the personnel performing information verification duties the annual training covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the FNMT’s Certificate Policy and/or Certification Practice Statement), common threats to the information verification process (including phishing and other social engineering tactics), the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” and the “EV SSL Certificate Guidelines” established by the entity CA/Browser forum. 285. The FNMT-RCM maintains records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily. 286. The FNMT-RCM documents that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task. 287. The FNMT-RCM requires all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. ### 5.3.4. Retraining Frequency and Requirements 288. The FNMT-RCM implements ongoing training plans, paying particular attention to substantial modifications of *Trust Service* infrastructure operations. The FNMT-RCM review these requirements at least once a year. ### 5.3.5. Job Rotation Frequency and Sequence 289. Not stipulated. ### 5.3.6. Sanctions for Unauthorized Actions 290. Security is included among employees’ responsibilities but does not require additional references since the FNMT-RCM’s main purpose is security, which is therefore the objective and responsibility of all the organisation's members. 291. In any event, without prejudice to the relevant public legislation, provisions of the Criminal Code that are directly applicable and clauses of certain senior management contracts, Chapter XVII “Disciplinary regime”, Article 63. Infringements and Penalties of the above-mentioned Collective Agreement specifically states: > *“The following shall be very serious infringements:* > > *...* > > *9.. The undue use or disclosure of data or matters known by reason of > the work carried out in the Organisation.* > > *...:* > > *...* > > *10. Negligence in the custody of official secrets, declared as such > by law or classified as such, which causes their publication or leads > to their undue dissemination or disclosure.* > > *...”* 292. The penalty may entail dismissal, irrespective of any infringement of general legislation and the corresponding penalty or sentence that may be imposed by a court. 293. Additionally, where required, personal confidentiality agreements may be arranged at the request of the FNMT-RCM and/or third parties. ### 5.3.7. Independent Contractor Controls 294. Personnel recruitment and policies are included in the Collective Agreement regulating work relationships between the FNMT-RCM and its employees, as well as in legislation applicable to the civil service and the related Statute (Spanish Royal Decree 51/2023 of January 31st, approving the *Fábrica Nacional de Moneda y Timbre-Real Casa de la Moneda* Statute, State-owned enterprise attached to Ministry of Finance and Civil Service). 295. Definitions of work posts and responsibilities, including security positions, are included in the Collective Agreement regulating work relationships between the FNMT-RCM and its employees, as well as applicable regulations governing the civil service. 296. In the case that an independent contractor is assigned to perform a Trusted Role for the certification service, the FNMT-RCM will verify that the personnel involved meet the training and skills requirements of section 5.3.3 and the document retention and event logging requirements of section 5.4.1 #### 5.3.7.1 Third-party contracting requirements 297. The contracting of third parties by the FNMT-RCM is subject to the Law 9/2017, of November 8, on Contracts of the Public Sector, by which the Directives of the European Parliament and Council 2014/23 / EU and 2014/24 / EU, of February 26, are transposed into the Spanish legal system (*LCSP*). In this context, the Entity is an "awarding authority" and is therefore subject to the above-mentioned law, i.e. to the "harmonised regulation" of contracting. For cases in which the *LCSP* is not applicable, the FNMT-RCM will employ its Internal Contracting Instructions (*IIC*). ### 5.3.8. Documentation Supplied to Personnel 298. All employees who have access to or control of the trustworthy systems in which trusted third-party services are based are provided with access to the department's knowledge database, which contains documentation on security regulations, *Certification Practices and Policies*, functions entrusted to personnel, the quality and security plan, business continuity policy and plans and, in particular, they are provided with the documentation required to carry out their respective tasks. 299. Personnel assigned permanently or temporarily to these posts will be duly accredited and identified by the FNMT-RCM. A periodic assurance process is completed to verify that they are still trusted by the FNMT-RCM to perform their confidential duties. 300. Relations between third parties and the FNMT-RCM are protected by the relevant confidentiality agreement if sensitive information must be exchanged in the course of the relationship. 301. The FNMT-RCM's personnel, under the Collective Agreement, do not require specific personal confidentiality agreements, without affecting exceptional cases in which there may be personal confidentiality agreements, normally due to third-party requests or the FNMT-RCM’s own decisions. ## 5.4. Audit procedures 302. The FNMT-RCM has a system for monitoring and logging events that is independent from the production infrastructure. It functions uninterruptedly (24x7), compiling security information and events for all the Certification Authority's sensitive and trust-related elements for subsequent processing and correlation. 303. The relevant reports are extracted from this monitoring system in order to oversee infrastructure security. Rules and policies are in place to provide real-time alarms in the event of anomalous behaviour in the Certification Authority’s systems or signs of a security incident. ### 5.4.1. Types of Events Recorded 304. The FNMT-RCM will log all significant events so as to verify that all the internal procedures necessary to carry out its activities are executed as stipulated in this document, in applicable legislation and in the Internal Security Plan and Quality and Security Procedures, allowing the causes of any anomalies to be identified. These logged events will be made available, if necessary, so as to provide evidence of the proper functioning of the services for the purposes of court proceedings. 305. The events logged will include all operations carried out during the management of keys, *Certificates*, *Electronic time stamp* issuance, *Certificate* status information, publication, filing, recovery, directory, event logs and user logs. All events relating to the life cycle of keys managed by the CA, including any subject keys generated by the CA. The registration information (identity accreditation), such as the unique identification data, the signed subscriber agreement, the identity of the entity to which the Registration Office belongs, etc., will also be part of the recorded events, as specified in the corresponding documents of Registration Procedures. The FNMT-RCM will archive all the most important events logged and will keep them accessible for a period of not less than 15 years. 306. All events logged may be audited and will include the date and time of record, the identity of the person making the journal record and a description of the record. 307. The FNMT-RCM will make available to the competent authorities the evidences related to the registered events that are in its possession, by judicial request or the corresponding legal procedure, upon written request made to the contact data described in section "1.5. 2. Contact details". 308. In addition to the events mentioned, all logs specified by the ISO 9001 and SR10 standards will be kept in the manner stated in the FNMT-RCM's general quality procedures, for a period of not less than three years. 309. FNMT-RCM will record at least the following events: a\) CA certificate and key lifecycle events, including: 1\. Key generation, backup, storage, recovery, archival, and destruction; 2\. Certificate requests, renewal, and re-key requests, and revocation; 3\. Approval and rejection of certificate requests; 4\. Cryptographic device lifecycle management events; 5\. Generation of Certificate Revocation Lists and OCSP entries; 6\. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles. b\) Subscriber Certificate lifecycle management events, including: 1\. Certificate requests, renewal, and re-key requests, and revocation; 2\. All verification activities stipulated in the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates and the CA’s Certification Practice Statement; 3\. Approval and rejection of certificate requests; 4\. Issuance of Certificates; and 5\. Generation of Certificate Revocation Lists and OCSP entries. 6\. Multi-Perspective Issuance Corroboration attempts from each Network Perspective, minimally recording, an identifier that uniquely identifies the Network Perspective used and the attempted domain name; and the result of the attempt. Also, Multi-Perspective Issuance Corroboration quorum results for each attempted domain name in a Certificate request. c\) Security events, including: 1\. Successful and unsuccessful PKI system access attempts; 2\. PKI and security system actions performed; 3\. Security profile changes; 4\. Installation, update and removal of software on a Certificate System; 5\. System crashes, hardware failures, and other anomalies; 6\. Firewall and router activities (see 5.4.1.1); and 7\. Entries to and exits from the CA facility. #### 5.4.1.1 Router and firewall activities logs 310. Logging of router and firewall activities include: 1\. Successful and unsuccessful login attempts to routers and firewalls; and 2\. Logging of all administrative actions performed on routers and firewalls, including configuration changes, firmware updates, and access control modifications; and 3\. Logging of all changes made to firewall rules, including additions, modifications, and deletions; and 4\. Logging of all system events and errors, including hardware failures, software crashes, and system restarts. ### 5.4.2. Frequency for Processing and Archiving Audit Logs 311. Logs are analysed continuously, although they may be audited manually where necessary. For example, this will occur in the event of a system alert caused by an incident, no frequency having been stipulated for this process. ### 5.4.3. Retention Period for Audit Logs 312. FNMT-RCM shall retain, for at least 15 years: 1. CA certificate and key lifecycle management event records (as set forth in Section 5.4.1 after the later occurrence of: 1. the destruction of the CA Private Key; or 2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 basicConstraints extension with the CA field set to true and which share a common Public Key corresponding to the CA Private Key; 1. Subscriber Certificate lifecycle management event records (as set forth in Section 5.4.1 after the revocation or expiration of the Subscriber Certificate; 2. Any security event records (as set forth in Section 5.4.1) after the event occurred. ### 5.4.4. Protection of Audit Log 313. Once entered in the systems, logs cannot be modified or deleted and will remain archived in their original condition. 314. Logs will only have read access and will be restricted to people authorised by the FNMT-RCM. 315. Logs will be recorded automatically by specific software implemented by the FNMT-RCM as deemed fit, so as to prevent manipulation. 316. The audit log will be protected against any contingency, modification, loss or data disclosure during recording on external media, change of external media and storage, in addition to the security measures in place for recording and subsequent verification. ### 5.4.5. Audit Log Backup Procedures 317. The FNMT-RCM, in its activities as a *Trust Service Provider* using a high-security system, guarantees that backups will be made of all audit logs. ### 5.4.6. Audit Log Accumulation System (internal vs. external) 318. The significant events generated by the CAs and by the RAs are duly stored in the FNMT-RCM’s internal systems. ### 5.4.7. Notification to Event-Causing Subject 319. Not envisaged. ### 5.4.8. Vulnerability Assessments 320. The FNMT-RCM has a Vulnerability Management Procedure disclosing vulnerability’s detection, log and fixing of the vulnerabilities detected within its systems. 321. The FNMT-RCM obtains information on technical vulnerabilities affecting the information systems and the appropriate measures are taken. Responsibilities associated with the management of technical vulnerabilities are defined and established, maintaining the information resources up-to-date in the asset inventory so as to identify any such vulnerabilities. Additionally, procedures undertaken are audited periodically and the management of technical vulnerabilities is monitored and assessed on a regular basis. 322. The FNMT-RCM will address any unforeseen critical vulnerability within 48 hours of discovering it. Once the impact has been analysed, it will be documented and a decision will be taken to resolve the vulnerability by means of a mitigation plan, based on the resolution cost. 323. The FNMT-RCM carries out quarterly vulnerability analyses in its systems. An annual penetration test is also performed. ## 5.5. Log archiving ### 5.5.1. Types of Records Archived 324. The FNMT-RCM will archive and keep accessible all relevant information on the data issued and received, particularly for use as evidence in legal proceedings and to guarantee the continuity of its Trust Services. 325. The following will be logged: - Issuance, revocation and other relevant events related to the *Certificates*, as well as operations related to the management of the *Trust Service Provider*’s keys and *Certificates*. - *Signatures* and other relevant events related to *Revocation Lists* (CRLs). - All operations to access the *Certificate* archive. - All operations to access the *Certificate status information service*. - Relevant events relating to the generation of random and pseudo-random number pairs for *Key* generation. - Relevant events relating to the generation of own *Key* pairs or *Key* pairs for authentication support. The numbers themselves or any data facilitating the prediction of the numbers will not be included in any event. - All operations in the *Key* filing service and access to the expired own *Key* archive. - All operations related to activities as a trusted third party. - Relevant events in the *Time Stamping Authority*’s operations, particularly relating to clock synchronisation and synchronisation losses. The exact moment of occurrence will also be included. 326. In addition to these events, all related documentation is also archived, for example: - Documentation related to the generation and conservation protocols of the *Keys* of the *Certification Authorities* and the *Time Stamping Service*. - Requests for issuance and revocation of *Certificates*, - Documentation related to the accreditation operations carried out by the registration offices. - Events related to the provision of the server signature service 327. Declarations of *Certification Practices* and *Policies* and their history. ### 5.5.2. Retention Period for Archive 328. The retention period of the archived records shall not be less than 15 years after the expiration of the validity of the associated certificate. ### 5.5.3. Protection of Archive 329. Access to the logs will be limited to personnel authorised by the FNMT-RCM. 330. Third-party access to encrypted data by means of the data recovery service without user authorisation must always comply with the Law and, if applicable, with the relevant *Contracts, Commissions and Agreements*. 331. The FNMT-RCM guarantees that the archive of logged events meets the following requirements: - It may not be modified through unauthorised means. - Availability and reliability must be high. 332. The confidentiality of the information will be guaranteed and access will be traceable. ### 5.5.4. Archive Backup Procedures 333. All archives deemed to be critical to the FNMT-RCM’s activities as a *Trust Service Provider* will be backed up at all times. ### 5.5.5. Requirements for Time-stamping of Records 334. All the events stored contain a time mark obtained from the UTC time reference (Spanish Navy Observatory). The Spanish Navy Observatory (*ROA*) is Spain’s official timing centre. The FNMT-RCM and the *ROA* have an agreement to synchronise the time in their systems. The terms and conditions of the Synchronisation System are defined in the document “FNMT – ROA Synchronisation System”. ### 5.5.6. Archive Collection System (internal or external) 335. The archive systems used by the FNMT-RCM to keep these audit logs will be the infrastructure’s own internal systems and external media with storage capacity for long periods of time will also be employed. These media will provide sufficient guarantees to prevent any type of alteration of the logs. 336. The FNMT-RCM will make several copies that will be stored in different places equipped with all physical and logical security measures to avoid, where reasonably possibly, any alteration of the media stored and of the data contained in the media. Each copy will be stored in a different place in case of a disaster in any location. ### 5.5.7. Procedures to Obtain and Verify Archive Information 337. These archive systems have a high level of integrity, confidentiality and availability to avoid attempts to manipulate the *Certificates* and events stored. ## 5.6. Change of CA keys 338. Prior to the expiration of the validity period of the *Certificate* of a root *Certification Authority* or of a subordinate *Certification authority*, a new root or subordinate *Certification Authority* will be created by generating a new key pair. The old *Certification Authorities* and their associated private keys will only be used to sign CRLs while there are active Certificates issued by those CAs. ## 5.7. Incident and vulnerability management ### 5.7.1. Incident and Compromise Handling Procedures 339. The FNMT-RCM guarantees a coherent and effective approach to the management of information security incidents. The document “Information Security Management System - Security Manual” lays down incident management procedures and responsibilities, guaranteeing a fast, effective and orderly response to security incidents. 340. In the case of a security incident, the affected parties will be notified as described in the Security Policy and the related implementing rules, particularly the incident response plan. In the event of a high-impact incident, the FNMT-RCM will send notification in less than 24 hours following detection. #### 5.7.1.1 Incident Response and Disaster Recovery Plans 341. The FNMT-RCM has an Incident Response Plan and a Disaster Recovery Plan. 342. FNMT-RCM implements, documents and tests annually business continuity and disaster recovery procedures to assure and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster or security compromise. FNMT-RCM test, review, and update these procedures at least once per year. 343. The business continuity plan include: 1. The conditions for activating the plan, 2. Emergency, Fallback and Resumption procedures, 3. A maintenance schedule for the plan; 4. Awareness and education requirements; 5. The responsibilities of the individuals; 6. Recovery time objective (RTO); 7. Regular testing of contingency plans. 8. The internal plan to maintain or restore the FNMT-RCM’s business operations in a timely manner following interruption to or failure of critical business processes 9. A requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation materials) at an alternate location; 10. What constitutes an acceptable system outage and recovery time 11. How frequently backup copies of essential business information and software are taken; 12. The distance of recovery facilities to the FNMT-RCM’s main site; and 13. Procedures for securing its facility to the extent possible during the period of time following a disaster and prior to restoring a secure environment either at the original or a remote site 14. Redundancy of the most critical components. 15. Start-up of an alternative support centre. 16. Full, periodic checking of backup copy services. 17. Compromised Signature creation data of the Trust Service Provider or algorithm compromise that leads a real threat, considering the current state of the art, identity impersonation. In these cases, the FNMT-RCM will schedule the revocation of the affected Certificates and will inform all members of the Electronic Community that all the Certificates, Revocation Lists, Electronic time stamps and any other data structure able to be signed are no longer valid due to the compromised data. The FNMT-RCM will restore the service as soon as possible and on the new terms applicable. #### 5.7.1.2 Mass Revocation Plans 344. The FNMT has a Mass Revocation Plan that will be executed in any case that requires the revocation of a substantial number of certificates within a relatively short timeframe due to a common cause, compliance requirement, or security incident. 345. This plan defines in a clear, actionable and comprehensive way for all the participants, a set of procedures leading to ensure rapid, consistent and reliable response to large-scale Certification revocation scenarios. It is made up of four parts with an estimated time for each subtask: communication with the customers, replacement and revocation of the Certificates and a “a posteriori” analysis to check the efficiency of the response, providing feedback to the plan. 346. All participants hold some roles and responsibilities specified in the plan. Additionally, to ensure all participants understand their roles, there is an initial and an annual training of the response procedures. 347. The FNMT-RCM will perform an annual testing of the mass revocation plan, incorporating lessons learned into such plan in order to continually improve their preparedness for mass revocation events over time. 348. The FNMT-RCM will annually test, review, and update its plan and its procedures. ### 5.7.2. Recovery Procedures if Computing Resources, Software, and/or Data Are Corrupted 349. This contingency is envisaged in the FNMT-RCM's Business Continuity Plan. ### 5.7.3. Recovery Procedures After Key Compromise 350. This contingency is envisaged in the FNMT-RCM's Business Continuity Plan, as is the procedure to be followed, described in the Crisis Management Plan as part of the Business Continuity Plan, including the following actions, among others: 1) Stop providing the affected service. 2) Revoke any certificates that might be affected. 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. 351. Study the need to execute the Discontinuance of the CSP’s Activities as per the Certification Practices Statement and prevailing legislation. ### 5.7.4. Business Continuity Capabilities after a Disaster 352. The FNMT-RCM has a business continuity plan describing the actions to be implemented in case of disaster. So, it has a backup system that stores in safe places the data necessary to resume CA operations in case of incident/disasters, even in the alternative support centre, in order to ensure that all essential information and software can be recovered following a disaster or media failure. 353. To guarantee business continuity after a contingency or disaster and following the provisions of the FNMT Business Continuity Plan Test Plan- RCM, backups are regularly tested by means of drills at least once a year. 354. In the case of a failure or disaster affecting the *Trust Service Provider*’s systems, a Disaster Recovery Plan will be launched, encompassing: 355. The FNMT-RCM will not be responsible for the lack of service or service anomalies, nor for any damage that may be caused directly or indirectly, when the failure or disaster is the result of force majeure causes, a terrorist attack, sabotage or wildcat strikes, all without affecting any actions necessary to correct and/or restore the service as soon as possible. ## 5.8. Discontinuance of the Trust Service Provider's activities 356. In the event of the discontinuance of the *Trust Service Provider* activities, the FNMT-RCM will be subject to the provisions of prevailing electronic signature legislation. 357. In any case, the FNMT-RCM: - Will duly inform *Certificate Subscribers* and *Holders*, and the Users of the affected services, of its intention to discontinue *Trust Service Provider* activities at least two (2) months in advance. - Any outsourcing of functions carried out in the FNMT-RCM’s name relating to the service to be discontinued will be terminated. - Once evidence that the *Subscribers* do not object has been obtained, *Certificate* that are still valid at the effective date of discontinuance may be transferred to a different *Trust Service Provider*. If such transfer is not possible, the *Certificates* will expire. - Whatever the service discontinued, the FNMT-RCM will transfer the event and audit logs to a third party, as well as the *Certificates* and keys used to provide the service, for a sufficient period of time as stipulated in prevailing legislation. - The *Supervisory body* will be informed of the discontinuance of the activity and the destination of the *Certificates*, specifying, if applicable, whether they are to be transferred or will expire. That body must be notified at least two (2) months in advance by means of a document signed by hand or electronically. 358. If discontinuance relates to the *Time Stamping Service*, the FNMT-RCM will: - revoke the *Certificates* of the affected *Time Stamping Units*. - destroy the *Private Keys* of the *Time Stamping Units* and related backups so that they cannot be recovered. 359. If discontinuance relates to the *Server signature service*, the FNMT-RCM will: - revoke the certificates of the affected Certification Authorities, and - destroy users' Private Keys and their backups, so that they cannot be recovered. # 6. Technical security controls ## 6.1. Key pair generation and installation ### 6.1.1. Key pair generation #### 6.1.1.1 CA Key Pair Generation 360. The FNMT-RCM possess a procedure described in the document “Gestión del ciclo de vida de las claves de la FNMT-RCM como Prestador de Servicios de Certificación y Sellado”, for conducting CA key pair generation for all CAs, whether root CAs or subordinate CAs that issue certificates to end users. 361. Following this procedure, the FNMT-RCM will prepare and follow a Key Generation Script, have a Qualified Auditor witness the CA Key Pair generation process, and have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair. 362. This procedure describes the following: - roles participating in the ceremony; - functions to be performed by every role and in which phases; - responsibilities during and after the ceremony; and - requirements of evidence to be collected of the ceremony. 363. The procedure of issuing, signing and distributing of new CA Certificate, specifying that before the expiration of the *Certificate* a new one is generated, thus avoiding possible interruptions in the operations from any entity that can trust the *Certificate*. 364. For reasons of security and quality, the *Keys* that the FNMT-RCM needs to carry out its activities as a *Trust Service Provider* will be generated by the Entity itself inside its own infrastructures, in a physically secure environment and by at least two authorised persons. 365. *Key* generation and *Private Key* protection are performed guaranteeing the necessary confidentiality measures, using secure, trusted hardware and software systems under the EESSI CWA14167-1 and CWA14167-2 standards, in addition to the necessary precautions to prevent loss, disclosure, modification or unauthorised use, in accordance with the security requirements specified in the EESSI standards applicable to *Trust Service Providers*. 366. *Key* algorithms and lengths employed are based on standards that are broadly recognised for the purpose for which they are generated. 367. The technical components necessary to create *Keys* are designed so that a *Key* is only generated once and so that a *Private Key* cannot be calculated using its *Public Key*. #### 6.1.1.2 RA Key Pair Generation 368. Not stipulated #### 6.1.1.3 Subscribers Key Pair Generation 369. The *Private keys for* the *Website authentication certificates* are generated and guarded by the *Subscriber* of the *Certificate.* The FNMT-RCM rejects a certificate request if one or more of the following conditions are met: \- 1. The Key Pair does not meet the requirements set forth in the BRL’s Section 6.1.5 and/or Section 6.1.6; \- 2. There is clear evidence that the specific method used to generate the Private Key was flawed; \- 3. The FNMT-RCM is aware of a demonstrated or proven method that exposes the Applicant’s Private Key to compromise; \- 4. The FNMT-RCM has previously been notified that the Applicant’s Private Key has suffered a Key Compromise using the CA’s procedure for revocation request as described in Section 4.9.3 and Section 4.9.12; \- 5. The Public Key corresponds to an industry-demonstrated weak Private Key, including known vulnerabilities such as Debian weak keys, ROCA and Close Primes vulnerabilities. A specific verification method will be applied in each case. ### 6.1.2. Private key delivery to subscriber 370. There is no generation or deliver of the *Private key* to the *Holder.* ### 6.1.3. Public key delivery to certificate issuer 371. The *Public key*, generated along with the *Private key* for the key generation and custody device, is submitted to the Certification Authority by sending a certification request using the PKCS \#10 format. ### 6.1.4. CA public key delivery to relying parties 372. The FNMT-RCM distributes the *Public Keys*, both of the roots CAs and of the subordinate CAs that issue the *Website Authentication Certificates*, through various means, such as publication on its website ([www.sede.fnmt.gob.es](http://www.sede.fnmt.gob.es)), or through public information contained in this document, in section “1.3.1. Certification Authority”. ### 6.1.5. Key sizes and algorithms used 373. The algorithms used in this CP/CPS are: - ECDSA-with-SHA384. - RSA-with-SHA384. 374. The Key size, depending on each case, is: - FNMT root CA Keys: ECC P-384 bits. - FNMT G2R root CA Keys: 4096 bits. - CA Subordinate keys: ECC P-384 bits. - G2R CA Subordinate keys: 4096 bits. - *Website authentication certificate* keys: ECC P-384 bits. ### 6.1.6. Public key parameters generation and quality checking 375. The *Public keys* for the *Website authentication certificates* are encoded under RFC5280 and PKCS#1. ### 6.1.7. Keys usage purposes (KeyUsage field X.509v3) 376. The FNMT *Certificates* include the Key Usage extension and, as applicable, the Extended Key Usage extension, indicating authorised uses of the *Keys*. 377. The root *Certificates* of the CA have enabled the uses of Keys to sign/stamp the *Certificates* of the Subordinated CAs and the ARLs. The *Certificates* of the Subordinate CAs that issue *Website Authentication Certificates* are exclusively authorised to sign/stamp end user *Certificates* (*Website authentication certificates*) and CRLs. Additionally, the G2 type of these Certificates feature the Extended Key Use for server authentication. 378. The *Website authentication certificate* is enabled for use of a digital signature. Additionally, these Certificates feature the Extended Key Use for server authentication and client authentication. ## 6.2. Private key protection and cryptographic module engineering controls 379. FNMT-RCM shall protect its Private Key(s) in accordance with the provisions of this CP/CPS and in a compliance with CA/Browser Forum's Baseline Requirements ### 6.2.1. Cryptographic Module Standards and Controls 380. The *Trust Service Provider*'s *Signature creation data* are protected by a cryptographic device that fulfils FIPS PUB 140-2 Level-3 security standards. Operations for the signing of *Certificates, Revocation lists* and data structures relating to the validity of *electronic Certificates* and *Time Stamps* are carried out inside the cryptographic device, which brings *Confidentiality* to the *Trust Service Provider*'s *Signature creation data*. 381. When the *Signature creation data* are outside the cryptographic device, the FNMT-RCM applies the appropriate technical and organisational measures to guarantee their *Confidentiality.* ### 6.2.2. Private Key (n out of m) Multi-person Control 382. Mechanisms to activate and use the *Certification Authorities’* *Private keys* are based on the segmentation of management and operation roles that the FNMT-RCM has implemented, including multi-person access based on cryptographic cards and related PINs in a simultaneous use M of N (2 of 5) system. ### 6.2.3. Private Key Escrow 383. Copy, backup or recovery operations relating to the *Signature creation data* are controlled exclusively by authorised personnel employing, at minimum, dual control in a secure environment. 384. The *Holders*’ *Private Keys* are held, at a high level of trust, under the exclusive control of the *Holder*. ### 6.2.4. Private Key Backup 385. Backup copies of CA Private Keys shall be backed up by multiple persons in Trusted Role position sand only be stored in encrypted form on cryptographic modules that meet the requirements specified in Section 6.2.1 ### 6.2.5. Private Key Archival 386. Only the FNMT-RCM may make a backup of the *Private keys,* guaranteeing that the security level of the copied data is at least equal to that of the original data and that the number of data duplicated does not exceed the minimum necessary to assure service continuity. The *Signature creation data* are not duplicated for any other purpose. ### 6.2.6. Private Key Transfer into or from a Cryptographic Module 387. The *Certification Authorities*’ *Private keys* are generated as described in point “6.1 *Key* generation and installation”. In the event that a Private Key is to be transported from one Cryptographic Module to another, the Private Key must be encrypted during transport. Private Keys must never exist in plain text form outside the Cryptographic Module boundary ### 6.2.7. Private Key Storage on Cryptographic Module 388. The FNMT-RCM has the necessary means to assure that the cryptographic hardware used to protect its *Keys* as a *Trust Service Provider:* - Has not been manipulated during transportation, by means of an inspection of the material supplied which includes controls to detect authenticity and possible manipulation. - Functions correctly, through continuous monitoring processes, periodic preventive maintenance and a software and firmware upgrade service. - Remains in a physically secure environment from receipt to destruction, if applicable. 389. Root CA private keys of the FNMT-RCM are held and used physically isolated from normal operations such that only designated trusted personnel have access to the keys for use in signing subordinate CA *Certificates*. 390. Root CA private keys of the FNMT-RCM are generated and stored inside cryptographic modules which meet the requirements of 6.2.1 of this *CP/CPS* ### 6.2.8. Activating Private Keys 391. The *Certification Authorities’ Private keys* are generated and custodied by a cryptographic device that meets FIPS PUB 140-2 Level 3 security requirements. ### 6.2.9. Deactivating Private Keys 392. A person in an administrator’s role may deactivate *the Certification Authorities’ Key* by stopping the system. Reactivation will follow the steps described in point “6.2.8 Private key activation method”. ### 6.2.10. Destroying Private Keys 393. The FNMT-RCM will destroy or store the *Trust Service Provider*'s *Keys* in an appropriate manner once the validity period has elapsed so as to avoid misuse. ### 6.2.11. Cryptographic Module Capabilities 394. The cryptographic modules fulfil the security requirements necessary to guarantee *Key* protection, as indicated in point “6.2.1 Cryptographic module standards” of this document. ## 6.3. Other aspects of key pair management ### 6.3.1. Public key archival 395. The *Certificates of authentication of websites* and, in turn, their associated *Public keys,* are kept by the FNMT-RCM during the period of time required by current legislation, which is currently specified as 15 years. ### 6.3.2. Certificate operational periods and key pair usage periods 396. *Certificate* and associated *Key* operating periods are as follows - Root CA *Certificates* and set of *Keys:* see section “1.3.1 Certification Authority” of this *CP/CPS*. - The certificates of the subordinates CA that issue the authentication certificates for websites and their set of *Keys*: see section “1.3.1. Certification Authority” of this *CP/CPS*. - 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 199 days. 397. For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. ## 6.4. Activation data ### 6.4.1. Activation data generation and installation 398. The activation data, both the FNMT root CA *Keys* and the *Keys* of the subordinate CAs that issue end-entity *Certificates*, are generated during the *Certification Authorities*’ *Key* creation ceremony. ### 6.4.2. Activation data protection 399. The activation data for the Certification Authorities’ *Private keys* are protected using the method described in paragraph “6.2.8 Private key activation method” of this document, including multi-person access based on cryptographic cards and related simultaneous use systems. ### 6.4.3. Other aspects of activation data 400. Not stipulated. ## 6.5. Computer security controls ### 6.5.1. Specific Computer Security Technical Requirements 401. When defining security for all the technical components used by the FNMT-RCM in the course of its *Trust Service Provider* activities and in its structure and procedures, all aspects of Information System security certification are taken into consideration, in accordance with the National Information System Security Certification Framework approved in Spain, in particular those relating to EESSI published in the Official Journal of the European Union or in the relevant Spanish Official Journals. Information technology security evaluation under ISO 15408 (Common Criteria) is also taken into account in the design, development, evaluation and acquisition of IT products and systems for use by the *Trust Service Provider*, in addition to the EESSI regulations. 402. The FNMT-RCM shall enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. 403. Infrastructure security management processes will be evaluated periodically. #### 6.5.1.1 Notification of security incidents 404. Incidents are reported to Management, irrespective of whether or not the appropriate corrective action is taken, through the Incident Management System in place in the Department to assure the fastest possible solution, as described in the “Incident Notification Procedure” and “Incident Management Procedure*”*. #### 6.5.1.2 Notification of security weaknesses 405. Security weaknesses are classed as incidents and, as such, are resolved, giving rise to the appropriate corrective action, as described in the above-mentioned procedures. #### 6.5.1.3 Notification of software failures 406. Software failures are classed as incidents and, as such, are resolved, giving rise to the appropriate corrective action, as described in the aforementioned procedures. #### 6.5.1.4 Learning from incidents 407. The “Incident Notification Procedure” and “Incident Management Procedure*”* also include incident groups and classifications giving rise to the relevant corrective actions. ### 6.5.2. Computer Security Rating 408. Technical components supplied to users so as to enhance public trust in the FNMT's cryptographic methods include security evaluations of the products and services offered, applying open criteria accepted by the market. 409. Security levels of infrastructure components and procedures and components forming part of the activities of the *Trust Service Provider* will be evaluated in accordance with “Information Technology Security Evaluation Criteria” (ITSEC/ITSEM) and/or Common Criteria (ISO15408), and particularly the EESSI initiative. 410. Information security management is carried out in accordance with the UNE- ISO/IEC 27001 standard “Information Security Management Systems (ISMS). Requirements”, regulations under which the FNMT-RCM has the corresponding certification in the field of systems involved in the provision of trust services. ## 6.6. Life cycle technical controls ### 6.6.1. System development controls 411. Before undertaking a software development project, the *Trust Service Provider* follows the “Guidelines for the establishment of security requirements for applications developed by Ceres”. This guarantees that computer applications developed undergo a risk assessment process and an analysis of security requirements. 412. The *Trust Service Provider*’s computer applications are developed in accordance with the “Procedure for managing changes in applications developed by Ceres”. This procedure allows identification of the need for emergency corrections or new versions of software, impact assessments, inclusion and documentation of approved changes, and verification that the product definition is consistent. 413. The FNMT-RCM monitors if all third parties linting software, used by the FNMT-RCM, have updated versions available. ### 6.6.2. Security management controls 414. The integrity of the FNMT-RCM’s information and systems, as a *Trust Service Provider,* is protected against viruses, malware and unauthorised access. 415. The FNMT-RCM has procedures guaranteeing the application of security patches in the shortest possible time once they are available, unless application will result in vulnerabilities or operating failures, in which case the reasons for non-application will be documented. ### 6.6.3. Life cycle security controls 416. The FNMT-RCM applies security controls throughout the system life cycles, among which includes the management of media, against obsolescence and deterioration of storage media, during the period of time required, in accordance with the provisions of its backup and recovery policy. #### 6.6.3.1 Algorithm update 417. The FNMT-RCM keeps permanently up to date with the evolution of cryptographic algorithms and undertakes to update the size of *keys* or cryptographic algorithms used by its *Certification Authorities* before reaching an insufficient level of security. ### 6.6.4. Network security controls 418. The FNMT-RCM segments its systems in separated networks or zones taking into account the functional, logical and physical relationship between reliable systems and services. 419. For the correct provision of trust services, external access to them is required through the Internet and / or other networks (for example, Red SARA). Access to the Internet in the Main Data Centre is redundant and, in addition, a different operator provides Internet access to the Backup Centre. The mechanisms of commutation of operators are automatic. Access to Red SARA is also redundant in the Main Data Centre and there is a backup in the Backup Centre, so that, if necessary, it is activated from the Red SARA Operations Centre at the request of FNMT-RCM. 420. The means of communication through public networks employed by the FNMT-RCM in its activities are equipped with sufficient security mechanisms to avoid or adequately control any external aggression through these networks. This system is audited periodically to check that it functions correctly. 421. Similarly, the network infrastructure that provides certification services is equipped with the necessary security mechanisms currently known to guarantee a reliable and comprehensive service. This network is also audited regularly in order to: 1. Verify that the network security controls that meet the network security and certification system requirements. 2. Review monitoring, passwords, etc. for signs of intrusion or weakness. 3. Ensure that the intrusion detection system and other monitoring software are up-to-date. 4. Confirm the ability to shut down certificate issuance quickly if alerted of intrusion. 422. The FNMT-RCM submits to a penetration test the systems related to the provision of trust services, prior to putting it into production and after infrastructure or application upgrades or modifications considered significant. The penetration tests are carried out by the Security and Normalization Area of the FNMT-RCM, which guarantees its execution by qualified personnel who have the necessary skills, tools, proficiency, code of ethics and independence to provide a reliable report. 423. The FNMT-RCM submits to a penetration test the systems related to the provision of trust services, prior to putting them into production and after the updates or modifications of infrastructure or applications considered significant. The penetration tests and the management of the results are the responsibility of the Security and Normalization Area of the FNMT-RCM, which guarantees its execution by independent personnel, who have the necessary skills, tools, competence, code of ethics and independence to provide a reliable report. 424. The FNMT-RCM possess a procedure to carry out the tasks related to the periodic analysis of vulnerabilities and the annual penetration test, treating the results thereof, in terms of their assessment, subsequent elaboration of the corresponding plan of action for correction and, where appropriate, for the corresponding assumption of risks. ## 6.7. Time-Stamping 425. The FNMT-RCM employs as a time source a connection with the Spanish Navy Observatory (UTC time standard) under an agreement between the two institutions to synchronise the time in their systems. The Spanish Navy Observatory (*ROA*) is Spain’s official timing centre. # 7. Certificate, CRLs and OCSP profiles ## 7.1. Certificate profile 426. *Website authentication certificates* are in accordance with the European standard ETSI EN 319 412-4 “Certificate profile for web site certificates”. 427. *Certificates* issued with EV policies (*Electronic Venue certificate EV, EV Certificate and SAN EV Certificate*) contain the policy identifier 0.4.0.2042.1.4., 2.23.140.1.1 and 0.4.0.194112.1.4 428. *Certificates* issued with OV policies (OV *certificate, OV Wildcard Certificate and SAN OV Certificate*) contain the policy identifier 0.4.0.2042.1.7. and 2.23.140.1.2.2 ### 7.1.1. Version number 429. *Website authentication certificates* are compliant with the X.509 version 3 standard. ### 7.1.2. Certificate content and extensions; application of RFC 5280 430. The extensions defined for the FNMT-RCM’s X.509 v3 certificates provide methods for associating additional attributes with users or Public Keys and for managing the certification hierarchy. Each extension in a certificate is designated as either critical or non-critical. 431. Certificate extensions, their criticality, and cryptographic algorithm object identifiers, are provisioned according to the IETF RFC 5280 standards and/or comply with CAB Forum Baseline Requirements and EV Guidelines where appropriate. 432. The documents describing the profiles of the Website authentication certificates, including all extensions, are published at AC SERVIDORES SEGUROS TIPO 1: AC SERVIDORES SEGUROS TIPO 2: ### 7.1.3. Algorithm object identifiers 433. The object identifier (OID) relating to the cryptographic algorithms used are: 1. RSA hierarchy: Algorithm SHA-384 with RSA Encryption with its corresponding OID 1.2.840.113549.1.1.12. 2. ECC hierarchies: Algorithm SHA-384 with ECDSA Encryption with its corresponding OID 1.2.840.10045.4.3.3. ### 7.1.4. Name formats 434. As of the issuance date, all Subject information is accurate, and all attributes present in the Subject field of a certificate have been verified. 435. *Website authentication certificate* encoding follows the RFC 5280 recommendation “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”. All the fields defined in the *Certificate* profile, except where expressly stated in the relevant fields, use UTF8String encoding. 436. *Website authentication certificate* MUST contain a valid and complete Subject Alternative Name (SAN) extension. The dNSName entry in the SAN extension MUST contain either a Fully-Qualified Domain Name or Wildcard Domain Name that the CA has validated in accordance with Section 3.2.2.4. 437. *Website authentication certificate* MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ’ (i.e. space) characters or any indication that a value or field is absent, incomplete, or not applicable. 438. *Website authentication certificate* MUST NOT contain underscore characters (“\_”) in dNSName entries; 439. OU fields are restricted to Subscriber information that has been verified in accordance with section 3 of this CP/CPS; 440. Wildcard Domain Names MUST be validated for consistency with Section 3.2.2.6. The entry MUST NOT contain an Internal Name. 441. The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name MUST consist solely of Domain Labels that are *P-Labels* or *Non-Reserved LDH Labels*. 442. *Website authentication certificate*’s Subject contain the field “OrganizationIdentifier” following the ETSI EN 319 412-1. 443. *Website authentication certificate*’s Subject contain the field “SerialNumber” with the *Subscriptor*’s NIF (Spanish Tax Identification Number) ### 7.1.5. Name constraints 444. The subordinate CA certificates are not technically constrained. ### 7.1.6. Certificate policy object identifier 445. The object identifier (OID) of the *Website authentication certificate* policy is that which is defined in section “1.2 Document Name and Identification” of this document. ### 7.1.7. Usage of the policy constraints extension 446. The “Policy Constraints” extension of the CA's root *Certificate* is not used. ### 7.1.8. Policy qualifiers syntax and semantics 447. The “Certificate Policies” extension includes a “Policy Qualifiers” field: - CPSPointer: contains the URL where the Certification Policies and Practices Statements applicable to this service are published. ### 7.1.9. Processing semantic for the critical certificate policy extension 448. The "Certificate Policy" extension includes the Policy OID field, which identifies the policy associated with the certificate by FNMT–RCM, as well as the related field in the previous section. ## 7.2. CRL profile ### 7.2.1. Version number 449. The CRL profiles are in accordance with standard X.509 version 2. ### 7.2.2. CRL and CRL entry extensions 450. The CRL profiles have the following structures:

Table 8 – CRL profiles
Fields and extensions Value
Version V2
Signature algorithm

ecdsa-with-Sha384 or rsa-with-

Sha384
CRL number INTEGER ≥ 0 and < 2¹⁵⁹, and convey a strictly increasing sequence to each CRL issued by the AC
Issuer Issuer DN
Issue date UTC issuance time.
Date of next upgrade Issue date + 24 hours (with the exception of the ARL, which is Issue date + 6 months)
Authority key identifier Issuer key hash
ExpiredCertsOnCRL NotBefore CA value
Certificates revoked List of certificates revoked, containing at least the serial number and revocation date for each entry
## 7.3. OCSP profile 451. The profile for the Online Certificate Status Protocol (OCSP) messages issued by the FNMT-RCM conform to the specifications contained in the IETF RFC 6960 Internet X.509 PKI Online Certificate Status Protocol (OCSP) Profile. ### 7.3.1. Version number 452. *Certificates* used by the *Certificate validity status information and consultation service*, via OCSP, comply with the X.509 version 3 standard. ### 7.3.2. OCSP extensions 453. The OCSP responses of the *Certificate status information service* on the validity status of the certificates include, for requests that request it, the global extension "nonce", which is used to link a request with a response, so that it is can prevent repetition attacks. 454. Additionally, the extension "Extended Revoked Definition" is included in the cases in which is consulted the status of a *Certificate* that the CA acknowledges as not issued. In this way, the service responds to the query of certificates not issued by the CA as revoked *Certificate*. # 8. Compliance audits and other assessments 455. The system for issuing *Website authentication certificates* is submitted to an audit process annually in accordance with the European standards ETSI EN 319 401 “General Policy Requirements for Trust Service Providers” and ETSI EN 319 411-1 "Policy and security requirements for Trust Service Providers issuing certificates”. 456. In addition, the *Certificates* that are deemed to be *qualified Certificates* are therefore audited to ensure compliance with the requirements set in European standard ETSI IN 319 411-2 “Requirements for trust service providers issuing EU qualified certificates”. 457. Independent auditor annually assess the CA’s compliance to the stated requirements and practices of this CP/CPS, and/or the CAB Forum’s Baseline Requirements and EV Guidelines. 458. Additional Audit plans will be regularly prepared, covering at least the following actions: - Audit of the Information Security Management System in accordance with UNE-ISO / IEC 27001 “Information Security Management Systems. Requirements”. - Audit of the Privacy Information Management System in accordance with UNE-ISO/ IEC 27701 “Privacy Information Management Systems Requirements”. - Audit as ruled in the National Security Scheme (Royal Decree 311/2022, of May 3 , which regulates the National Security Scheme in the field of Electronic Administration). - Audit of the Quality Management System according to ISO 9001. - Audit of the Social Responsibility Management System in correspondence with IQNet SR10. - Audit of the Business Continuity Plan according to ISO 22301. - Audit in accordance with Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/, and Organic Law 3/2018, of December 5, on the Protection of Personal Data and guarantee of digital rights (RGPD / LOPD-GDD). 459. Risk analysis is also carried out, in accordance with the dictates of the Information Security Management System. ## 8.1. Frequency or circumstances of assessment 460. The ETSI audits detailed in the previous section are carried out annually. The corresponding audit plans will be prepared periodically. 461. For *Certificates* that are considered to be qualified (*Electronic Venue certificate EV, EV Certificate and SAN EV Certificate,* the audit additionally guarantees compliance with the requirements of the European standards ETSI EN 319 411-2 “Requirements for trust service providers issuing EU certificates” and ETSI EN 319 412- 4 “Certificate profile for web site certificates”. 462. The frequency of the rest of the additional audits will be in accordance with the provisions of the corresponding current regulations and with the CAB Forum’s Baseline Requirements and EV Guidelines. The operational period during which the Certification Authority issues Certificates shall be divided into a continuous and uninterrupted sequence of audit periods. Each audit period will not exceed a maximum duration of one (1) year. ## 8.2. Identity / qualifications of assessor 463. The auditor that verifies and checks the proper performance of the FNMT-RCM *Trust Service Provider* must be a person or professional with sufficient official qualifications and suitable experience in the matter to be audited, pursuant to legislation in force from time to time. The auditor must at least be accredited under the European standard ETSI EN 319 403. 464. The audit report issued will identify the auditors. The audit report will be signed by the auditors and the head of the entity audited. ## 8.3. Assessor’s relationship to assessed entity 465. These audits may be entrusted to external Audit Firms, to qualified internal personnel (as per applicable legislation) or both. In the case of internal personnel and depending on the criticality of the area to be audited, the level of independence of the personnel involved and their experience will be specified in each case, based on functional independence parameters. 466. Where the audits are performed by personnel external to the FNMT-RCM, the necessary measures and controls are put in place to regulate audit requirements, scope, access to sensitive information and other agreements on *Confidentiality* and responsibility for assets. 467. In external audits, the auditor and the audit firm will never have any employment, commercial or other relationship of any kind with the FNMT-RCM or with the party requesting the audit. The requested audit must always be carried out by an independent professional. ## 8.4. Topics covered by assessment 468. The following controls will be carried out: - Internal network security controls. - Internal contingency plan controls and tests. - Internal Quality and Security controls. - Extraordinary controls: Where required in the circumstances, at the FNMT-RCM’s discretion. ## 8.5. Actions taken as a result of deficiency 469. All weaknesses detected in the audit will give rise to the relevant corrective actions. The corrective action plan will be drawn up as soon as possible and will be kept with the audit report for inspection and follow-up in subsequent audits. 470. Should the weakness entail a serious risk to system security, *Certificates* or *Revocation Lists*, *Signature creation or verification data* or any document or piece of data deemed to be *Confidential* in this document, of the *Subscribers* or of the *Trust Service Provider*, the FNMT-RCM will act as described in the *Continuity Plan* so as to safeguard security in all the infrastructure. 471. The FNMT-RCM will also act diligently to correct the error or defect detected as soon as possible. ## 8.6. Communication of results 472. The competent administrative authorities or courts of law may request the audit reports to verify the proper functioning of the *Trust Service Provider*. 473. The FNMT-RCM will make its Audit Report publicly available no later than three months after the end of the audit period. ## 8.7. Self-Audit 474. Additionally, the FNMT-RCM performs internal audits to self-assess compliance with its *Certification Policies*, *Certification Practices Statement*, applicable regulations, and the requirements established by the CA / Browser forum and to control the quality of the provision of services. These internal audits are carried out at least quarterly, taking a randomly selected sample of at least 3% of the *Certificates* issued during the period that begins immediately after the previous self-assessment sample. 475. The FNMT-RCM uses a linting process to verify the technical accuracy of *Certificates* within the selected sample set independently of previous linting performed on the same *Certificates*. # 9. Other business and legal matters ## 9.1. Fees 476. The FNMT-RCM will apply to the Public Administrations the fees approved by the relevant Under-Secretary’s Office for the provision of certification services or, failing this, the fees stated in the specific management agreement or commission. 477. The fees applicable to the private sector are governed by the agreement for the provision of certification services. Additionally, the FNMT-RCM may determine the fees and payment methods deemed fit from time to time. The price and terms of payment may be consulted in the FNMT-RCM website or will be provided by the relevant commercial area in response to requests sent to the e-mail address comercial.ceres@fnmt.es. ### 9.1.1. Certificate issuance or renewal fees 478. Fees applicable to the issuance or renewal of *Certificates* will be determined as stipulated in paragraph “9.1 Fees” of this document. ### 9.1.2. Certificate access fees 479. Not stipulated. ### 9.1.3. Revocation or status information access fees 480. The FNMT-RCM provides Certificate status information services free of charge by means of the OCSP protocol. ### 9.1.4. Fees for other services 481. Fees applicable to other services will be determined as stipulated in paragraph “9.1 Fees” of this document. ### 9.1.5. Refund policy 482. The FNMT - RCM has a return policy that allows the refund request within the established termination period, accepting that this fact will lead to the automatic revocation of the certificate. The procedure is published at the Website of the FNMT – RCM. ## 9.2. Financial responsibility. 483. The FNMT-RCM has the necessary human, material and financial resources to reasonably cover the application requirements of each declared policy. As a governmental Entity attached to the Ministry of Finance and Civil Service, in patrimonial matters, Law 33/2003, of November 3, of the Patrimony of Public Administrations and its Statute (currently approved by Royal Decree 51/2023, of January 31st), in terms of adequacy, sufficiency, effective application, identification and control of their assets to serve the public service to which they are intended. Additionally, although the national regulations on the provision of trust services establish the exemption of the FNMT-RCM, due to its governmental nature, about the constitution of a civil liability insurance to exercise as a qualified trust services provider, this Entity possess, voluntarily, said insurance, as defined in the following section. ### 9.2.1. Insurance coverage 484. The FNMT-RCM, as a *Trust Service Provider*, as well as a Spanish government body, has third-party liability insurance covering its *Trust Service Provider* activities, with a coverage limit of above €4,000,000. ### 9.2.2. Other assets 485. No stipulation. ### 9.2.3. Insurance or warranty coverage for end-entities 486. No stipulation. ## 9.3. Confidentiality of business information ### 9.3.1. Scope of confidential information 487. The FNMT-RCM has internal regulations developing the Entity’s “Information Security Management System”, in which information classification and processing is defined. ### 9.3.2. Information not within the scope of confidential information 488. The following information is not deemed to be confidential: - Information contained in documents classified as “Public”. - Information contained in *Certificates*. - *Certificate* Revocation Lists (CRLs) and information contained in replies issued by the *Certificate validity status information and consultation service*. 489. Any information that must be published by law. ### 9.3.3. Responsibility to protect confidential information 490. Confidential information relating to the *Trust Service Provider*’s activities will be disclosed subject to prevailing legislation. Information on the activity relating to *Certificate* issuance and management may be disclosed, if requested, as evidence of certification in a court proceeding, even without the *Certificate Holder*’s consent, provided this complies with applicable legislation. ## 9.4. Privacy of personal information 491. The FNMT-RCM publishes the records of processing activities and the rest of the information related to personal data, for consultation by interested parties, at the following website: ### 9.4.1. Privacy plan 492. The processing of personal data carried out by the FNMT-RCM aligns with the provisions of Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation, hereinafter GDPR) as well as the requirements that are application by specific national regulations in this matter. ### 9.4.2. Information treated as private 493. The FNMT-RCM considers as private all personal information about natural persons using trust services not incorporated in the certificates and in the mechanisms used by the *Certificate status information and consultation service*. 494. In any case, all personal information collected in the processes of requesting, renewing and revoking electronic *Certificates* (with the exception indicated in the following section), private keys that are in possession of the Trust Service Provider, as well as all that clearly identified as such, is considered private information. 495. The FNMT-RCM applies the appropriate safeguards to protect private information. ### 9.4.3. Information not deemed private 496. The information incorporated into the electronic *Certificates*, the information regarding the status of the *Certificates*, the date of beginning of that state (active, revoked, expired ...), as well as the reason that caused the status change, is not considered private information. Therefore, electronic Certificates, Revocation Certificate Lists and any content thereof are not considered private information. ### 9.4.4. Responsibility to protect private information 497. The FNMT-RCM adopts the required security measures in accordance with the GDPR regarding the access and treatment it performs on the personal data of applicants and subscribers of the *Certificates*. 498. Technical and organizational measures shall be established taking into account the cost of the technique, the costs of application, as well as the nature, scope, context and purposes of the treatment and the risk to the rights and freedoms of individuals. #### 9.4.4.1 Data Protection Officer 499. The GDPR establishes the obligation to designate a Data Protection Officer (DPO) to any authority or body of the public sector that carries out the processing of personal data. The contact data of the DPO of the FNMT-RCM are published on the website referenced in the first point of this section "9.4 Personal data protection". These contact details include the email address to which the interested parties can address all questions relating to the processing of their personal data and the exercise of their rights, in accordance with article 38.4 of the GDPR. #### 9.4.4.2 Records of processing activities 500. The FNMT-RCM possess records of processing activities carried out under its responsibility, as the "management of the PKI", related to the activity carried out by this Entity as a Trust Services Provider. These records includes, for each processing identified, the following information: 1) Purpose 2) Responsible entity 3) Categories of personal data 4) Who provides the data 5) Who is affected by personal data 6) Who are the people in charge of the treatment 7) Data communications 8) International data transfers 9) Cancellation period 10) Security measures 501. The document of records of processing activities can be consulted on the website referenced in the first point of this section "9.4 Personal data protection". #### 9.4.4.3 Subject’s rights 502. Subjects can exercise the right of access, the right to rectification, to erasure, to restriction of processing, to data portability as well as the right to object to processing and not to be subject to a decision based solely on automated processing, in accordance with the provisions of articles 15 to 22 of the GDPR, by contacting the person responsible for processing electronically, through of the electronic headquarters of the FNMT-RCM, or in person through the General Registry of this Entity. #### 9.4.4.4 Cooperation with the Authorities 503. The FNMT-RCM will cooperate with the Spanish Data Protection Agency when required. #### 9.4.4.5 Notification of personal data breach 504. The FNMT-RCM shall notify to the Spanish Data Protection Agency of any personal data breach, without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. 505. In cases where the personal data breach result in a high risk to the rights or freedoms of data subjects, the notification to the Spanish Data Protection Agency will be complemented by a notification addressed to the subjects, in order to allow them to adopt measures to protect themselves from its consequences. ### 9.4.5. Notice and consent to use private information 506. The obtaining of private information from individuals in the processes linked to the life cycle of the *Certificates* (application, accreditation of identity, renewal, revocation...) will be carried out, in any case, after obtaining the consent of the subject, unambiguously, that is, through a manifestation of the subject or through clear affirmative action. ### 9.4.6. Disclosure pursuant to judicial or administrative process 507. The FNMT-RCM shall not disclose personal data, unless requested by the administrative or judicial authorities. ### 9.4.7. Other information disclosure circumstances 508. No stipulation. ## 9.5. Intellectual property rights 509. The FNMT-RCM has exclusive ownership of all rights, including exploitation rights, to the secure *Directory* of *Certificates*, *Revocation Lists*, *Certificate* status information services and *Time stamping* services, pursuant to the revised Intellectual Property Law introduced by Royal Decree-Law 1/1996 (12 April) (Intellectual Property Law), including the *sui generis* right recognised in Article 133 of that Law. Consequently, access to the secure *Certificate Directories* is permitted for authorised members of the *Electronic Community*, while any reproduction, public disclosure, distribution, transformation or reorganisation is prohibited, unless specifically authorised by the FNMT-RCM or by the Law. The extraction and/or reuse of all or a substantial part of the content, whether from a quantitative or qualitative perspective, is also prohibited, as is repeated or systematic extraction and/or reuse. 510. Access to the *Time stamping* services will be restricted as stipulated in the specific policies and practices governing those services. 511. The FNMT-RCM holds all rights, title and interest to all intellectual and industrial property and knowledge related to this document, 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 document, is prohibited without the express authorization of the FNMT-RCM. 512. The *OID* used in the *Certificates* issued, in *Certificates* employed to provide the services, in *Electronic time stamps* and to store certain objects in the *Directory* are owned by the FNMT-RCM and have been registered at the IANA (Internet Assigned Number Authority), under iso.org.dod.internet.private.enterprise (1.3.6.1.4.1 - IANA-Registered Private Enterprises), the number [1.3.6.1.4.1.5734](http://www.alvestrand.no/objectid/1.3.6.1.4.1.5734.html) having been assigned (FABRICA NACIONAL DE MONEDA Y TIMBRE - REAL CASA DE LA MONEDA). This may be consulted and verified at: 513. Unless a specific agreement is entered into with the FNMT-RCM, the total or partial use of any of the *OID*s assigned to the FNMT-RCM is prohibited, barring the specific needs for which they were included in the *Certificate* or in the *Directory*. 514. Reproduction or copying is prohibited, even for private use of information that may be deemed Software or Databases pursuant to prevailing intellectual property legislation, as well as public disclosure or disclosure to third parties. 515. All extraction and/or reuse of all or a substantial part of the content or databases made available by the FNMT-RCM to *Subscribers* or *User entities* is prohibited. ## 9.6. Representation and warranties ### 9.6.1. CA representations and warranties 516. The obligations and responsibilities of the FNMT-RCM, as a *Trust service provider*, of the *Certificate Subscriber,* and, as applicable, with trusting third parties, determined mainly by the document on the terms and conditions of use contained in the *Certificate* issuance agreement and, secondarily, by this *Certification Practices and Policies Statement.* 517. The FNMT – RCM complies with all requirements contained in the technical specifications of the ETSI EN 319 411 standard for the issuance of Certificates and undertakes to continue complying with said regulation or those that replace it. 518. The FNMT-RCM issues the *Website authentication certificate* in accordance with the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates”, established by the entity CA/Browser forum, which may be consulted at the following address: Likewise, it will adapt its issuance practices for these *Certificates* to the version of the aforementioned requirements currently in effect. In the event of any inconsistency between this *CP/CPS* and the aforementioned version, said requirements shall prevail over those contained in this document. 519. In addition, the FNMT-RCM undertakes to comply, with regard to the issue of EV Certificates (*Electronic Venue certificate EV, EV Certificate and SAN EV Certificate),* all requirements established by the entity CA/Browser for these types of Certificates (EV SSL Certificate Guidelines), and which can be consulted at . In the event of any inconsistency between this *CP/CPS* and the aforementioned version, said requirements shall prevail over those contained in this document. 520. Without prejudice to any of the provisions contained in any the regulations applicable to these types of *Certificates*, as well as the obligations described in the corresponding section of this document*,* the *Trust Service Provider* undertakes to: 521. Prior to *Certificate* issuance - Implement a procedure for verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) listed in the Certificate’s subjectAltName extension. - Verify that the *Applicant* has acknowledged and accepted the Terms of Use. - Verify the identity and personal circumstances of the *Applicant* for the *Certificate* and of the *Subscriber* and/or their *Representative,* and collect their declaration that the *Applicant* is authorised by the *Subscriber* to make such request. The identification will be made through verified *Certificates* with electronic signature accepted during the FNMT-RCM processes. - Verify all data related to the legal personality of the *Subscriber* and regarding legal capacity of the *Representative d*uring the registration process. All these checks will be carried out as per the provisions of the *Special Certification Practices Statement* expressed in this document, and in accordance with the registration protocols and procedures of the FNMT-RCM. > The FNMT-RCM may perform verifications with the involvement of third > parties holding notarised powers of representation, or public or > private registries as a part of the processes undertaken to verify the > aforementioned aspects. - Verify that all the information contained in the *Certificate* application matches the information provided by the *Applicant*. - Verify that the *Applicant* is in possession of the *Private Key* associated with the *Public Key* that is included in the Certificate to be issued. - Ensure that the procedures followed guarantee that the *Private Keys* corresponding to the *Website authentication certificates* are generated without any copies being made, or any storage of them being performed by FNMT-RCM. - Perform the communication of information to the *Subscriber*, *Representative* and *Applicant* in such a manner that its *Confidentiality* is protected. - Make available to the *Applicant, Subscriber, Representative* and any other interested parties ( ) the *Declaration of Certification Practices* and how much information is relevant for the development of the procedures related to the life cycle of the *Certificates* object of this *Special Certification Policy and Practices Statement* in accordance with applicable regulations. - Maintain a 24x7 online-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates. - The FNMT-RCM will revoke the Certificate for any of the reasons specified in this document and CAB Forum Requirements. ### 9.6.2. RA representations and warranties 522. The activities related to the RA will be carried out exclusively by the FNMT-RCM, through its Registry Area*.* 523. The RA, through the Registry Area of the FNMT-RCM, has the following obligations: - In general terms, to follow all procedures established by the FNMT-RCM in the *Certification Policy and Practices Statement* in terms of the performance of its functions of management, issuance and revocation of Certificates, and to not take any steps to alter this operating framework. - In particular, to verify the identity, and any personal data that may be relevant for the specified purpose, of *Applicants* for *Certificates*, *Subscribers* and their *Representatives*, using any of the methods permitted under the Law, and in accordance, in general terms, with the provisions contained in this document*.* - Verify that the ownership of the domain name corresponds to the identity of the *Subscriber* or, if applicable, obtain authorisation from the latter, which will be associated with the *Website authentication certificate*, by any means at its disposal that would reasonably allow it to believe such ownership, in accordance with the state of the art. - Expressly obtain the statement of the *Subscriber* in relation to the ownership of the domain of the *Website authentication certificate*, stating that it has sole decision-making power over it. - Preserve all information and documentation relating to *Certificates,* maintaining all application, renewal or revocation data for fifteen (15) years. - Handle the receipt and management of applications and the issuance contracts (pdf form) sent to *Certificate Subscribers.* - Diligently check the causes for revocation that could affect the validity of *Certificates*. ### 9.6.3. Subscriber representations and warranties 524. FNMT-RCM will require, as part of the Terms and Conditions, the Applicant’s agreement with the obligations and warranties set forth in this section. The Certificate will not be issued until the Applicant’s acceptance of the terms and conditions. 525. The *Applicant* will be answerable for the truth of the information submitted during Certificate application and for the Certificate application to be made from equipment or a device that he or she may use to a high degree of trust under his or her exclusive control. 526. The *Applicant* will hold the FNMT-RCM harmless from and undertake defence at its own cost against any action that may be initiated against the latter entity as a result of the falseness of the information supplied in the Certificate issuance procedure or from any damage that the FNMT-RCM may incur as a result of an act or omission by the Applicant. 527. The *Subscriber* must fulfil security regulations related to the custody and use of information guaranteeing access to his or her *Private keys*. 528. The FNMT-RCM, in its activities as a *Trust Service Provider*, where permitted, envisaged or required by prevailing legislation, may obtain the e-mail address, mobile telephone number for the receipt of text messages and address of the *Subscribers* in contracts submitted to *Applicants* for signing, before issuing a *Certificate* or contracting a specific service. 529. This information is included in order to provide the trust services of which the said *Subscribers* are users and/or to notify events of interest to the *Subscriber* related to the FNMT-RCM's services and the *Certificates*, particularly those related to the revocation and suspension of *Certificates* or the termination of any agreements between the FNMT-RCM and the *Subscribers*. Additionally, the said information will be used as a communication channel to cover any need in the event of a disaster contingency that might disable the FNMT-RCM. 530. The *Applicant* and, subsequently, the *Subscriber* will be responsible for keeping the information up to date and correct. 531. *Subscribers* must have control of the website domain name included in said *Certificates* and maintain all associated *Private keys* under their exclusive use. 532. The *Applicant* and the *Subscriber* of the *Certificates* issued under this *CPPS* have the obligation to: - Do not use the *Certificate* outside the limits specified in this special *Certification Policy and Practices Statement* - Not to use the *Certificate* in the event that the *Trust Service Provider* that issued the certificate in question has ceased its activity as Certificate Issuer, in particular in any cases where the Supplier's Creation Data may be compromised, and this fact has been expressly communicated. - Provide truthful information in any applications for *Certificates* and keep it updated, with all contracts being signed by an individual with sufficient capacity for such purpose. - Not to request for the *Subject* of the certificate any distinctive signs, denominations or industrial or intellectual property rights of which it does not own, license, or have demonstrable authorisation for its use. - Install the *Certificate* only on servers that are accessible at the subjectAltName(s) listed in the *Certificate*, and to use the *Certificate* solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use - Acting diligently with respect to the custody and preservation of the *Signature/Seal Creation data* or any other sensitive information such as *Keys, Certificate* activation codes, access words, personal identification numbers, etc., as well as the *Certificates* themselves, which includes, in any case, the commitment to maintain all mentioned data confidential. - To be aware of and comply with the conditions of use of the *Certificates* provided for under the conditions of use and in the *Certification Practices Statement,* and, in particular, all applicable limitations of use of the Certificates - Become aware of and comply all modifications that may arise in the *Certification Procedure Statement.* - To request the revocation of the corresponding *Certificate,* according to the procedure described in this document, duly notifying the FNMT-RCM of the circumstances for revocation or suspected loss of *Confidentiality*, unauthorised disclosure, modification or use of the associated *Private keys,* - Review the information contained in the *Certificate* and notify the FNMT-RCM of any error or inaccuracy. - Verify the *Advanced Electronic signature* or *Advanced Electronic seal* provided by the *Trust Service Provider* issuing any *Certificates* prior to trusting them. - Diligently report any modification of the data provided in the application for the *Certificate* to the FNMT-RCM, requesting, when pertinent, the revocation of the same. 533. In any event, it shall remain the responsibility of the *Subscriber* to use appropriately use diligently guard the *Certificate,* according to the specific purpose and function for which it was issued, and to inform the FNMT-RCM regarding any potential variation of status or information with respect to that which is contained in the *Certificate,* so that it may be revoked and re-issued. 534. Likewise, Subscriber shall be answerable, in all cases, to the FNMT-RCM, the User Entities and, when applicable, to third parties, with regard to any improper use of the *Certificate* or for any inaccuracy or errors in the declarations contained in it, or for acts or omissions causing harm to the FNMT-RCM or third parties. 535. It will be the responsibility and, therefore, obligation of the *Subscriber* not to use the *Certificate* in the event that the *Trust Service Provider* has ceased in the activity as *Certification Entity* that made the issuance of the Certificate in question, and in the case that the subrogation detailed under the law is not performed. In any event, the *Subscriber* must not use the *Certificate* where the *Provider's Signature creation data* may be jeopardised and/or compromised and the Provider has notified this or, if applicable, has become aware of these circumstances. 536. With regard to *Electronic Venue certificate EV*, public entity *Subscribers,* represented through various authorised bodies, acting through the *Registry Operations Manager* for the issuance of these types of Certificates, must: - Not to register or process requests for *Electronic Venue certificate EV* by personnel who render their services in an entity other than that represented as the *Registry Office*, unless expressly authorised by another entity. - Not to register or process requests for *Certificates* issued under this policy and whose *Subscriber* corresponds to a public entity over which it has no powers, or does not have powers to act as the *Registry Office.* - Not perform registrations or process requests for *Certificates* issued under this policy and whose *Subscriber* does not correspond to the ownership of the e-mail address through which the *Website* contained in the *Certificate* that is the subject of the request will be accessed. - Not to register or process requests for *Certificates* issued under this policy and whose *Applicant* corresponds to an individual who does not provide services at the entity of the *Subscriber* of the *Certificate* and/or has not been authorised by the person acting as representative of the Public Entity for the management and administration of the electronic address through which the *Website* which will identify the Certificate object of the application is accessed. - Reliably verify the identification and authorisation data of the *Certificate Subscriber* (the Entity that owns the *Website* and the e-mail address, domain or URL through which such Site is accessed) and the *Applican*t (the individual with sufficient powers to request an *Electronic Venue certificate EV*) for the *Certificate,* and verify that it matches with the owner and all contacts contained in the corresponding databases, for the management and administration of the e-mail address through which the *Website* identified in the *Certificate* will be accessed. - To request the revocation of the *Electronic Venue certificate EV* issued under this policy when any of the data referred to the Subscriber or to the electronic address included in the *Certificate* is incorrect, inaccurate, or has changed with respect to that which is recorded in the *Certificate*, or does not correspond to the owner and contacts established in the corresponding databases for the management and administration of the e-mail address referenced in the *Certificate* subject to the revocation. 537. The relationships of the FNMT-RCM and the *Subscriber* will be determined mainly, for the purposes of the use regime of the *Certificates*, through the document related to the conditions of use or, where appropriate, the contract for the issuance of the *Certificate* and in accordance with all contracts, agreements or relationship documents entered into between the FNMT-RCM and the corresponding Public Entity. ### 9.6.4. Relying party representations and warranties 538. It will be the responsibility of the User Entity and of the trusting third parties who use the Certificates to verify and check the status of said Certificates, in no case acting to assume the validity of the Certificates without these verifications. 539. In the case of a *Qualified Certificate*, verify that the service identifier is the one published in the corresponding *Trusted Service List*, accessible through the following link: 540. Should the circumstances require additional guarantees, the User entity must obtain them in order for trust to be reasonable. 541. Moreover, the User entity will be responsible for observing the provisions of the Certification Practices Statement and any future amendments to it, paying particular attention to the stipulated restrictions on the use of Certificates in this Certification Policy. ### 9.6.5. Representations and warranties of other participants 542. Not stipulated. ## 9.7. Disclaimers of warranties 543. Not stipulated. ## 9.8. Limitations of liability 544. The FNMT-RCM will only be answerable for the correct personal identification of the *Applicant* and future *Holder*, and for including these data in a *Certificate*. In order for the guarantees, obligations and responsibilities to be applicable, the event must have taken place within the scope of the *Electronic Community*. 545. The FNMT-RCM will only be answerable for weaknesses in the procedures pertaining to its own activities as a *Trust Service Provider* and in accordance with these *Certification Policies* or the Law. It will not in any circumstances be liable for actions or losses that may be incurred by *Holders*, *Subscribers*, *User entities* or third parties which are not due to errors attributable to the FNMT-RCM in the above-mentioned *Certificate* issuance and/or management procedures. 546. The FNMT-RCM will not be liable for force majeure events, terrorist attacks, wildcat strikes or actions constituting offences or misdemeanours that affect its facilities in which the services are provided, unless the Entity is guilty of serious negligence. In any event, the FNMT-RCM may include disclaimers in the relevant contracts and/or agreements. In any case, the amount of damages that the FNMT-RCM would be required to pay to affected third parties and/or members of the *Electronic community* as a result of a court order, in the absence of specific provisions of contracts or agreements, is limited to a maximum of SIX THOUSAND EUROS (€6,000). 547. The FNMT-RCM will not be answerable to persons whose behaviour in the use of the *Certificates* has been negligent; for these purposes, and in any event, negligence will be regarded as the failure to comply with the provisions of this *Certification Practices and Policies Statement* and, in particular, the provisions of the sections that refer to the parties’ obligations and liability. 548. The FNMT-RCM will not be liable for any software that it has not provided directly. Nonetheless, the FNMT-RCM will put in place adequate measures to protect its systems against *Malicious software (Malware)* and will diligently keep them up to date to cooperate with users in the avoidance of the damage that such software may cause. 549. The FNMT-RCM does not guarantee the cryptographic algorithms and will not be liable for damage caused by successful external attacks on the cryptographic algorithms used, provided it acted with due diligence based on the current state of technology and in accordance with this *Certification Practices and Policies Statement* and the Law. 550. The FNMT-RCM in the provision of its service as a Time Stamping Authority, shall not be held responsible for any damage or harm and/or defective operations that the Electronic Time Stamps that it issues cause as a result of the uses that are made of them, either due to the fault of interested parties or defects in the original data. 551. The FNMT-RCM in the provision of its service as a Time Stamping Authority, shall not be liable to anyone whose behaviour when using the Qualified Time Stamping Service and/or the Electronic Time Stamps themselves is negligent. For these purposes, and in all cases, failure to observe the provisions established in these Policies and Practices for the Qualified Time Stamping Service, in the \[TSPS\] and, in particular, the provisions in the sections relating to the obligations and responsibilities of the parties, shall be deemed to constitute negligence 552. The FNMT-RCM in the provision of its service as a Time Stamping Authority, shall not be liable in the event of unforeseen circumstances, force majeure, terrorist attacks, wildcat strikes, or in the case of events involving actions that constitute a crime or failure that affects the underlying infrastructure, except in the event that the entity itself committed a serious breach. In any case, in the corresponding contracts and/or agreements, the FNMT-RCM may establish additional liability limitation clauses to those reflected in this document. 553. The FNMT-RCM in the provision of its service as a Time Stamping Authority, shall not be responsible for any software that it has not supplied directly. 554. The FNMT-RCM does not guarantee the cryptographic algorithms and shall not be held liable for any damage caused by successful external attacks on the cryptographic algorithms used, provided it maintains due care over them, in accordance with the current status of the technique, and acts in accordance with the provisions of the applicable Policies and Practices for Trusted Services and Electronic Certifications and the Law. ## 9.9. Indemnities 555. The FNMT-RCM may include indemnity clauses in the legal instruments linking it to the *Holder* for the infringement of the latter’s obligations or of applicable legislation. In this respect, see also point “9.6 Obligations and guarantees” and “9.8. Limitations of liability”. ### 9.9.1. CA indemnity 556. Not stipulated. ### 9.9.2. Subscribers indemnity 557. Not stipulated. ### 9.9.3. Relying parties indemnity 558. Not stipulated. ## 9.10. Term and termination ### 9.10.1. Term 559. This *Certification Practices and Policies Statement* will come into force when it is published. ### 9.10.2. Termination 560. This *Certification Practices and Policies Statement* will be terminated when a new version of the document is published. The new version will entirely supersede the previous document. The FNMT- RCM undertakes to subject the said Statement to an annual review process. ### 9.10.3. Effects of termination and survival 561. For valid *Certificates* issued under a previous *Certification Practices* and *Policies Statement*, the new version will prevail over the previous version in all matters that do not conflict. ## 9.11. Individual notices and communication with participants 562. The FNMT-RCM, in its activities as a *Trust Service Provider*, where permitted, envisaged or required by prevailing legislation, may obtain the e-mail address, mobile telephone number for the receipt of text messages and/or address of the *Subscribers* during the application process and before issuing a *Certificate*. 563. This information is included in order to provide the trust services of which the said *Subscribers* are users and/or to notify events of interest related to the FNMT-RCM's services, particularly those related to the revocation *Certificates* or the termination of any agreements between the FNMT-RCM and the *Subscribers*. Additionally, the said information will be used as a communication channel to cover any need in the event of a disaster contingency that might disable the FNMT-RCM. 564. The *Applicant* and, subsequently, the *Subscribers* will be responsible for keeping the information up to date and correct. ## 9.12. Amendments ### 9.12.1. Procedure for amendment 565. Amendments to this *Certification Practices and Policies Statement* will be approved by Ceres Department management and will be reflected in the relevant minutes of the Provider's Management Committee meetings, pursuant to the internal procedure approved in the document “Review and maintenance procedure for certification policies and the trust service practices statement”. ### 9.12.2. Notification mechanism and period 566. Any amendment to this *Certification Practices and Policies Statement* will be immediately published in the URL where it may be accessed. 567. Should the amendments not entail significant changes to the parties’ obligations and responsibilities or the modification of the service provision policies, the FNMT-RCM will not previously inform users and will simply post a new version of the statement in question on its website. ### 9.12.3. Circumstances under which an OID must be changed 568. Significant amendments to the terms and conditions of the services, obligations and responsibilities, or restrictions on use may give rise to a change to the service policy and identification (OID), as well as a new link to the new service policy statement. In this case, the FNMT-RCM may establish a mechanism for providing information on the proposed changes and, if applicable, gathering opinions from the affected parties. ## 9.13. Dispute resolution provision 569. The FNMT-RCM will respond to any request, complaint or claim from its customers or third parties that place their trust in its trust services, pursuant to the protocols approved by the Entity through the internal procedure “Protocol for the management of corrective, preventive and improvement actions", "Protocol for the management of suggestions, complaints and claims" and "Protocol for the management of incidents". The contact data for such complaints or claims are provided in point “1.5.2 Contact details for this document”. ## 9.14. Governing law 570. The provision of trust services by the FNMT-RCM will be governed by the laws of Spain. 571. The following legislation is applicable to these trust service practices: - Law 6/2020 (11 November) regulating certain aspects of electronic trust services. - Law 39/2015 (1 October) on the Common Administrative Procedure for Public Administrations. - Law 40/2015 (1 October) on the Public Sector. - Organic Law 3/2018, of December 5, Protection of Personal Data and Guarantee of Digital Rights. - Regulation (EU) No. 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC. - Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). 572. Additionally, the practices of the trust services provided by the FNMT-RCM follow the following standards: - ETSI EN 319 401: General Policy Requirements for Trust Service Providers - ETSI EN 319 411-1: Policy and security requirements for Trust Service Providers issuing certificates. General requirements. - ETSI EN 319 411-2: Requirements for trust service providers issuing EU qualified certificates - ETSI EN 319 412: Electronic Signatures and Infrastructures (ESI); Certificate Profiles - ETSI EN 319 421: Policy and Security Requirements for Trust Service Providers issuing Time-Stamps - ETSI EN 319 422: Time-stamping protocol and time-stamp token profiles. - CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TSL Server Certificates - CA/Browser Forum EV Guidelines - Web accessibility standard UNE-EN 301 549 - Chrome Root Program Policy, Mozilla Root Store Policy, Microsoft Trusted Root Program and Apple Root Certificate Program. - CCADB Policy 573. In general, the members of the *Electronic Community* and *Users* of the FNMT-RCM’s trust services accept that any lawsuit, discrepancy, matter or claim arising from the enforcement or interpretation of the *Trust Service and Electronic Certification Practices Policies and/or Declarations* or related to them directly or indirectly will be resolved in accordance with the provisions of the relevant contracts, general terms and conditions and/or commissions or agreements, in the terms stated in the Entity’s Statute introduced under 51/2023 (of January 31st) (Official State Gazette no. 27 of February 1st,2023). 574. In the event that the contracts, general terms and conditions and/or commissions or agreements do not specify any conflict resolution arrangement, all the parties submit to the exclusive jurisdiction of Spanish courts in the city of Madrid. 575. In addition, mediation or arbitration procedures may be agreed, subject to the approval of the competent bodies of the FNMT-RCM, in accordance with applicable legislation. ## 9.15. Compliance with applicable law 576. The FNMT-RCM expresses its commitment to comply with all regulations and the application requirements applicable for each type of *Website authentication certificate*, including the considerations established in section "1.5.4. DPC Approval Procedure” of this *CP/CPS* document. ## 9.16. Miscellaneous provisions ### 9.16.1. Entire Agreement 577. The *Subscribers* and third parties placing their trust in the *Certificates* fully accept the content of this *Certification Practices and Policies Statement.* ### 9.16.2. Assignment 578. The FNMT-RCM will not be responsible for the lack of service or service anomalies, nor for any damage that may be caused directly or indirectly, when the failure or disaster is the result of force majeure causes, a terrorist attack, sabotage or wildcat strikes, all without affecting any actions necessary to correct and/or restore the service as soon as possible. ### 9.16.3. Severability 579. In case of conflict of any part of this document with current legislation of any jurisdiction in which a CA operates or issues certificates, after the corresponding legal review, FNMT-RCM can modify the conflicting points the minimum extent necessary to fulfill the aforementioned legislation. 580. In such event, (prior to issuing a certificate under the modified requirements) FNMT-RCM will include in subsections of this Section information about the Law requiring modification and the specific change implemented by FNMT-RCM. 581. FNMT-RCM will also (prior to issuing a certificate under the modified requirement) inform interested parties such as the CAB Forum of the relevant information newly added. 582. FNMT-RCM makes any changes to its practices that are allowed under a certain legal provision, these changes must stop once that law is no longer valid, or if the requirements change in a way that allows the FNMT-RCM to follow both the law and the CABForum’s requirements at the same time. FNMT-RCM will then adjust its practices, update its Certificate Policy Statement (CP/CPS), and notify the CA/Browser Forum. This will all be completed within 90 days. ### 9.16.4. Enforcement (attorneys' fees and waiver of rights) 583. Not stipulated. ### 9.16.5. Force Majeure 584. Not stipulated. ## 9.17. Other provisions 585. The FNMT-RCM, as a *Trust Service Provider*, will provide services to all interested parties that request them on the terms stipulated in this document and the Policies, Practices and Issuance Laws applicable to the purpose of the application. 586. The FNMT-RCM’s trust services, adequately used and combined, will allow *Users*, *Subscribers* and *Holders*, among others, to obtain information exchange security measures necessary for the identification, authentication, non-repudiation and confidentiality of the parties. 587. The FNMT-RCM manages its certification services and issues *Certificates* in accordance with the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates", established by the entity CA/Browser forum, which may be consulted at the following address: and in accordance with the latest version of the requirements defined by the entity CA / Browser forum in its "Guidelines for the Issuance and Management of Extended Validation Certificates" (which can be consulted at the address ). 588. The FNMT-RCM will review its certification policies and practices so that they remain in line with the said requirements. On publication of new versions of the requirements document and in the event of an inconsistency, the FNMT-RCM will act diligently to correct any departures or, if appropriate, include a notification in this document on infringements committed. 589. In case of loss of the QSCD certification of any of the qualified signature / seal creation devices used by FNMT-RCM, as a Trusted Service Provider, appropriate measures will be taken to reduce the possible impact. The supervisory body will be informed about this and FNMT-RCM will stop the issuance of *Certificates* on those devices. 590. The organizational structure of the FNMT-RCM guarantees that the units related to the *Certificate* generation and revocation management are independent of other units for its decisions relating to the establishing, provisioning and maintaining and suspension of services in conformance with the applicable certificate policies. The document “CERES - Organización del Departamento” defines this organizational structure. Additionally, the legal nature of the FNMT-RCM, as a governmental entity attached to the General State Administration, guarantees that its senior executive, senior staff and staff in trusted roles are free from any commercial, financial and other pressures which might adversely influence trust in the services it provides. 591. The FNMT-RCM applies the principles of equal opportunities, non-discrimination and universal accessibility to its services, processes and procedures. The measures adopted reasonably comply with the basic criteria and conditions of accessibility and non-discrimination in accordance with the applicable regulations (see section "9.14 Applicable legislation"), with the aim of guaranteeing that users of trust services, in no case, suffer discrimination in the exercise of their rights and faculties due to reasons based on disability or advanced age. Additionally, the websites of the FNMT-RCM are subject to analysis in terms of compliance with accessibility requirements, such as the Accessibility Observatory of the Ministry of Finance. 592. The FNMT-RCM allows third parties to check and test all types of certificates issued. For this, it has a set of test certificates that can be requested through the email address in the section "1.5.2 Contact details". # Appendix I: FNMT-RCM “SERVIDORES SEGUROS” root Certificate profile
APPENDIX I: FNMT-RCM “SERVIDORES SEGUROS” ROOT CERTIFICATE PROFILE
Field Content Critical ext.

  1. Version

 2

  1. Serial Number

 Certificate Serial number.

  1. Signature Algorithm

ecdsa-with-SHA384

Keys: ECC P-384 bits

  1. Issuer Distinguish Name

 Issuer Certificate (CA root)

  1. Country

 C=ES

  1. Organization

 O=FNMT-RCM

  1. Organization Unit

 OU=Ceres

  1. OrganizationIddentifier

 VATES- Q2826004J

  1. CommonName

 cn=AC RAIZ FNMT-RCM SERVIDORES SEGUROS

  1. Validity

 25 years

  1. Subject

  1. Country

 C=ES

  1. Organization

 O=FNMT-RCM

  1. Organization Unit

 OU=Ceres

  1. OrganizationIddentifier

 VATES- Q2826004J

  1. CommonName

 cn=AC RAIZ FNMT-RCM SERVIDORES SEGUROS

  1. Subject Public Key Info

 ECC P-384 bits

  1. Subject Key Identifier

 CA Key Identifier. Means to identify certificates that contain a particular public key and facilitates the construction of certification routes.

  1. Key Usage

 Allowed use of certified keys. yes

  1. Digital Signature

 0

  1. Content Commitment

 0

  1. Key Encipherment

 0

  1. Data Encipherment

 0

  1. Key Agreement

 0

  1. Key Certificate Signature

 1

  1. CRL Signature

 1

  1. Basic Constraints

 yes

  1. cA

 Value TRUE (CA)

  1. pathLenConstraint

 None
# Appendix II: FNMT-RCM “SERVIDORES SEGUROS G2R” root Certificate profile
APPENDIX I: FNMT-RCM “SERVIDORES SEGUROS” ROOT CERTIFICATE PROFILE
Field Content Critical ext.

  1. Version

 2

  1. Serial Number

 Certificate Serial number.

  1. Signature Algorithm

Sha384WithRSAEncryption

Keys: RSA 4096 bits

  1. Issuer Distinguish Name

 Issuer Certificate (CA root)

  1. Country

 C=ES

  1. Organization

 O=FNMT-RCM

  1. CommonName

 cn=AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R

  1. Validity

 15 years

  1. Subject

  1. Country

 C=ES

  1. Organization

 O=FNMT-RCM

  1. CommonName

 cn=AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R

  1. Subject Public Key Info

 RSA 4096 bits

  1. Subject Key Identifier

 CA Key Identifier. Means to identify certificates that contain a particular public key and facilitates the construction of certification routes.

  1. Key Usage

 Allowed use of certified keys. yes

  1. Digital Signature

 0

  1. Content Commitment

 0

  1. Key Encipherment

 0

  1. Data Encipherment

 0

  1. Key Agreement

 0

  1. Key Certificate Signature

 1

  1. CRL Signature

 1

  1. Basic Constraints

 yes

  1. cA

 Value TRUE (CA)

  1. pathLenConstraint

 None
[^1]: > Issued in accordance with requirements established under Annex IV > of Regulation (EU) No. 910/2014 of the European Parliament and of > the Council of 23 July 2014 on electronic identification and trust > services for electronic transactions in the internal market and > repealing Directive 1999/93/EC. [^2]: > *Note:* The OID or policy identifier is a reference that is > included in the Certificate in order to determine a set of rules > that indicate the applicability of a certain type of *Certificate* > to the *Electronic Community* and/or Application class with the > same security requirements. [^3]: Royal Legislative Decree 5/2015, of October 30, approving the revised text of the Basic Employee Statute Law.