## **FNMT Certification Practice Statements** **Documents Reviewed:** This is a review of: **Root CPS, version 5.7** (Declaración General de Prácticas de Certificación – “DGPC) https://www.sede.fnmt.gob.es/documents/10445900/10536309/dgpc_english.pdf , and **CPS for EV and OV Certificates** (Política y Prácticas de Certificación particulares de los certificados de Servidores Seguros – “DPPP”), **version 1.3**, English translation - https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf. ### **Good** **Generally** Both CPSes (DGPC and the DPPP) are formatted according to RFC 3647, as required by section 2.2 of the Baseline Requirements. There is a Document History table for the DGPC and the DPPP. This is good because it shows change management by the CA’s Policy Authority and demonstrates annual review / revision of the CPS. **Specifically** (sections refer to the DPPP unless otherwise indicated) 1.3.1 – 20 The PKI hierarchy is presented in the DGPC and there is a separate PKI hierarchy for server certificates under the “Servidores Seguros” root certificate. 1.4.2 - 23 This section of the DPPP prohibits the use of server certificates for interception of communications and man-in-the-middle attacks. 1.5.4 – 30 CPS is updated and re-versioned annually, even if no other changes are made. Mozilla Root Store Policy, section 3.3 (subsection 4), requires that the CPS be reversioned and re-dated, even if there are no changes. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses 3.1.1 – 42 “FNMT-RCM complies with X.500, RFC 5280 and CA/Browser Forum requirements for naming.” 3.2.2.4 - 62 “[B]efore issuing a Website authentication certificate, it is verified that the domain to be included in the Certificate is public (i.e. it is not an internal domain)” (Per section 3.2.2.5 – 63, FNMT does not issue certificates to IP addresses) 3.2.4 – 69 All information in the certificate is verified. There is no unverified information in the certificate. 4.2.1 – 86 “Reuse of previous validation data or documentation obtained from a source specified under section 3.2 may be used no more than 13 months after such data or documentation was validated.” 4.2.2 – 87 “The RA that acts in the process of issuing *Website authentication certificates* is shall always be that of the FNMT-RCM itself, and, therefore, the validation of domains will never be delegated to any other AR.” This is good because third parties are not allowed to perform domain verification. See Baseline Requirements section 1.3.2 - “With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.” 4.2.2 – 93 CAA record processing is specified, as required by section 2.2 of the Baseline Requirements. 4.3.1 – 96 “Once the application for the Certificate has been approved by the RA of the FNMT-RCM's, the system then performs pre-issuance linting to check compliance with RFC 5280 and CA/Browser Forum (BRs and EVGs). Only where no errors are found, FNMT-RCM proceeds to issue the Certificate according to the profile approved for each corresponding type of Certificate.” 4.3.1 – 98 “The processes related to the issuance of electronic Certificates guarantee that all the accounts that interact with them include multi-factor authentication.” Subsection 3 of section 2.1 of the Mozilla Root Store Policy requires that any accounts capable of certificate issuance use multi-factor authentication. 4.9.1.1 – 141 Reasons for Revoking a Subordinate CA follow those in section 4.9.1.1 of the Baseline Requirements. 4.9.2 – 145 “Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate” 4.9.5 – 152 “All revocation requests for end entity Certificates, are processed within a maximum of 24 hours of receipt.” 4.9.7 – 155 “Revocation lists (CRLs) for end-entity Certificates are issued at least every 12 hours, or whenever there is a revocation; they have a 24-hour validity period” 5.7.3 – 236 **(of the DGPC)** In the event of a key compromise, FNMT will “3) Execute the Communication Plan to notify of the events affected parties and to the browsers in whose root programs the FNMT-RCM certificates are included.” 6.1.1.3 – 226 “The Private keys for the Website authentication certificates are generated and guarded by the Subscriber of the Certificate.” Section 5.2 of the Mozilla Root Store Policy prohibits key generation for the Subscribers of server certificates. 6.1.5 – 231 FNMT only allows ECC P-384. 9.6.1 – 318 “In the event of any inconsistency between this DPPP and the aforementioned version, said requirements shall prevail over those contained in this document.” Section 2.2 of the Baseline Requirements and section 8.3 of the EV Guidelines say that the CA must include in the CPS such statements. Section 9.10.2 **of the DGPC – 428** The FNMT- RCM undertakes to subject the CPS to an annual review process. ### **Meh** 1.5.2 - 27 This section should also mention “revocation requests”. Currently it only says, “To report security issues such as suspected key compromise, certificate misuse, fraud or other matters, contact incidentes.ceres@fnmt.es” 4.9.13 – 161 CPS states, “The suspension of certificates is not covered.” Does this mean that suspension is not an option, not provided? 4.10 I couldn’t see where the validity period of an OCSP response was specified. Section 6 of Mozilla Root Store Policy provides, For end-entity certificates, if the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service: - it MUST update that service at least every four days; and - responses MUST have a defined value in the nextUpdate field, and it MUST be no more than ten days after the thisUpdate field; and - the value in the nextUpdate field MUST be before or equal to the notAfter date of all certificates included within the BasicOCSPResponse.certs field or, if the certs field is omitted, before or equal to the notAfter date of the CA certificate which issued the certificate that the BasicOCSPResponse is for. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation 6.3.2 – 249 The maximum validity for OV certificates should be clarified as 397 days (instead of 24 months). 9.5 - 315 References the corresponding section of the DGPC. Note that while section 9.5 of the DGPC states, “382. The FNMT-RCM holds all rights, title and interest to all intellectual and industrial property and knowledge related to this DGPC, the statements (policies and practices) specifying or completing this DGPC, the services provided and the computer programs or hardware used to provide them,” Mozilla Root Store Policy 3.3.3 provides that CPs and CPSes are made available under a Creative Commons license (or a set of equally permissive licensing terms). https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses ####**Certificate Profiles** I didn’t see a certificate profile for end entity certificates. Is there a mechanism to ensure that serial numbers are non-sequential, greater than zero (0), and contain at least 64 bits of output from a CSPRNG? I also didn’t see where you acknowledge that any CN value in the subject DN of an end entity certificate must also be in one of the SANs. Some CAs include that in the Naming section or elsewhere in their CPS, but I couldn't find it in your CPS. Also note that any certificates must contain an EKU and not the “anyEKU” EKU. Mozilla Policy section 5.2 states, “Effective for certificates with a notBefore date of July 1, 2020 or later, end-entity certificates MUST include an EKU extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.” ###**Bad** 3.2 – 49 and 50 and 3.2.2.4 – 60 Section 2.3 of the Baseline Requirements says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes **in detail** how the CA implements the latest version of these Requirements." Subsection 3 of section 2.2 of the Mozilla Root Store Policy states, “The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with.” See - https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Baseline_Requirements ("It is **not** sufficient to simply reference section 3.2.2.4 of the [CA/Brower Forum's Baseline Requirements (BR)](https://cabforum.org/baseline-requirements-documents/)") FNMT asserts that it will use the following Baseline Requirements methods: “3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact”, “3.2.2.4.4 Constructed Email to Domain Contact” or “3.2.2.4.7 DNS Change”. It is **good** that “For each method FNMT-RCM will follow a documented process and maintain records noting the method(s) used for each issuance.” While one might argue that the FNMT CPS meets the very minimum requirements of Baseline Requirements and the Mozilla Policy, the provisions are just too short and abbreviated. For instance, it is clear that FNMT will only use those 3 methods for domain validation, but most CPSes provide a little more detail for how these procedures are accomplished. Similarly, for Extended Validation, the following language is an inadequate statement of validation procedures followed by FNMT to issue Extended Validation certificates because it does not provide any specifics on how several practices are actually performed by FNMT: “In addition, the FNMT-RCM, before issuing an EV Certificate, SAN EV Certificate or Electronic Venue certificate, ensures that all information included in these types of Certificates relative to the Subscriber, is in accordance with (and is verified according to) the requirements defined by the entity CA/Browser forum in its “guide for the issuance and management of Extended Validation Certificates” and that can be consulted at the address https://cabforum.org/extended-validation/” For instance, how does FNMT determine what qualifies as a QIIS? And how can FNMT be fully and fairly audited if its CPS doesn’t contain all of the BR/EV requirements? Are its auditors fully familiar with both standards? Are detailed checklists used to ensure compliance? Are there separate and additional sets of controls and lists of controls that FNMT maintains and provides to its auditors? These and other related questions remain to be answered in the CPS or other public document. Transparency is missing without more details regarding FNMT's specific practices to demonstrate that it follows and complies with the BR and EV requirements.
Bug 1559342 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
## **FNMT Certification Practice Statements** **Documents Reviewed:** This is a review of: **Root CPS, version 5.7** (Declaración General de Prácticas de Certificación – “DGPC) https://www.sede.fnmt.gob.es/documents/10445900/10536309/dgpc_english.pdf , and **CPS for EV and OV Certificates** (Política y Prácticas de Certificación particulares de los certificados de Servidores Seguros – “DPPP”), **version 1.3**, English translation - https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf. ### **Good** **Generally** Both CPSes (DGPC and the DPPP) are formatted according to RFC 3647, as required by section 2.2 of the Baseline Requirements. There is a Document History table for the DGPC and the DPPP. This is good because it shows change management by the CA’s Policy Authority and demonstrates annual review / revision of the CPS. **Specifically** (sections refer to the DPPP unless otherwise indicated) 1.3.1 – 20 The PKI hierarchy is presented in the DGPC and there is a separate PKI hierarchy for server certificates under the “Servidores Seguros” root certificate. 1.4.2 - 23 This section of the DPPP prohibits the use of server certificates for interception of communications and man-in-the-middle attacks. 1.5.4 – 30 CPS is updated and re-versioned annually, even if no other changes are made. Mozilla Root Store Policy, section 3.3 (subsection 4), requires that the CPS be reversioned and re-dated, even if there are no changes. See https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses 3.1.1 – 42 “FNMT-RCM complies with X.500, RFC 5280 and CA/Browser Forum requirements for naming.” 3.2.2.4 - 62 “[B]efore issuing a Website authentication certificate, it is verified that the domain to be included in the Certificate is public (i.e. it is not an internal domain)” (Per section 3.2.2.5 – 63, FNMT does not issue certificates to IP addresses) 3.2.4 – 69 All information in the certificate is verified. There is no unverified information in the certificate. 4.2.1 – 86 “Reuse of previous validation data or documentation obtained from a source specified under section 3.2 may be used no more than 13 months after such data or documentation was validated.” 4.2.2 – 87 “The RA that acts in the process of issuing *Website authentication certificates* is shall always be that of the FNMT-RCM itself, and, therefore, the validation of domains will never be delegated to any other AR.” This is good because third parties are not allowed to perform domain verification. See Baseline Requirements section 1.3.2 - “With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.” 4.2.2 – 93 CAA record processing is specified, as required by section 2.2 of the Baseline Requirements. 4.3.1 – 96 “Once the application for the Certificate has been approved by the RA of the FNMT-RCM's, the system then performs pre-issuance linting to check compliance with RFC 5280 and CA/Browser Forum (BRs and EVGs). Only where no errors are found, FNMT-RCM proceeds to issue the Certificate according to the profile approved for each corresponding type of Certificate.” 4.3.1 – 98 “The processes related to the issuance of electronic Certificates guarantee that all the accounts that interact with them include multi-factor authentication.” Subsection 3 of section 2.1 of the Mozilla Root Store Policy requires that any accounts capable of certificate issuance use multi-factor authentication. 4.9.1.1 – 141 Reasons for Revoking a Subordinate CA follow those in section 4.9.1.1 of the Baseline Requirements. 4.9.2 – 145 “Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate” 4.9.5 – 152 “All revocation requests for end entity Certificates, are processed within a maximum of 24 hours of receipt.” 4.9.7 – 155 “Revocation lists (CRLs) for end-entity Certificates are issued at least every 12 hours, or whenever there is a revocation; they have a 24-hour validity period” 5.7.3 – 236 **(of the DGPC)** In the event of a key compromise, FNMT will “3) Execute the Communication Plan to notify of the events affected parties and to the browsers in whose root programs the FNMT-RCM certificates are included.” 6.1.1.3 – 226 “The Private keys for the Website authentication certificates are generated and guarded by the Subscriber of the Certificate.” Section 5.2 of the Mozilla Root Store Policy prohibits key generation for the Subscribers of server certificates. 6.1.5 – 231 FNMT only allows ECC P-384. 9.6.1 – 318 “In the event of any inconsistency between this DPPP and the aforementioned version, said requirements shall prevail over those contained in this document.” Section 2.2 of the Baseline Requirements and section 8.3 of the EV Guidelines say that the CA must include in the CPS such statements. Section 9.10.2 **of the DGPC – 428** The FNMT- RCM undertakes to subject the CPS to an annual review process. ### **Meh** 1.5.2 - 27 This section should also mention “revocation requests”. Currently it only says, “To report security issues such as suspected key compromise, certificate misuse, fraud or other matters, contact incidentes.ceres@fnmt.es” 4.9.13 – 161 CPS states, “The suspension of certificates is not covered.” Does this mean that suspension is not an option, not provided? 4.10 I couldn’t see where the validity period of an OCSP response was specified. Section 6 of Mozilla Root Store Policy provides, For end-entity certificates, if the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service: - it MUST update that service at least every four days; and - responses MUST have a defined value in the nextUpdate field, and it MUST be no more than ten days after the thisUpdate field; and - the value in the nextUpdate field MUST be before or equal to the notAfter date of all certificates included within the BasicOCSPResponse.certs field or, if the certs field is omitted, before or equal to the notAfter date of the CA certificate which issued the certificate that the BasicOCSPResponse is for. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation 6.3.2 – 249 The maximum validity for OV certificates should be clarified as 397 days (instead of 24 months). 9.5 - 315 References the corresponding section of the DGPC. Note that while section 9.5 of the DGPC states, “382. The FNMT-RCM holds all rights, title and interest to all intellectual and industrial property and knowledge related to this DGPC, the statements (policies and practices) specifying or completing this DGPC, the services provided and the computer programs or hardware used to provide them,” Mozilla Root Store Policy 3.3.3 provides that CPs and CPSes are made available under a Creative Commons license (or a set of equally permissive licensing terms). https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses #### **Certificate Profiles** I didn’t see a certificate profile for end entity certificates. Is there a mechanism to ensure that serial numbers are non-sequential, greater than zero (0), and contain at least 64 bits of output from a CSPRNG? I also didn’t see where you acknowledge that any CN value in the subject DN of an end entity certificate must also be in one of the SANs. Some CAs include that in the Naming section or elsewhere in their CPS, but I couldn't find it in your CPS. Also note that any certificates must contain an EKU and not the “anyEKU” EKU. Mozilla Policy section 5.2 states, “Effective for certificates with a notBefore date of July 1, 2020 or later, end-entity certificates MUST include an EKU extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.” ### **Bad** 3.2 – 49 and 50 and 3.2.2.4 – 60 Section 2.3 of the Baseline Requirements says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes **in detail** how the CA implements the latest version of these Requirements." Subsection 3 of section 2.2 of the Mozilla Root Store Policy states, “The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with.” See - https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Baseline_Requirements ("It is **not** sufficient to simply reference section 3.2.2.4 of the [CA/Brower Forum's Baseline Requirements (BR)](https://cabforum.org/baseline-requirements-documents/)") FNMT asserts that it will use the following Baseline Requirements methods: “3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact”, “3.2.2.4.4 Constructed Email to Domain Contact” or “3.2.2.4.7 DNS Change”. It is **good** that “For each method FNMT-RCM will follow a documented process and maintain records noting the method(s) used for each issuance.” While one might argue that the FNMT CPS meets the very minimum requirements of Baseline Requirements and the Mozilla Policy, the provisions are just too short and abbreviated. For instance, it is clear that FNMT will only use those 3 methods for domain validation, but most CPSes provide a little more detail for how these procedures are accomplished. Similarly, for Extended Validation, the following language is an inadequate statement of validation procedures followed by FNMT to issue Extended Validation certificates because it does not provide any specifics on how several practices are actually performed by FNMT: “In addition, the FNMT-RCM, before issuing an EV Certificate, SAN EV Certificate or Electronic Venue certificate, ensures that all information included in these types of Certificates relative to the Subscriber, is in accordance with (and is verified according to) the requirements defined by the entity CA/Browser forum in its “guide for the issuance and management of Extended Validation Certificates” and that can be consulted at the address https://cabforum.org/extended-validation/” For instance, how does FNMT determine what qualifies as a QIIS? And how can FNMT be fully and fairly audited if its CPS doesn’t contain all of the BR/EV requirements? Are its auditors fully familiar with both standards? Are detailed checklists used to ensure compliance? Are there separate and additional sets of controls and lists of controls that FNMT maintains and provides to its auditors? These and other related questions remain to be answered in the CPS or other public document. Transparency is missing without more details regarding FNMT's specific practices to demonstrate that it follows and complies with the BR and EV requirements.