# Firmaprofesional ## Overall Issues * From the Information Gathering document (in CCADB), there were several broken links: * [English Translated Documents v190507](https://www.firmaprofesional.com/esp/cps-eng-2) * [BR Self-Assessment](https://www.firmaprofesional.com/images/pdfs/CPS/FP_-_CAs_BR_Self_Assessment_2019-190806.xlsx) * I could not find a version, in English, for the overall Certificate Profile, although there is an equivalent version [in Spanish](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_Perfiles_Certificados-190507-ES.pdf). There are individual CPs available in English, but they do not seem to share the same content. * The 2019 Audit had several minor non-conformities (equivalent to unqualified findings), which I could not find incident reports for. These are tracked in https://bugzil.la/1606380 . The expectation is that the CA will be disclosing these issues as they become aware of them, as well as their proposed or implemented resolution, as part of [Incident Reporting Process](https://wiki.mozilla.org/CA/Responding_To_An_Incident) While there are a number of 'meh' comments here, overall I want to thank Firmaprofesional for the level of detail present in the CP, because it helps highlight and identify potential areas of concern or opportunities for improvement. These "meh" comments are meant to suggest that they're the result of, or potentially leave, ambiguity, but that they may not be outright bad or forbidden practices presently. Similarly, even when bad things are listed, they were largely only identifiable due to the transparency provided here. ## Documents Reviewed * [PKI Disclosure Statement v190220](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_PDS-190220-EN.pdf) * [CPS v190806](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-190806-EN.pdf) * [CP Website Authentication Certificates v190806](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CP_Autenticacion_Web-190806-EN.pdf) ## PKI Disclosure Statement Review Reviewed [v190220](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_PDS-190220-EN.pdf) ### Good * Section 2 is incredibly detailed about what will and will not have a QcStatement regarding QcSSCD, which made it very easy to test and confirm this was the case. Of the 904 certificates examined, this was true for all of them. ### Bad * Section 3.2 places limits on what a certificate may sign, prohibiting CSRs, CRLs, and certificates. It's unclear the intended restriction here, and how that relates to private key usage restrictions. ### Meh * Section 2.27 omits a statement about the QcSSCD despite it being in an Other Device (Compare with 2.13) * Section 4.1 allows the CA to generate keys for Subscribers. This is likely intended for the non-TLS cases, such as Centralized SSCD operated by Firmaprofessional or pre-provisioned SSCDs, but such limitations on key generation are not explicitly stated within the PDS. * Section 7.3 notes Firmaprofessional retains registration information for up to 15 years, with logs stored between 1 and 15 years. Various CAs have, in the past, mentioned challenges regarding GDPR and the necessity of retaining information for so long. This is not a Mozilla-related action item, but worth flagging for consideration/review in the event that an adverse GDPR finding may require changes to this infrastructure or impact the CA services. * The CP and the audit identify both OVCP and EVCP certificate profiles. Similarly, the CP for Website certificates notes three sub-types of website certificates: OV, EV, and Electronic Office. However, the PDS only references EV (2.15) and Electronic Office (2.23, 2.24), and makes no mention of OV certificates. ## Certificate Policy Reviewed [v190806](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CP_Autenticacion_Web-190806-EN.pdf) ### Good * 2.1 makes it clear that TLS certificates are only issued by a particular sub-CA. This approach to clearly separating out the potential issuance policies is a good overall design, particularly if/when accompanied by technical controls to ensure that is the case, such as limiting extendedKeyUsages. ### Bad * 3.5.3 documents the problem reporting address (as does 4.4). Baseline Requirements, v1.6.7, Section 4.9.3, requires this be documented in section 1.5.2 of the CPS, which it is not. See the CPS review for more discussion. * 4.1.2.2.2(5) describes a validation method that is equivalent to "any other method" - i.e. it is not permitted by 3.2.2.4 or 3.2.2.5 after the adoption of SC7 * 4.1.2.3.1 mentions the use of "Reliable Data Source" for measuring operational existence for EV certificates, but that does not seem to align with EV Guidelines, v1.7.1, Section 11.6, which requires the use of a Qualified Indepedent Information Source. The inclusion of D&B, which is not even reliable, which is a lower bar than QIIS, suggests a revamp of these procedures may be needed. * 4.1.5 lists the CAA domain name used ("firmaprofesional.com"), except that BRs v1.6.7, Section 2.2 requires that this be listed in Section 4.2 of the CP/CPS. No mention of CAA is made in the CPS, so this is listed as an issue here. ### Meh * 1.1 states that Firmaprofessional "issues three types of Website Authentication Certificates", but then lists four types: Electronic Office, EV, OV, and PSD2. This is not a big deal, and may simply require updating to "issues _four_ types". * 2.1 of the CP clearly states that all Website authentication certificates come from a single sub-CA, which is great. However, the audit report provided does not clearly support this CP statement, as shown through certificates like https://crt.sh/?id=1038824329 , which are capable of TLS but not included in the scope of the audit. This is already flagged as a failed ALV finding. Tracking this in https://bugzil.la/1606380 * 3.4 explicitly states Firmaprofesional does not issue IDN certificates. There's nothing requiring that they do, but I wanted to draw attention to this from a Mozilla Policy perspective, given that Mozilla intentionally supports IDN and previously heavily promoted them under Principle 2 of the Mozilla Manifesto. * 4.1.1.3 is unclear the process of obtaining an EV certificate, perhaps due to translation issues. Specifically, the following statement is unclear: "For the application process of Firmaprofesional SSL EV certificates it is necessary to use at least two of these profiles." * 4.1.2.1 makes it clear that EV validation may be delegated to third parties. Given the myriad issues given around EV validation, this does raise a concern, both about the process/validation procedures as well as the general application of the Network Security Requirements. Conversely, given the limited scope of Firmaprofesional's EV issuance, and the degree to which government agencies are vetted, this may offer a more robust, more localized approach. It's unclear, but this is something I think would be worth focusing on if Firmaprofesional had misissuances for EV certificates. * 4.1.2.2.1(a) states that "A certificate issued by an official register 825 days before the issuance of the certificate is also accepted." It's unclear what 'certificate' refers to, whether it's X.509v3 or a physical copy. The selection of 825 days suggests it's related to the limits on the reuse of validation information, and so this seems to suggest it may be a digital certificate. I think a longer explanation of this validation process would be useful. * 4.1.2.2.2(b) is good, in that it lists potential reliable data sources, but is unfortunate, because past evidence suggests that D&B is not actually a reliable data source. While the focus is presently on EV certificates, contributing to the CA Browser Forum's Validation WG's effort on [identifying and disclosing data sources](https://cabforum.org/pipermail/validation/2019-December/001384.html) would be useful. * 4.1.2.3.1 mentions "non-commercial entities", but does not mention how it validates that multiple countries recognize the institution * 4.1.2.3.1 mentions registered brands, but does not indicate that the use of branding or trademarks is limited in the fields that this information can appear in. * 4.1.2.3.7 (and elsewhere) describe a process in which an Applicant may send an email from an a priori authorized e-mail address, and that constitutes proof of authorization. It's unclear that this meets the requirements set forth in the EV Guidelines regarding a "Verified Method of Communication" in 11.5. This is "meh" because it may be an issue in the EVGs, but the risk here is e-mail spoofing on behalf of an attacker. In theory, it should be possible to mitigate this by having the CA send the e-mail to the determined e-mail address, and requiring some interaction (e.g. clicking a link). This remains "secure" (ish) even if the recipient domain has not set up DKIM/DMARC or the CA has not implemented it, as a way of preventing spoofing. * 4.1.5 has some translation issues regarding "CAA register" ## Certification Practice Statement Reviewed [v190806](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-190806-EN.pdf) ### Good * 1.2.2 extensively documenting the format and allocation of the OIDs was extremely helpful for reviewing and examining present and past practices. * 1.3.2 makes it explicitly clear that Firmaprofesional does not allow externally-operated sub-CAs * 2.4 is the first time I've seen a CA explicitly state that they publicize (non-CA) certificates in public repositories. * 3.2.5 explicitly lists the sources of information used for WHOIS validation, and does not rely on third-party WHOIS data aggregators. * 9.3.2 explicitly states that certificates are public, as does 9.4.3. ### Bad * 1.3.3 allows the use of Delegated Third Parties for certain functions (RA Operator), beyond the provisions of an "Enterprise RA" defined in the BRs. Further, these RA Operators are allowed to further delegate CA functions to other third-parties. This should definitely cause concern for any validation other than domain names, which are not permitted to be delegated, although no statement of non-delegation is present. I debated making this a "meh", but I think the risk is great enough that it should be 'bad' unless it can be clearly clarified in the CP/CPS. This is further compounded by 3.2.4, which seems to suggest that RA operators may only be Enterprise RAs, so it's difficult to have a clear picture on everything going on here. * 1.4.1 and 3.4 document the problem reporting address, but this address is not present in Section 1.5.2, as required by the BRs v1.6.7, Section 4.9.3. * 3.1.2 explicitly mentions "TEST" and "INVALID" certificates in the context of subject fields as not having legal validity, which is questionable * 3.1.6 disclaims Firmaprofesional's responsibilities with respect to trademarks, but the CP documents the extensive process for validating trademarks. It stands out, particularly with the CA disclaiming liability, as the CA is obligated by the BRs to do certain due diligence. * 3.2.6 starts off positively, by suggesting that the only way for an e-mail address to appear are if the applicant requests it and the CA verifies it, or if the CA determines to include it itself. However, the downside with the CA-determined approach is that it relies on third-party databases to determine whether to include the e-mail address, creating possible issues if one of these databases lists an e-mail address that they are not the domain holder for / that the e-mail subscriber did not approve. That is, if a database said "Joe Example" had an e-mail address belonging to me, it's possible that Joe Example might get a certificate issued that I did not approve or authorize. Mozilla [Root Store Policy 2.7](https://github.com/mozilla/pkipolicy/commit/171d8565f103e8fc803217e324cac3d672e93328) expects that the CA validates at least the domain part for all e-mail addresses included. * 4.9.1 appears to be missing the following from 4.9.1 of the BRs: * For 4.9.1.1, for 24 hours, (2) & (4) * For 4.9.1.1, for 5 days, (1), (4), (5), (7), (8), (9) That said, it may be that these are intended to be accounted for, but it's unclear, because the BR self-evaluation/mapping isn't available right now. For example, 4.9.3.3 accounts for the missing parts of 4.9.1.1's 24 hour requirements * 7.1.2 notes that an rfc822name SAN may be used, but this is not permitted by the BRs. While noted as optional in the base policy, the lack of an explicit profile in English makes it difficult to confirm that this is compliant. This also applies to 7.1.4's use of the emailAddress Subject DN field. ### Meh * Version History: While not wanting to call out CAs for identify issues and proactively fixing them, it's slightly concerning that a statement of adherance to the latest version of the CA/Browser Forum documents was not added until the most recent version of the CPS, as discussed in the changelog, despite this being required in Section 2.1 of the BRs since the introduction and adoption of the BRs. * 1.3.2.1 leaves it ambiguous whether or not Firmaprofesional issues intermediate certificates via SHA-1. While the lack of an externally operated sub-CA should be a mitigating factor, the use of SHA-1 by sub-CAs should still be concerning. This would be easily fixed if the statement was "only issues certificates in SHA256" (notwithstanding the ambiguity of hash algorithms in signatures). It's specifically the presence of "end entity" that raises an eyebrow. * 1.5.3 states that documents are reviewed and, "if appropriate", updated annually. Mozilla Policy expects explicit updates to confirm that the policy has been reviewed annually. * 2.2.1 has a slight translation issue: "both" the CPS, CP, and PDS - three items, not two * 3.1.4 mentions compliance with X.500, but it would be useful to also mention RFC 5280 and the Baseline Requirements * 3.2.5 suggests that only WHOIS is used for domain validation, but the CP lists other forms of validating. * 6.1.5 acknowledges there are still 1024-bit operator/administrator keys in use * 7.2.2.2 includes an untranslated portion "Entries de la CRL"
Bug 1102143 Comment 25 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
# Firmaprofesional ## Overall Issues * From the Information Gathering document (in CCADB), there were several broken links: * [English Translated Documents v190507](https://www.firmaprofesional.com/esp/cps-eng-2) * [BR Self-Assessment](https://www.firmaprofesional.com/images/pdfs/CPS/FP_-_CAs_BR_Self_Assessment_2019-190806.xlsx) * I could not find a version, in English, for the overall Certificate Profile, although there is an equivalent version [in Spanish](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_Perfiles_Certificados-190507-ES.pdf). There are individual CPs available in English, but they do not seem to share the same content. * The 2019 Audit had several minor non-conformities (equivalent to unqualified findings), which I could not find incident reports for. These are tracked in Bug 1606380 . The expectation is that the CA will be disclosing these issues as they become aware of them, as well as their proposed or implemented resolution, as part of [Incident Reporting Process](https://wiki.mozilla.org/CA/Responding_To_An_Incident) While there are a number of 'meh' comments here, overall I want to thank Firmaprofesional for the level of detail present in the CP, because it helps highlight and identify potential areas of concern or opportunities for improvement. These "meh" comments are meant to suggest that they're the result of, or potentially leave, ambiguity, but that they may not be outright bad or forbidden practices presently. Similarly, even when bad things are listed, they were largely only identifiable due to the transparency provided here. ## Documents Reviewed * [PKI Disclosure Statement v190220](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_PDS-190220-EN.pdf) * [CPS v190806](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-190806-EN.pdf) * [CP Website Authentication Certificates v190806](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CP_Autenticacion_Web-190806-EN.pdf) ## PKI Disclosure Statement Review Reviewed [v190220](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_PDS-190220-EN.pdf) ### Good * Section 2 is incredibly detailed about what will and will not have a QcStatement regarding QcSSCD, which made it very easy to test and confirm this was the case. Of the 904 certificates examined, this was true for all of them. ### Bad * Section 3.2 places limits on what a certificate may sign, prohibiting CSRs, CRLs, and certificates. It's unclear the intended restriction here, and how that relates to private key usage restrictions. ### Meh * Section 2.27 omits a statement about the QcSSCD despite it being in an Other Device (Compare with 2.13) * Section 4.1 allows the CA to generate keys for Subscribers. This is likely intended for the non-TLS cases, such as Centralized SSCD operated by Firmaprofessional or pre-provisioned SSCDs, but such limitations on key generation are not explicitly stated within the PDS. * Section 7.3 notes Firmaprofessional retains registration information for up to 15 years, with logs stored between 1 and 15 years. Various CAs have, in the past, mentioned challenges regarding GDPR and the necessity of retaining information for so long. This is not a Mozilla-related action item, but worth flagging for consideration/review in the event that an adverse GDPR finding may require changes to this infrastructure or impact the CA services. * The CP and the audit identify both OVCP and EVCP certificate profiles. Similarly, the CP for Website certificates notes three sub-types of website certificates: OV, EV, and Electronic Office. However, the PDS only references EV (2.15) and Electronic Office (2.23, 2.24), and makes no mention of OV certificates. ## Certificate Policy Reviewed [v190806](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CP_Autenticacion_Web-190806-EN.pdf) ### Good * 2.1 makes it clear that TLS certificates are only issued by a particular sub-CA. This approach to clearly separating out the potential issuance policies is a good overall design, particularly if/when accompanied by technical controls to ensure that is the case, such as limiting extendedKeyUsages. ### Bad * 3.5.3 documents the problem reporting address (as does 4.4). Baseline Requirements, v1.6.7, Section 4.9.3, requires this be documented in section 1.5.2 of the CPS, which it is not. See the CPS review for more discussion. * 4.1.2.2.2(5) describes a validation method that is equivalent to "any other method" - i.e. it is not permitted by 3.2.2.4 or 3.2.2.5 after the adoption of SC7 * 4.1.2.3.1 mentions the use of "Reliable Data Source" for measuring operational existence for EV certificates, but that does not seem to align with EV Guidelines, v1.7.1, Section 11.6, which requires the use of a Qualified Indepedent Information Source. The inclusion of D&B, which is not even reliable, which is a lower bar than QIIS, suggests a revamp of these procedures may be needed. * 4.1.5 lists the CAA domain name used ("firmaprofesional.com"), except that BRs v1.6.7, Section 2.2 requires that this be listed in Section 4.2 of the CP/CPS. No mention of CAA is made in the CPS, so this is listed as an issue here. ### Meh * 1.1 states that Firmaprofessional "issues three types of Website Authentication Certificates", but then lists four types: Electronic Office, EV, OV, and PSD2. This is not a big deal, and may simply require updating to "issues _four_ types". * 2.1 of the CP clearly states that all Website authentication certificates come from a single sub-CA, which is great. However, the audit report provided does not clearly support this CP statement, as shown through certificates like https://crt.sh/?id=1038824329 , which are capable of TLS but not included in the scope of the audit. This is already flagged as a failed ALV finding. Tracking this in https://bugzil.la/1606380 * 3.4 explicitly states Firmaprofesional does not issue IDN certificates. There's nothing requiring that they do, but I wanted to draw attention to this from a Mozilla Policy perspective, given that Mozilla intentionally supports IDN and previously heavily promoted them under Principle 2 of the Mozilla Manifesto. * 4.1.1.3 is unclear the process of obtaining an EV certificate, perhaps due to translation issues. Specifically, the following statement is unclear: "For the application process of Firmaprofesional SSL EV certificates it is necessary to use at least two of these profiles." * 4.1.2.1 makes it clear that EV validation may be delegated to third parties. Given the myriad issues given around EV validation, this does raise a concern, both about the process/validation procedures as well as the general application of the Network Security Requirements. Conversely, given the limited scope of Firmaprofesional's EV issuance, and the degree to which government agencies are vetted, this may offer a more robust, more localized approach. It's unclear, but this is something I think would be worth focusing on if Firmaprofesional had misissuances for EV certificates. * 4.1.2.2.1(a) states that "A certificate issued by an official register 825 days before the issuance of the certificate is also accepted." It's unclear what 'certificate' refers to, whether it's X.509v3 or a physical copy. The selection of 825 days suggests it's related to the limits on the reuse of validation information, and so this seems to suggest it may be a digital certificate. I think a longer explanation of this validation process would be useful. * 4.1.2.2.2(b) is good, in that it lists potential reliable data sources, but is unfortunate, because past evidence suggests that D&B is not actually a reliable data source. While the focus is presently on EV certificates, contributing to the CA Browser Forum's Validation WG's effort on [identifying and disclosing data sources](https://cabforum.org/pipermail/validation/2019-December/001384.html) would be useful. * 4.1.2.3.1 mentions "non-commercial entities", but does not mention how it validates that multiple countries recognize the institution * 4.1.2.3.1 mentions registered brands, but does not indicate that the use of branding or trademarks is limited in the fields that this information can appear in. * 4.1.2.3.7 (and elsewhere) describe a process in which an Applicant may send an email from an a priori authorized e-mail address, and that constitutes proof of authorization. It's unclear that this meets the requirements set forth in the EV Guidelines regarding a "Verified Method of Communication" in 11.5. This is "meh" because it may be an issue in the EVGs, but the risk here is e-mail spoofing on behalf of an attacker. In theory, it should be possible to mitigate this by having the CA send the e-mail to the determined e-mail address, and requiring some interaction (e.g. clicking a link). This remains "secure" (ish) even if the recipient domain has not set up DKIM/DMARC or the CA has not implemented it, as a way of preventing spoofing. * 4.1.5 has some translation issues regarding "CAA register" ## Certification Practice Statement Reviewed [v190806](https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-190806-EN.pdf) ### Good * 1.2.2 extensively documenting the format and allocation of the OIDs was extremely helpful for reviewing and examining present and past practices. * 1.3.2 makes it explicitly clear that Firmaprofesional does not allow externally-operated sub-CAs * 2.4 is the first time I've seen a CA explicitly state that they publicize (non-CA) certificates in public repositories. * 3.2.5 explicitly lists the sources of information used for WHOIS validation, and does not rely on third-party WHOIS data aggregators. * 9.3.2 explicitly states that certificates are public, as does 9.4.3. ### Bad * 1.3.3 allows the use of Delegated Third Parties for certain functions (RA Operator), beyond the provisions of an "Enterprise RA" defined in the BRs. Further, these RA Operators are allowed to further delegate CA functions to other third-parties. This should definitely cause concern for any validation other than domain names, which are not permitted to be delegated, although no statement of non-delegation is present. I debated making this a "meh", but I think the risk is great enough that it should be 'bad' unless it can be clearly clarified in the CP/CPS. This is further compounded by 3.2.4, which seems to suggest that RA operators may only be Enterprise RAs, so it's difficult to have a clear picture on everything going on here. * 1.4.1 and 3.4 document the problem reporting address, but this address is not present in Section 1.5.2, as required by the BRs v1.6.7, Section 4.9.3. * 3.1.2 explicitly mentions "TEST" and "INVALID" certificates in the context of subject fields as not having legal validity, which is questionable * 3.1.6 disclaims Firmaprofesional's responsibilities with respect to trademarks, but the CP documents the extensive process for validating trademarks. It stands out, particularly with the CA disclaiming liability, as the CA is obligated by the BRs to do certain due diligence. * 3.2.6 starts off positively, by suggesting that the only way for an e-mail address to appear are if the applicant requests it and the CA verifies it, or if the CA determines to include it itself. However, the downside with the CA-determined approach is that it relies on third-party databases to determine whether to include the e-mail address, creating possible issues if one of these databases lists an e-mail address that they are not the domain holder for / that the e-mail subscriber did not approve. That is, if a database said "Joe Example" had an e-mail address belonging to me, it's possible that Joe Example might get a certificate issued that I did not approve or authorize. Mozilla [Root Store Policy 2.7](https://github.com/mozilla/pkipolicy/commit/171d8565f103e8fc803217e324cac3d672e93328) expects that the CA validates at least the domain part for all e-mail addresses included. * 4.9.1 appears to be missing the following from 4.9.1 of the BRs: * For 4.9.1.1, for 24 hours, (2) & (4) * For 4.9.1.1, for 5 days, (1), (4), (5), (7), (8), (9) That said, it may be that these are intended to be accounted for, but it's unclear, because the BR self-evaluation/mapping isn't available right now. For example, 4.9.3.3 accounts for the missing parts of 4.9.1.1's 24 hour requirements * 7.1.2 notes that an rfc822name SAN may be used, but this is not permitted by the BRs. While noted as optional in the base policy, the lack of an explicit profile in English makes it difficult to confirm that this is compliant. This also applies to 7.1.4's use of the emailAddress Subject DN field. ### Meh * Version History: While not wanting to call out CAs for identify issues and proactively fixing them, it's slightly concerning that a statement of adherance to the latest version of the CA/Browser Forum documents was not added until the most recent version of the CPS, as discussed in the changelog, despite this being required in Section 2.1 of the BRs since the introduction and adoption of the BRs. * 1.3.2.1 leaves it ambiguous whether or not Firmaprofesional issues intermediate certificates via SHA-1. While the lack of an externally operated sub-CA should be a mitigating factor, the use of SHA-1 by sub-CAs should still be concerning. This would be easily fixed if the statement was "only issues certificates in SHA256" (notwithstanding the ambiguity of hash algorithms in signatures). It's specifically the presence of "end entity" that raises an eyebrow. * 1.5.3 states that documents are reviewed and, "if appropriate", updated annually. Mozilla Policy expects explicit updates to confirm that the policy has been reviewed annually. * 2.2.1 has a slight translation issue: "both" the CPS, CP, and PDS - three items, not two * 3.1.4 mentions compliance with X.500, but it would be useful to also mention RFC 5280 and the Baseline Requirements * 3.2.5 suggests that only WHOIS is used for domain validation, but the CP lists other forms of validating. * 6.1.5 acknowledges there are still 1024-bit operator/administrator keys in use * 7.2.2.2 includes an untranslated portion "Entries de la CRL"