Add Renewed Autoridad de Certificacion Firmaprofesional root certificate
Categories
(CA Program :: CA Certificate Root Program, task, P1)
Tracking
(Not tracked)
People
(Reporter: me, Assigned: bwilson)
References
Details
(Whiteboard: [ca-approved] - In NSS 3.74, FF 97; EV enabled in FF 97)
Attachments
(8 files, 1 obsolete file)
|
||
Comment 1•11 years ago
|
||
|
|
||
Updated•11 years ago
|
|
Reporter | |
Comment 2•11 years ago
|
||
|
|
Reporter | |
Comment 3•11 years ago
|
||
|
|
||
Comment 4•11 years ago
|
||
|
|
Reporter | |
Comment 5•10 years ago
|
||
|
|
Reporter | |
Comment 6•10 years ago
|
||
|
|
||
Comment 7•10 years ago
|
||
|
||
Updated•9 years ago
|
|
|
||
Updated•8 years ago
|
|
|
||
Comment 10•8 years ago
|
||
|
||
Updated•8 years ago
|
|
||
Comment 11•8 years ago
|
||
|
||
Comment 12•7 years ago
|
||
|
|
||
Comment 13•7 years ago
|
||
|
|
||
Updated•7 years ago
|
|
|
||
Comment 14•7 years ago
|
||
|
|
||
Comment 15•7 years ago
|
||
|
|
||
Comment 16•7 years ago
|
||
|
|
||
Comment 17•6 years ago
|
||
|
|
||
Comment 18•6 years ago
|
||
(In reply to Kathleen Wilson from comment #15)
The link below shows the CA information that has been verified. Search in
the page for the word "NEED" to see where further clarification is requested.https://ccadb-public.secure.force.com/mozilla/
PrintViewForCase?CaseNumber=00000053In particular:
- Per
https://wiki.mozilla.org/CA/
Required_or_Recommended_Practices#CAA_Domains_listed_in_CP.2FCPS
CPS "shall clearly specify the set of Issuer Domain Names that the CA
recognises in CAA "issue" or "issuewild" records as permitting it to issue."
We issued a new version of the SSL CP with more clear statements on CAA records last December and a new version last January.
Find the public version here: https://www.firmaprofesional.com/esp/cps-eng-2
And the specific SSL CP: https://www.firmaprofesional.com/images/pdfs/CPS/FP_CP_Autenticacion_Web-190121-EN.pdf
You can find information on CAA records in section 4.1.5. Certificate issuance.
- Explain/resolve all lint test errors:
https://crt.sh/?caid=430&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01
Find Bug_1102143_answers-190301.pdf report attached (https://bugzilla.mozilla.org/attachment.cgi?id=9047670).
https://crt.sh/?caid=994&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01
Still working on it.
|
|
||
Comment 19•6 years ago
|
||
(In reply to chemalogo from comment #18)
I have update the root inclusion case in the CCADB to reflect the new CP/CPS, etc.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000053
Please double-check the data.
https://crt.sh/?caid=994&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01
Still working on it.
OK. Please update this bug when response is ready.
|
|
||
Comment 20•6 years ago
|
||
|
|
||
Comment 21•6 years ago
|
||
Find attached the final report with answers for all the arisen issues ("Answers to arisen issues" - Bug_1102143_answers-190423.pdf).
|
|
||
Comment 22•6 years ago
|
||
The information for this root inclusion request is available at the following URL.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000053
This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.
There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review
It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21
|
|
||
Comment 23•6 years ago
|
||
In case it is beneficial for accelerating the course of this issue, please find attached the url of Firmaprofesional's BR Self Assessment corresponding to 2019:
https://www.firmaprofesional.com/images/pdfs/CPS/FP_-_CAs_BR_Self_Assessment_2019-190806.xlsx
|
||
Updated•6 years ago
|
|
|
||
Comment 24•6 years ago
|
||
|
|
||
Updated•6 years ago
|
|
|
||
Comment 25•6 years ago
•
|
||
Firmaprofesional
Overall Issues
- From the Information Gathering document (in CCADB), there were several broken links:
- I could not find a version, in English, for the overall Certificate Profile, although there is an equivalent version in Spanish. 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
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 Review
Reviewed v190220
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
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 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
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 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"
|
||
Comment 26•6 years ago
|
||
Chema: would you like to make changes to the CP and CPS to address the issued identified in comment #25 before I begin a public discussion on this request? I recommend that you do so.
|
|
||
Comment 27•6 years ago
|
||
Thanks, Wayne. I'm on vacation until tomorrow and then we will begin to examine thoroughly comment #25 and also bug https://bugzilla.mozilla.org/show_bug.cgi?id=1606380.
|
|
||
Updated•6 years ago
|
|
|
||
Comment 28•6 years ago
|
||
We've fixed documentation with all Bad and almost all Meh's recommendation and we are now translating it.
it is taking longer than expected because we are also reviewing the documentation is align with Mozilla policy 2.7.
|
|
||
Comment 29•6 years ago
|
||
Here you can find the updated documentation, in English. We will update also CCADB:
- CPS: https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-200205-EN-sFP.pdf
- CP website authentication certificates: https://www.firmaprofesional.com/wp-content/uploads/pdfs/200205-FP_CP_Autenticacion_Web-200205-EN-sFP.pdf
- PKI Disclosure statement: https://www.firmaprofesional.com/wp-content/uploads/pdfs/200123-FP_PDS-200123-EN-sFP.pdf
- Certificate profiles: https://www.firmaprofesional.com/wp-content/uploads/pdfs/200205-FP_Perfiles_Certificados-200205-EN-sFP.pdf
For the previous documents we recommend going to the following URL, since the aforementioned URLs are version dependent: https://www.firmaprofesional.com/cps
- BR self-assessment: https://www.firmaprofesional.com/images/pdfs/CPS/FP_-_CAs_BR_Self_Assessment_2019-190806.xlsx
Please, Wayne, you can begin the public discussion. Thanks.
|
|
||
Comment 30•6 years ago
|
||
For the record, I've tried both to update CPS/CP data on CCADB:
- for Case 00000053 Add Renewed Autoridad de Certificacion Firmaprofesional root certificate
- for the Root CA
and the answer is "You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary."
|
|
||
Updated•6 years ago
|
|
|
||
Comment 32•6 years ago
|
||
(In reply to chemalogo from comment #29)
Here you can find the updated documentation, in English. We will update also CCADB:
I have updated the CCADB with the new CP/CPS URLs.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000053
|
||
Comment 33•5 years ago
|
||
This is in response to Ryan's Comment #25 above. I have reviewed the updated versions of the PDS, CP, and CPS, as mentioned above, and I have the following comments/observations about how/whether his comments have been addressed.
Firmaprofesional
Overall Issues
. . .
It would be good if all requirements could be met/demonstrated in a single document (preferably in the CPS) – not with some requirements stated in the CP and others in the CPS. It is difficult to search back and forth through multiple documents to determine whether a CA has complied with all of the requirements. In a related way, this may be due to the fact that the CP does not follow the RFC 3647 framework. This is especially true when the Baseline Requirements state that a certain provision must appear in a certain section of the CP/CPS.
Documents Reviewed
- PDS v. 200123 (https://www.firmaprofesional.com/wp-content/uploads/pdfs/200123-FP_PDS-200123-EN-sFP.pdf)
- CP v. 200205 (https://www.firmaprofesional.com/wp-content/uploads/pdfs/200205-FP_CP_Autenticacion_Web-200205-EN-sFP.pdf )
PKI Disclosure Statement Review
Reviewed v190220
- Reviewed PDS v. 200123 (https://www.firmaprofesional.com/wp-content/uploads/pdfs/200123-FP_PDS-200123-EN-sFP.pdf)
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.
The comment and its resolution aren't clear.
Certificate Policy
Reviewed v190806
Reviewed CP v. 200205 (https://www.firmaprofesional.com/wp-content/uploads/pdfs/200205-FP_CP_Autenticacion_Web-200205-EN-sFP.pdf )
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.
Fixed – although CAs need to be more clear about the use of the address for revocation - the CPS says, ““Complaints, suggestions and communication of unauthorized uses of certificates” but not revocation, key compromise, etc. (Also see general comments above.)
- 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
Fixed - replaced/removed
- 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.
Fixed - replaced/removed
- 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.
This is still in section 4.1.5 of the CP (see general comment re: RFC 3647) and in section 3.2.2 of the CPS, not in section 4.2 as required by the BRs.
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".
Fixed.
- 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
See comments/responses re: ALV processing, (above in this bug).
- 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.
Still prohibited, but not a compliance issue.
- 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."
For the application process of Firmaprofesional SSL EV certificates it is necessary to use at least two of the persons mentioned in section 2.3.1.
- 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.
Section 4.1.2.1 is about “Electronic Office” certificates, not EV, which is discussed in section 4.1.2.3 of the CP.
- 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.
Agreed - using the word "certificate" to mean two different things is confusing. It now says, "signed document" in this subsection - Consultation with official register depending on the type of the organisation. For example, for companies, the consultation will be with the trade register. In cases of public entities, the consultation will be with a public entities register. A signed document issued by an official register 825 days before the issuance of the certificate is also accepted." But the language for verifying a registered brand or commercial name still uses the word "certificate".
- 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 would be useful.
I don’t see that numbering or language in the version I’m looking at, so it must have been fixed.
- 4.1.2.3.1 mentions "non-commercial entities", but does not mention how it validates that multiple countries recognize the institution
This entry in the table doesn't appear to have been changed to discuss verification of recognition by multiple countries.
- 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.
The following language has been added to this entry in the table: "Its use is limited to fields where this information may appear"
- 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.
This section remains unchanged.
- 4.1.5 has some translation issues regarding "CAA register"
This issue still exists. (“Registro” in Spanish is ambiguous – it can mean "registry" OR " record", and in these places, it probably should have been translated to “CAA record”)
Certification Practice Statement
Reviewed v190806
Reviewed CPS v. 200205 (https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-200205-EN-sFP.pdf)
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.
Not fixed
- 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.
Added to section 1.5.2 “Complaints, suggestions and communication of unauthorized uses of certificates” with email address of soporte@firmaprofesional.com
- 3.1.2 explicitly mentions "TEST" and "INVALID" certificates in the context of subject fields as not having legal validity, which is questionable
Removed “In the case that the information recorded in the DN are fictitious or explicitly indicate their invalidity (eg. "TEST" or "INVALID") the certificate will be considered without legal validity, and valid only to carry out technical tests for interoperability.”
- 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.
Language has been replaced with, “If an applicant claims to be entitled to a trademark that they wish to incorporate in a certificate, the CA will seek evidence of the possession of the right to the trademark requested before the issuance of the certificates, through consultation with official records or documents issued by them.”
- 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 expects that the CA validates at least the domain part for all e-mail addresses included.
Last part of section 3.2.6 now reads,
“In cases where the signatory has no connection with the RA, verification of the email address is carried out by challenge and response to the requested address.
In any case, Firmaprofesional will validate the domain part for all email addresses included in the web authentication certificates.”
- 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
Not fixed.
- 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.
Footnote No. 5 has been added “Not allowed in website authentication certificates”
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.
Section 1.3.2.2 discusses Subordinate CAs and remains unchanged.
- 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.
This section now states, “The CPS, CPs and PDSs will be reviewed and updated annually.”
- 2.2.1 has a slight translation issue: "both" the CPS, CP, and PDS - three items, not two
Fixed
- 3.1.4 mentions compliance with X.500, but it would be useful to also mention RFC 5280 and the Baseline Requirements
Fixed
- 3.2.5 suggests that only WHOIS is used for domain validation, but the CP lists other forms of validating.
A third bullet has been added “Those that are included in the Certification Policy documents of web authentication certificates.”
- 6.1.5 acknowledges there are still 1024-bit operator/administrator keys in use
Fixed
- 7.2.2.2 includes an untranslated portion "Entries de la CRL"
Fixed
|
|
||
Comment 34•5 years ago
|
||
Thanks, Ben, for your comments.
We will work on them in the following weeks.
Nowadays we are facing new challenges due to COVID-19, here in Spain, with National requirements on the issuance of Qualified (according to eIDAS) Certificates for Natural Person.
|
|
||
Updated•5 years ago
|
|
|
||
Comment 35•5 years ago
|
||
In the mean time, find linked 2020's BR self-assessment: https://www.firmaprofesional.com/wp-content/uploads/pdfs/Firmaprofesional_BR_Self_Assessment-200406-EN.pdf
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 36•5 years ago
|
||
Newer CPS published/effective 1-Oct-2020 (https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-201001-EN-sFP.pdf) needs to be reviewed.
|
|
Assignee | |
Updated•4 years ago
|
|
|
||
Comment 37•4 years ago
|
||
There have been recent updates also for CPS and for CP, that, in our opinion address all the remaining issues.
Find them at:
- CPS: https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-210322-EN-sFP.pdf
- CP: https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CP_Autenticacion_Web-210322-EN-sFP.pdf
The most recent version is always available at: https://www.firmaprofesional.com/certification-policies-and-practices/
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 38•4 years ago
|
||
CP/CPS Review of Firmaprofesional
General Documentation CPS and
Certification Policy for Website Authentication Certificates
v. 210322 (published March 22, 2021)
https://www.firmaprofesional.com/certification-policies-and-practices/
BASELINE REQUIREMENTS AND MOZILLA ROOT STORE POLICY REVIEW
CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)
OK – CPS follows RFC 3647 without blank sections. However, some of the titles of the sections don’t match the English version of RFC 3647. For instance, in the CP the title to section 3.1 is “Appoint” rather than “Naming”, and in section 5.6 of the CP, the title is “CA Password change” whereas in RFC 3647 the title is “Key changeover”.
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”
Adequate – Section 9.5 of the CP states, “As stated in the current Certification Practices Statement of Firmaprofesional.” The CPS states, “The intellectual property of this CPS and the various CPs belongs to Firmaprofesional, SA.” Nothing appears to contradict the license required by Mozilla, but a more permissive license for the use of the CP/CPS would be better.
Statement of adherence to BRs/EVGs and their precedence (MRSP § 2.3) (BR § 2.2 / EVG 8.3)
“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”
Section 8.3 of the EV Guidelines contains a similar provision – “In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.”
Should be fixed – Section 9.14 of the CPS states, “The current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document. Guidelines For The Issuance And Management Of Extended Validation Certificates, published at http://www.cabforum.org by the CA / Browser Forum.” This last sentence should be followed by “In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.”
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)
Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.
OK – This prohibition should be called out in the CP or CPS. However, the CA “AC Firmaprofesional – INFRAESTRUCTURA” had the serverAuth EKU and codeSigning EKU and was revoked on 11/11/2020, and the AC Firmaprofesional - Secure Web 2020 and AC Firmaprofesional - Secure Web 2021 only have the serverAuth and clientAuth EKUs.
Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)
“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”
Good – The CAs are called out in section 1.3.1 of the CPS.
Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)
“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.
Good – Section 1.5.3 of the CPS states, “The CPS, CPs and PDSs will be reviewed and updated annually.”
Statement of Non-Delegation for Domain Validation (BR § 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.”
Should be fixed – Section 3.2.2.1 of the CP states, “Firmaprofesional verifies, before issuing the SSL certificate, that the applicant has control over the domain for which the certificate is requested”, but it does not expressly prohibit the delegation of domain validation to third parties.
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)
“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”
Should be fixed – Section 1.5.2 of the CPS specifies “soporte@firmaprofesional.com” for “Complaints, suggestions and communication of unauthorized uses of certificates.” It should alert readers of where they can report “suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.”
Naming compliant with X.500, RFC5280, Baseline Requirements and EV Guidelines
The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.
Needs to be fixed – Sections 3.1.1, 7.1.1., and 7.1.4 of the CPS discuss naming compliant with X.500 and RFC 5280. CPS section 3.1.4 says, “In all cases Firmaprofesional follows the rules set out in the reference standard X.500 in ISO/IEC 9594, as well as by RFC 5280 and by the CA / Browser-Forum Baseline Requirements.” However, the CP does not describe how naming is consistent with the CA/Browser Forum’s EV Guidelines.
No internal names or reserved IP addresses (BR § 7.1.4.2.1)
“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”
Good - Section 1.4.1.4 of the CP states “Issuance of certificates for IP addresses or internal Domain Names (private or reserved) is not allowed.”
ALL certificates must meet Mozilla/BR validation requirements
CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)
CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.
[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used by a man-in-the-middle to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]
Needs to be fixed – Section 3.2.2.1 of the CPS says that domain validation uses “Those that are included in the Certification Policy documents of web authentication certificates.” Section 3.2.2.1 of the CP states that Firmaprofesional uses BR methods 3.2.2.4.2, 3.2.2.4.3, 3.2.2.4.4 and 3.2.2.4.7. Section 3.2.2.4.3 of the Baseline Requirements states, “CAs SHALL NOT perform validations using this method after May 31, 2019.” Instead, Firmaprofesional should refer to BR section 3.2.2.4.15.
CA validates domain part of all e-mail addresses (MRSP § 2.2.2)
“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”
Needs to be fixed – Section 3.2.2.2 of the CPS states, "In any case, Firmaprofesional will validate the domain part for all email addresses included in the web authentication certificates.” It should say “email certificates” or “SMIME certificates” as in “In any case, Firmaprofesional will validate the domain part for all email addresses included in SMIME certificates.”
Data sources and QIISes need to be accurate (BR § 3.2.2.7 / EVG § 11.11.5)
“[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.” If the CA intends to issue EV certificates, then the QIIS also needs to be evaluated for its reliability and accuracy. See EVG § 11.11.5.
Needs to be fixed – Section 3.2 of the CP references the use of a “reliable data source” (“a database used to verify information about the identity of organizations, recognized among commercial companies and public administrations as a reliable source and created by a third party, other than the applicant himself”). However, the CP and CPS do not contain the criteria and methods by which Firmaprofesional determines that a given data source is reliable.
Section 3.2.2.7 of the Baseline Requirements says, “The CA SHOULD consider the following during its evaluation:
\1. The age of the information provided,
\2. The frequency of updates to the information source,
\3. The data provider and purpose of the data collection,
\4. The public accessibility of the data availability, and
\5. The relative difficulty in falsifying or altering the data.”
Also refer to EVG § 11.11.5.
All information in a certificate must be verified (MRSP § 2.2.1)
“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”
Needs to be fixed – CP and CPS section 3.2.4 say, “No stipulation.” They should say that all information in a certificate is verified.
Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)
CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.” For EV Certificates, the reuse timeframe is now 398 days instead of 13 months.
Should be fixed – Section 3.2 of the CP says, “A signed document issued by an official registry 825 days before the issuance of the certificate is also accepted.” For EV certificates, this should be changed to 398 days. Section 4.4.1.3.1 of the CP says in several places, “Certificate or document issued two years before the SSL Certificate issuance, by the Trade Register or equivalent, LEI or Chamber Commerce two years before the SSL Certificate issuance.” These instances should be changed to 398 days for EV certificates.
CAA record checking and recognized domain names in section 4.2 (BR § 2.2)
“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”
OK – Section 4.2.2 of the CP says, “Prior to issuing the SSL OV, SSL EV and PSD2 certificates, the existence of a CAA record is validated for each DNS name of the CN and subjectAltName extensions of the certificate. In the event that the certificate is issued, validation will be done before the TTL of the CAA record. Firmaprofesional processes the "issue" and "issuewild" tags. The CAA record that identifies the domains for which the issuance by Firmaprofesional is authorized is "firmaprofesional.com".” Many CAs provide a more detailed explanation of CAA processing practices.
Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3)
CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.
Needs to be fixes or called out – I could not find the phrase “multi-factor authentication” in conjunction with “accounts capable of causing certificate issuance”. I did find this sentence “Additionally, the issuance of the SSL EV Web Server Certificate requires the approval of two people: the RA Operator in charge of managing the request and the Administrator of the Technical Department in charge of issuing the certificate.” But that is not the same thing as implementing two-factor authentication on such accounts.
Pre-issuance linting (Recommended Practices)
“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences.”
Should be fixed – Pre-issuance linting does not appear to be mentioned in the CPS or CP.
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)
Needs to be fixed – In section 4.9.1 of the CPS, Firmaprofesional lists the reasons for revocation and says, "This term will be reduced to 24 hours in the following cases:
The subscriber requests in writing that Firmaprofesional revokes the certificate.
The subscriber notifies Firmaprofesional that they have not authorised the original certificate request and do not retroactively grant this authorisation.
Firmaprofesional obtains proof that the subscriber private key corresponding to the public key in the certificate has been compromised.
Firmaprofesional obtains evidence that the validation of the domain authorisation, or the control of any qualified domain name or IP address in the certificate cannot be trusted.
If at the end of this period, the certificate is still suspended, Firmaprofesional will proceed with the automatic revocation."
Another reason for 24-hour revocation exists in section 4.9.1.1 of the Baseline Requirements – “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys”.
Firmaprofesional should review both section 4.9.1.1 and section 4.9.1.2 of the Baseline Requirements and ensure that it has adequately addressed the revocation reasons and timeframes. Also, certificate suspension is prohibited for server certificates, so this language needs to be clarified in the CPS. (Section 4.9.13 of the CP says that suspension is not allowed for website authentication certificates.)
SMIME Reasons for Revocation (MRSP § 6.2)
“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events … [e.g. MRSP § 6.2, ”5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted;”]
Needs to be fixed – Firmaprofesional should review MRSP section 6.2 and make sure it has covered the revocation reasons for SMIME certificates.
CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)
Good – Section 4.9.7 specifies, “The CRL of the end entity certificates are issued at least every 24 hours, or whenever a revocation occurs, and are valid for 7 days.”
Clearly specify methods to demonstrate private key compromise (MRSP § 6)
Needs to be fixed - Mozilla now requires that Section 4.9.12 of the CP or CPS describes the method by which any party can demonstrate private key compromise to Firmaprofesional.
CA must not allow certificate suspension (BR § 4.9.13)
Good. Section 4.9.13 of the CP states, “The suspension of any of the types of certificates contemplated in this policy is not allowed.”
OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)
OK – CPS section 4.9.10 states, “Information provided via OCSP service is updated at least every four days.”
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)
“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”
Should be fixed – Section 1.3.4 of the CPS says, “The Root Certificates of Firmaprofesional are recognised by the leading software vendors such as Microsoft, Apple or Mozilla Foundation.”
Section 5.7.3 states, “The Continuity Plan of the Firmaprofesional hierarchy treats the compromise of a CA’s private key or of the cryptographic suite (algorithms) as a disaster. In the event that a CA’s private key is compromised, Firmaprofesional will: 1. Inform all subscribers, users and other CAs with which it has agreements or any other type of formal commitment, at least by posting a warning on the CA’s webpage.”
Firmaprofesional should ensure that its disaster and continuity plans require someone to immediately notify Mozilla in the event of a key compromise.
CA must not generate Subscriber key pairs (MRSP § 5.2)
“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”
OK – Section 6.1.1 of the CPS states, “For end entity certificates, key generation devices will be carried out on devices which provide reasonable assurance that the private key can only be used by the signatory, either by physical means or by the subscriber setting the controls and afterwards taking appropriate security measures.” Section 6.1.1 of the CP says, “Specifically, in relation to this PC, signature keys will be generated within the applicant systems using their own compatible applications with the PKI standards.”
Must meet RSA key requirements (MRSP § 5.1)
Could be improved – CP sections 6.1.5 and 6.1.6 could be improved with reference to a modulus length divisible by 8, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#511-rsa, etc. and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide Firmaprofesional with safeguards.
Must meet ECC key requirements (MRSP § 5.1)
Could be improved – CP sections 6.1.5 and 6.1.6 could be improved with reference to
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#512-ecdsa
and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide Firmaprofesional with safeguards.
Certificate lifetimes limited to 398 days (BR § 6.3.2)
“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”
Good – Section 1.4.1.1 of the CP says, “Validity period will be indicated within the certificate, up to a maximum of 1 (one) year for all issued certificates that are described in this Policy.”
Network Security (MRSP § 2.1.2)
CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.
Needs to be fixed – Section 6.7 of the CPS states, “The CA prevents physical access to network management devices and has an architecture that directs the traffic generated based on its security features, creating clearly defined network sections. This division is performed by using firewalls.” Compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements should be ensured with incorporation of it by reference. https://cabforum.org/network-security-requirements/
Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)
“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”
Should be fixed – Section 7.1 of the Firmaprofesional CPS states that the serial number is “[a] Unique random code with respect to the issuer's DN”. The requirement is that the CA generates a non-sequential certificate serial number greater than zero (0) containing at least 64 bits of output from a cryptographically secure pseudorandom number generator (CSPRNG).”
EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)
More information needed – The EKUs of end entity server certificates can contain both serverAuth and clientAuth but the anyExtendedKeyUsage EKU cannot be present. The certificate profiles for OV and EV TLS certificates will need to be reviewed.
Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)
Should be fixed – Section 7.1.3 of the CPS lists the SHA1 algorithm as a supported algorithm without reference to it being prohibited.
Any CN must also be in a SAN (BR § 7.1.4.2.2.a)
Needs to be fixed – The CP or CPS should state that any commonName field in the certificate Subject DN has to be one of the SANs that has been validated pursuant to one of the allowed methods in BR section 3.2.2.4.
EXTENDED VALIDATION GUIDELINES REVIEW
The following additional EV review is based on version 1.7.4 of the EV Guidelines.
EVG Section 8.1 - the CA shall notify the CAB Forum if a provision of the EV Guidelines is illegal under local government laws.
Needs to be fixed – Firmaprofesional should add language acknowledging that if there is any inconsistency concerning its compliance with applicable domestic law and the Baseline Requirements or the EV SSL Certificate Guidelines, that the CPS may be adjusted to satisfy the requirements of such domestic laws, however the CA/Browser Forum shall be notified immediately of any such adjustment.
EVG Section 8.4 - the CA shall maintain liability insurance of US$2 million and professional liability insurance of US$5 million.
Should be fixed – Reference should be made to compliance with provisions of the EV Guidelines. Currently, section 9.2 of the CPS states, “As a Certification Services Provider Firmaprofesional has sufficient financial resources to bear the risk of liability for loss or damage to users of its services and to third-parties, guaranteeing its responsibilities in its activity of TSP as required by the current Spanish legislation. Such guarantees do not apply to certificates that are not qualified, in that case the amount in respect to loss or damage that must be paid by legal order is limited to a maximum of 6,000 €.” Section 9.2.1 states, “The aforementioned guarantee is established by means of a Civil Liability Insurance with a coverage of € 3,000,000 or in accordance with current regulations in Spanish legislation for trust service providers.”
EVG Section 9.2.1 - the organization name must include the full legal name for the subscribing organization as listed in official records.
OK – CP Section 1.3.3 says the name will be determined as follows: “The subscriber of the website authentication certificate will be the Organisation that appears as “Registrant” within the domain official register, or the Administration, Body or Public Law Entity identified in the certificate.” However, the Website Authentication Certificate CP generally lacks descriptions of the steps taken by a CA in between validating information and putting that information correctly in EV certificates.
EVG Sections 9.2.3, 11.2.1 and 11.2.2 – The CA must verify the Applicant’s legal existence and identity directly with the incorporating agency or registration agency and the business category field must contain one of the following: "Private Organization", "Government Entity", "Business Entity", or "Non-Commercial Entity"
OK – Section 4.4.1.3.1 of the CP (Verification of the applicant legal existence and identity) states the verification requirements for the four types of entities that are issued EV certificates. However, the Website Authentication Certificate CP generally lacks descriptions of the steps taken by a CA in between validating information and putting that information correctly in EV certificates.
EVG Section 9.2.4 - jurisdiction of incorporation/registration fields must not contain information that is not relevant to the level of the incorporating agency or registration agency.
Should be fixed – The Website Authentication Certificate CP generally lacks descriptions of the steps taken by a CA in between validating information and putting that information correctly in EV certificates.
EVG Sections 9.2.4, 9.2.5, and 11.1.3 – the CA shall maintain a publicly available list of its verification sources, incorporating agencies, and registration agencies (e.g. QIISes, QGISes, QGTISes). Information about where this information can be located must appear in section 3.2 of the CPS.
Good – Sections 1.4.1.2 and 3.2 of the CP say, “The list of Incorporating Agencies or Registry Agencies is published in the repository of the Firmaprofesional website (www.firmaprofesional.com), in the "Verification Sources" section.”
EVG Sections 9.2.5 and 11.2.1 - subject registration number: if the jurisdiction of incorporation or registration does not provide a registration number, then the date of incorporation or registration is entered in this field.
Should be fixed – The Website Authentication Certificate CP generally lacks descriptions of the steps taken by a CA in between validating information and putting that information correctly in EV certificates.
EVG Section 9.2.6 - subject physical address of place of business must contain the address of the physical location of the business.
Could be improved – CP section 4.4.1.3.2 (Verification of the geographic location where the applicant develops their business) contains a very brief description of the process for determining the physical location of the EV applicant. -- ”1) If the geographic location of the applicant appears in one of the methods mentioned in section “Verification of the applicant legal existence and identity”, then no additional verifications are needed.; 2) Consultation with a reliable database. For example Legal Entity Identifier (LEI).; 3) Notarial deed that certifies the geographic location.” Again, the Website Authentication Certificate CP generally lacks descriptions of the steps taken by a CA in between validating information and putting that information correctly in EV certificates.
EVG Section 9.2.7 - the CA shall implement a process that prevents an organizational unit from including a trade name unless the CA has verified that information.
OK – See CP Sections 3.2 and 4.4.1.3.1. “If the applicant wishes to incorporate the information of a registered trademark or trade name into the certificate, then it is verified that he has the right to use the trademark or name using one of the following means: ….”
EVG Sections 9.2.8, 9.8.2, and Appendix H – if included in the certificate, the CA shall confirm registration references for legal entities.
Should be fixed – please refer to EVG sections 9.2.8, 9.8.2, and Appendix H
EVG Section 9.2.9 - the CA shall not include any subject attributes except as specified in section 9.2 of the EV Guidelines.
Needs to be fixed – I could not find a limitation on the kinds of subject attributes that can appear in an EV certificate.
EVG Sections 9.3.2 and 9.3.5 - subscriber certificates shall contain the appropriate EV policy OIDs.
Good – Currently, from section 7.1, it appears to be using the EV OID of 1.3.6.1.4.1.13177.10.1.3.10. In the CCADB, the EV OID is also listed as 1.3.6.1.4.1.13177.10.1.3.10.
EVG Section 9.4 - the validity period for an EV certificate shall not exceed 398 days.
Good – Section 1.4.1.1 of the CP says, “Validity period will be indicated within the certificate, up to a maximum of 1 (one) year for all issued certificates that are described in this Policy.”
EVG Section 9.8.1 - wildcard certificates are not allowed.
Good – CP Section 1.4.1.3 says, “SSL EV Web Server Certificates and Electronic Office Certificates cannot be wildcard certificates.”
EVG Section 10.1.2 - the roles of certificate requestor, certificate approver, and contract signer are required for the issuance of EV certificates.
Good – CP section 1.3.3.2 says, “certain roles are established to be executed by distinct persons related to an SSL EV Certificate applicant.” It then lists these roles. Section 4.1.1.3 describes how these roles participate in the process.
EVG Section 11.2.2(4) - principal individuals of business entity must be validated in a face-to-face setting.
Should be fixed – CP section 4.4.1.3.1 says that for the representative of a business entity, Firmaprofesional checks “[an] Official document (record) of appointment, either of the General Meeting of the entity, of the public registry or power of attorney.” However, section 11.2.2(4) of the EV Guidelines has additional requirements that should be incorporated into the CP.
EVG Section 11.3.1 - assumed names must be verified with an appropriate government agency or a QIIS that has verified the assumed name with the appropriate government agency.
Good – See CP sections 3.2 and 4.4.1.3.1. “If the applicant wishes to incorporate the information of a registered trademark or trade name into the certificate, then it is verified that he has the right to use the trademark or name using one of the following means: ….”
EVG Section 11.5.1 - the CA must establish a verified method of communication with the applicant.
Needs to be fixed – I could not find in the CP any reference to the EV Guidelines’ “Verified Method of Communication”. Firmaprofesional should explain how it complies with section 11.5 of the EV Guidelines.
EVG Section 11.6.1 - the CA must verify that the applicant has the ability to engage in business. The EV issuance process requires that the operational existence be established in one of 4 ways: “(1) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has been in existence for at least three years, as indicated by the records of an Incorporating Agency or Registration Agency; (2) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company is listed in either a current QIIS or QTIS; (3) Verifying that the Applicant, Affiliate, Parent Company, or Subsidiary Company has an active current Demand Deposit Account with a Regulated Financial Institution by receiving authenticated documentation of the Applicant's, Affiliate's, Parent Company's, or Subsidiary Company's Demand Deposit Account directly from a Regulated Financial Institution; or (4) Relying on a Verified Professional Letter to the effect that the Applicant has an active current Demand Deposit Account with a Regulated Financial Institution.”
Needs to be more consistent with EVG 11.6.1 - CP section 4.4.1.3.3 says, “All methods described in sections “Verification of the applicant legal existence and identity” and “Verification of the geographic location where the applicant develops their business”, verify that the organisation has an active status. If this was not possible, it would be necessary an online consultation with a reliable database like Legal Entity Identifier (LEI); Evidences contained in section “Verification of the applicant legal existence and identity”, copy of consultation with the reliable database. “
EVG Section 11.7.1 - domain name verification must use a procedure from section 3.2.2.4 of the Baseline Requirements (BR)
Good – CP 4.4.1.3.4 says, “For EV certificates, Firmaprofesional will follow the same method for domain name control verification than for OV certificates.”
EVG Section 11.8.1 - the CA must verify the name and title of the contract signer and certificate approver
Good - See CP section 4.4.1.3.5 (Verification of name, position and authority of the subscriber contract signatory and the certificate approver)
EVG Section 11.9 - the CA must verify the signature on the subscriber agreement and certificate request
Good - See CP sections 4.1.1.3, 4.2, 4.2.2 and 4.4.1.3.6 (Verification of the subscriber contract signature)
EVG Section 11.11.5 - the CA shall use documented processes to check the accuracy of a QIIS.
Needs to be fixed – see discussion above under Data sources and QIISes need to be accurate (BR § 3.2.2.7 / EVG § 11.11.5). Firmaprofesional needs to state how it establishes the reliability and accuracy of QIISes.
EVG Section 11.12.2 - the CA must check whether the applicant, contract signer, or certificate approver is on denied persons lists, etc.
Needs to be fixed - CPS section 3.2.7 only says, “Firmaprofesional has methods to identify high-risk certificates through the use of blacklists, which require additional checks.” This needs to be more specific for the EV process and say that Firmaprofesional checks to ensure that the applicant, contract signer, and certificate approver are not prohibited by Spanish law from doing business by being on any applicable government denied persons list or registry, e.g. for money laundering or terrorism financing, even though Spain might not have such lists.
EVG Sections 11.13, 14.1.3 and 16 - the CA must perform final cross-correlation and other due diligence based on the entire corpus of information and have multi-person, auditable controls to ensure separation of duties with respect to EV certificate issuance
Partially OK - See CP section 4.2.2 (“the issuance of the SSL EV Web Server Certificate requires the approval of two people: the RA Operator in charge of managing the request and the Administrator of the Technical Department in charge of issuing the certificate”). However, I did not find mention of “final cross-correlation and other due diligence based on the entire corpus of information.”
EVG Section 11.14.3 - validation data cannot be reused after 398 days
Should be fixed - See my comments above under “Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)”. I didn’t see any limitations except for two years in the CP, and not the thirteen-month EV timeframes, which will be 398 days effective October 1, 2021.
EVG Section 12 - root CA private keys must not be used to sign EV certificates
Needs to be fixed – Section 6.1.7 of the CPS says, “Permitted uses of the key for each certificate are defined in the corresponding Certification Policy.” But section 6.1.7 of the CP says, “As stated in the current Certification Practices Statement of Firmaprofesional.” Section 6.1.7 should say what Root private keys are allowed to be used for.
EVG Section 14.1.1 - a CA must verify the identity and trustworthiness of anyone involved in EV processes
OK – CPS section 5.3.1 says, “All personnel who have been qualified as sufficiently trustworthy to perform tasks without supervision must have spent at least six months working in the production centre and have a fixed employment contract.” However, it does not specifically say that this applies to persons involved in EV processes. See EV section 14.1.1 for a more detailed explanation of steps that need to be taken.
EVG Section 14.1.2 – the internal examination of specialists must include the EV certificate validation criteria of the EV guidelines
Needs to be fixed – CPS Section 5.3.1 says, “All staff are qualified and have been fully trained to perform the operations to which they have been assigned.” See EVG § 14.1.2 and BR 5.3.3 for additional details.
EVG Section 14.2.1 - the CA shall ensure that third-party personnel satisfy the training and skills requirements of section 14 of the EV guidelines.
Needs to be fixed – CPS Section 5.3.7 contains no guarantees that third-party personnel have the necessary training or skill to perform EV-related duties.
|
||
Comment 39•4 years ago
|
||
Thanks for the thorough analysis.
We are working on a new version of both documents.
|
||
Comment 40•4 years ago
|
||
Dear Ben,
Here we attach the new CPS: https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CPS-210628-EN-sFP.pdf
and CP Website Authentication Certificates: https://www.firmaprofesional.com/wp-content/uploads/pdfs/FP_CP_Autenticacion_Web-210628-EN-sFP.pdf
We have incorporated all the changes that you indicated "need to be fixed" and most of "Should be fixed" "Adequate", "Could be improved" and "more information".
This is a summary of them:
CPS's Changes:
● Update of section 1.4.2.1. and 1.5.2. incorporating key compromise, complaints or suggestions
● Update section 2.4 reference BR Audits.
● Update section 3.1.4 EV Guidelines reference and data requirements of natural or legal persons without restriction of characters.
● Update section 3.2 criteria for Verification Sources.
● Update section 3.2.2.1 reference to the Web authentication PC
● Update section 3.2.4 and 3.2.7
● Update section 4.2 reference RFC 6844 ERRATA 5065
● Update section 4.9.1 incorporation of new revocation circumstances
● Update of section 4.9.3.1 Online procedure
● Update of section 4.9.12 key compromise verification methods
● Update of section 6.2.1
● Update of section 4.10.2
● Update of section 5.3.1 specific training requirements for validation specialists
● Update of section 5.3.7
● Update section 5.7.3 Notification of software manufacturers for compromise of keys.
● Update section 6.1.7 permitted uses of keys clarifying the permitted uses of certificates
● Update section 6.2.1 Loss of QSCD qualification
● Update section 6.7
● Clarification of the minimum entropy of the serial number in section 7.1
● Update section 7.1.3 incorporation of date of prohibition of use of SHA1
● Update section 9.2.1 clarification of coverage required by the EV Guidelines
● Update section 9.5
● Update section 9.14 and 9.15 prevalence of the EV Guidelines and resolution of conflicts with national law
CP Website Authentication Certificates' Changes:
● Update section 3.2 Selection criteria for Verification Sources
● Update section 3.2.2.1
● New section 4.1.1.1. Verified methods of communication
● Update section 4.2.2 verification of information by two people
● Update section 4.3.1 incorporation cablint and zlint tools
● Update section 4.4.1.3.1. reference to section 11.2.2 (4) of the EV Guidelines, adequacy of validity time of evidence and reference to the verification Sources validated by Firmaprofesional
● Update section 7.1 subject field according to section 9.2 EV Guidelines
● Clarification on pre-certificates in section 7.1.2 and reference to the subjectAlternativeNames
● Update section 8.2 reference to quarterly SSL audits
Best regards,
|
|
Assignee | |
Updated•4 years ago
|
|
|
||
Comment 41•4 years ago
|
||
If there is anything that we can do to speed this up, please, let us know.
|
|
Assignee | |
Comment 42•4 years ago
|
||
Review based on the Firmaprofesional CP and CPS cited in Comment #40
CPS's Changes:
Fine - except noted below as follows:
● Update section 3.1.4 EV Guidelines reference and data requirements of natural or legal persons without restriction of characters.
OK, but Firmaprofesional should consider clarifying this language because it led to a discussion in Bug # 1717795 https://bugzilla.mozilla.org/show_bug.cgi?id=1717795.
● Update section 4.2 reference RFC 6844 ERRATA 5065
OK, but note that RFC has been obsoleted by RFC 8659 - see https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.8.pdf
● Update section 4.9.1 incorporation of new revocation circumstances
OK, the CPS now states, "For SSL certificates, for any of the causes established in the Baseline Requirements or in the EV Guidelines of the CA Browser Forum and in the times established for each cause"
● Update section 6.7
OK, but I would have liked to have seen specific reference to the CA/Browser Forum's Network and Certificate Systems Security Requirements
CP Website Authentication Certificates' Changes:
OK
|
|
Assignee | |
Comment 43•4 years ago
|
||
Public discussion of this inclusion request began today. See:
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0FIybeh-N4s/m/2JyxAirsBAAJ
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 44•4 years ago
|
||
Public discussion has now closed with a recommendation that Mozilla approve and implement this inclusion request.
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0FIybeh-N4s/m/MIRkSrDMAwAJ
|
|
Assignee | |
Updated•4 years ago
|
|
|
||
Comment 45•4 years ago
|
||
As per Comment #44, and on behalf of Mozilla I approve this request from Autoridad de Certificacion Firmaprofesional to include the following root certificate:
- Autoridad de Certificacion Firmaprofesional CIF A62634068 (Email, Websites); EV
I will file the NSS and PSM bugs for the approved changes.
|
|
||
Comment 46•4 years ago
•
|
||
I have filed bug #1741930 against NSS and bug #1741932 against PSM for the actual changes.
|
|
||
Updated•4 years ago
|
|
||
Updated•3 years ago
|
Description
•