Add ANF AC root certificates
Categories
(CA Program :: CA Certificate Root Program, task, P1)
Tracking
(Not tracked)
People
(Reporter: pablo, Assigned: bwilson)
References
Details
(Whiteboard: [ca-approved] - In NSS 3.66, FF 90; EV enabled in FF 90)
Attachments
(5 files, 3 obsolete files)
User Agent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36
Steps to reproduce:
CA Name: ANF Autoridad de Certificación (ANF AC)
Website: www.anf.es
Current CPS: https://anf.es/pdf/Certification_Practices_Statement_ANFAC_v26.pdf
Current CP: https://anf.es/pdf/CP_SSL_Electronic_Headquarters_v2_8.pdf
ANF Autoridad de Certificación (ANF AC) requests the inclusion of the following Root certificates in Mozilla Root Store and enable EV treatment:
[ROOT 1] ANF Secure Server Root / FB8FEC759169B9106B1E511644C618C51304373F6C0643088D8BEFFD1B997599
[SUBCA 1.1] ANF High Assurance Server CA / 8AF55A7E98536624CD3E4CDCEE7F7CC591460DB781BA8450BA053B069695C174
[ROOT 2] ANF Global Root CA / E0AFBD2C0EE95A68CD9A3C590B2D3FE07C0A6D0BE796AE5291E424D47792178E
[SUBCA 2.1] ANF Global Subordinate EV CA1 / 7FB3A023DCCE660E387D18B9F3454D82CA77223DE537008E27C8F63F1A0A81D2
Information is provided in CCADB Root inclusion Case 00000501 including URL for root download, test websites and explanation of recommended and forbiden practices. All cablint, zlint, x509lint tests have been performed without errors.
Mozilla Root Inclusion Case Information: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000501
Root Store Operators may access this page via: https://ccadb.my.salesforce.com/5001J00000oOFAJ
Baseline Requirements 1.6.6. Self-Assessment is attached to this Bug.
If further information or evidence is required, we are at your complete disposal.
Pablo Díaz
ANF Autoridad de Certificación
Actual results:
Currently both Root certificate are not included in Mozilla Root Store.
Expected results:
Inclusion of Root certificates (ANF Secure Server Root) and (ANF Global Root CA) in Mozilla Root Store.
|
||
Comment 1•6 years ago
|
||
Adding a note to the previous Bug 555156 . Issues with the auditor were identified, as well as the issuance of misissued test certificates from the hierarchy.
|
Reporter | |
Comment 2•6 years ago
|
||
Dear Ryan, due to the responsibility that comes with being included in any Root store, I understand that has to be taken into account.
Note that currently, the misissued test certificates identified in the previous bug are all revoked, do not refer to the hierarchies here identified for inclusion and, as pointed out in the previous bug, ANF AC has quickly taken appropriate measures to prevent and prohibit the issuance of test certificates without the corresponding CA/B Forum OID, as well as the indicated period of validity.
Both hierarchies (ANF Secure Server Root) and (ANF Global Root CA) ANF AC is requesting for inclusion in this bug do not have any misissued certificates.
|
|
||
Comment 3•6 years ago
|
||
Pablo: While it is useful that you now have a (potentially) clean hierarchy, it is important to understand the impact these past actions have on future trust. As best I can tell, this was under the same auditor as previously used, using the same audit criteria, and the same CP/CPS as when these misissued certificates were issued. Similarly, ANF was trusted by two other browser root stores, Microsoft and Apple, and the time these incidents occurred.
From a relying party side, this gives the impression that either ANF does not understand the relevant requirements, or, worse, does not intend to follow them. The best solution for such a scenario, the one that keeps the most users safe and secure, would be to never, ever trust ANF certificates, past, present, or future. I’m sure that sounds rather extreme, and so it is important for ANF to understand it is working with a “trust deficit” - it has done things that has and would have led to immediate and complete distrust, and thus has a highly damaged reputation.
If ANF would like to pursue inclusion, it needs to acknowledge that the community has no reason to trust it and ample reason not to, and work to provide the necessary degree of transparency and to identify meaningful steps it can take to restore trust: not just to the baseline of other pending CAs (where we don’t know anything about them), but to a level where the community believes it’s in the best interest to trust ANF.
This is the CAs responsibility, and so I’m not going to lay out some multi-step program for you. You need to identify things you can do to restore trust before you should be trusted. However, to help give you a sense of things, expecting incident reports for past misissuances under the old hierarchy, and comprehensive responses that provide meaningful details, are one way. Of course, if the incident responses are bad, if they lack detail or don’t provide confidence that ANF understands the issues and has mitigated them from ever reoccurring, then they may credibly prevent trust from being granted.
|
|
Reporter | |
Comment 4•6 years ago
|
||
Ryan: I attach, as you recommend, a report on the incidents identified in bug 555156 about the old hierarchy (not subject to inclusion), and the corrective measures taken. I understand that the technical incidents to which you refer, are two incidents detected in the issuance of test certificates for internal purposes. These incidents should not have occurred, but we affirm that in no case have they caused, nor could they have caused damage to third parties.
Based on these technical incidents, you make statements such as: "the best solution would be to never ever trust ANF certificates, past, present or future", "has a highly damaged reputation", or "ANF does not understand the relevant requirements, or, worse, does not intend to follow them”.
Nothing further from reality. In our organization, it is as important to confront and fix the mistakes made, as maintaining a rational balance in the use of hyperboles that do not fit reality. Based on these technical incidents, you build a series of subjective reputational considerations that in no way conform to reality. In all sincerity we have to say, (by no means contradicting that these incidents did not have to occur), that to use these qualifications and consequences, seems to us more than excessive.
I insist that the hierarchies here requested for inclusion have nothing to do with these incidents, and the CP and CPS have been updated 100% in accordance with CA/B Forum Baseline Requirements and EV Guidelines. ANF AC has worked hard to comply with the applicable requirements and is aware of the importance of operating in strict compliance with the standards.
With respect to reputation, I consider important to inform that ANF AC was founded in 2000. In the almost twenty years of operation we have not had a single incidence. Our activity has focused on the issuance of certificates for electronic signature, electronic seals, time stamps and certified validations, always used in economic transactions and of high legal importance. We are one of the few CAs in the European Union (EU) that has the highest level of accreditations, such as qualified validation of electronic signatures and seals, among others. We are officially recognized to operate in all EU countries, and Latin American third parties, and for the issuance of PSD2 certificates. At present, our volume of identity certificate issuance exceeds 300,000 units per year to customers who trust ANF AC. One of the most valued points of ANF AC's PKI is the strength of our identity authentication procedures.
Regarding the previous bug 555156, it started in 2010. As you know, in January 2016, after the second public comment period, the summary of the assessment was:
“…I am not aware of instances where ANF has knowingly issued certificates for fraudulent use….
…ANF appears to provide a service relevant to Mozilla users. ANF is a private Certification Authority, recognized and accredited by the Spanish Government as a Certificate Services Provider (CSP). ANF AC has accredited more than 1000 Registry Authorities throughout Spain to issue qualified user identity certificates. ANF CA also issues certificates for SSL with and without Extended Validation.
…Based on this assessment I intend to approve this request from ANF to include the "ANF Global Root CA" root certificate, enable the Websites trust bit, and enable EV treatment.”
However, given the subsequent technical incidents that you detected, the ANF AC’s CEO gave orders to stop the process and to replace the technical department, and enter a period of strengthening human and technical resources.
In 2019, as can be seen in the change of contact made in the CCADB, ANF AC has built a new technical team that has the confidence of ANF AC’s CEO.
Again, I insist, the considerations made are not intended to understate or downplay the incidents detected in the old hierarchy (not subject to inclusion), the technical aspects are addressed in the attached report.
|
|
Reporter | |
Comment 5•6 years ago
|
||
|
|
||
Comment 6•6 years ago
|
||
(In reply to Pablo Díaz from comment #4)
I understand that the technical incidents to which you refer, are two incidents detected in the issuance of test certificates for internal purposes.
There were, quite literally, dozens. Nearly every certificate from this particular CA was misissued.
These incidents should not have occurred, but we affirm that in no case have they caused, nor could they have caused damage to third parties.
This is, and has always been, completely irrelevant, particularly when taking a risk based approach. The difference between "damage to third parties" or not is, in the CA space, "luck", usually of the "sheer dumb" kind.
I insist that the hierarchies here requested for inclusion have nothing to do with these incidents, and the CP and CPS have been updated 100% in accordance with CA/B Forum Baseline Requirements and EV Guidelines. ANF AC has worked hard to comply with the applicable requirements and is aware of the importance of operating in strict compliance with the standards.
Am I correct that these are the same CP/CPS, from the same auditor?
One of the most valued points of ANF AC's PKI is the strength of our identity authentication procedures.
One of the most valued points for CAs being publicly trusted is their ability to understand and follow the requirements placed on them. ANF has demonstrated it has not done so in the past. It is attempting to demonstrate that it will now do so in the future. In the attached incident report, in Comment #5, ANF demonstrates that it still does not understand the requirements or expectations of the Baseline Requirements nor of Mozilla Policy, and why the proposed remediations are themselves prohibited. Similarly, in its response, it demonstrates that it is not aware of the significant misissuance it has caused.
With respect to the European supervision, it is all well and good that the Supervisory Body accepted the Conformity Assessment Report. However, the relying public has no equivalent information to go on when determining whether ANF is trustworthy. As important is the prospect that the question of whether or not the auditor was examining for compliance with the Baseline Requirements or with the eIDAS Regulation, the latter of which certainly does not require compliance with the former, and in both cases, are inadequate for compliance with Mozilla Policy.
However, given the subsequent technical incidents that you detected, the ANF AC’s CEO gave orders to stop the process and to replace the technical department, and enter a period of strengthening human and technical resources.
In 2019, as can be seen in the change of contact made in the CCADB, ANF AC has built a new technical team that has the confidence of ANF AC’s CEO.
In 2019, ANF misissued dozens of certificates, some as recent as a few months ago, from a hierarchy trusted by multiple browsers, in contravention of the Baseline Requirements. You can understand why the public, for whom the only information they have is what ANF has actually done, which is some of the most serious and egregious badness, would not have confidence in the technical team.
|
|
Reporter | |
Comment 7•6 years ago
|
||
(In reply to Ryan Sleevi from comment #6)
Ryan: In the previous bug for the old hierarchy, ANF AC received indications that, to avoid confusion, it was most convenient to create a new and clean hierarchy, and that Mozilla closed the root inclusion case. Precisely for that reason ANF AC requested the withdrawal of the inclusion request for the old hierarchy. The old hierarchy is not, nor has it ever been included in Mozilla's Root Store.
Kathleen said:
“Closing the request [Referring to previous bug] as WONTFIX. I am also going to close the existing Root Inclusion Case in the CCADB, in order to avoid future confusion. Pablo, when you are ready with the new CA hierarchy and corresponding documentation, please create a new Root Inclusion Case and corresponding Bugzilla Bug as described here: [Link to Mozilla Wiki - Create a Root Inclusion Case]”
ANF AC has proceeded as instructed.
For ANF AC, the old hierarchy is outside the scope of Mozilla's Policy, and so the auditor was informed. We have reviewed both the Mozilla Policy and the “CA/Responding To An Incident” procedure published by Mozilla, and we have not succeeded to find any indication that an incident occurred in a hierarchy not included in Mozilla (or currently under review) should be reported. Could be considered outside the scope of Mozilla, unless there is any Mozilla’s document we have not taken into account.
ANF AC regarding the new hierarchies and possible incidents and the corresponding communication to Mozilla, has established procedures that we understand are as required to comply with the indications published by Mozilla. Specifically, the mechanisms implemented determine that the process to follow in case of an incident is:
- Immediately suspend the issuance of the affected part of the ANF AC PKI until the source of the problem is diagnosed.
- Investigate the facts and circumstances related to the problem reported and provide a preliminary report on the conclusions to both the subscriber and the entity that presented the problem report.
- Establish whether the certificate should be revoked or not, and if so, establish a date on which ANF AC will revoke the certificate (less than 5 days), taking into account possible damage of subscribers. In the event that the affected certificate was not to be revoked within the period of time required by the BR, the procedure in Mozilla’s “CA/Responding To An Incident” will be followed.
- Find out how the error or problem arose and why the problem was not detected before.
- Review the need to update any process to ensure that the latest version of the applicable requirements is met.
- Review of certificates issued to find others with the same problem.
- Examination of possible related problems that can be remedied at the same time.
- Provide Mozilla with a report of the incident, within a maximum period of 2 weeks, which will include how and when the incident was detected, the summary of affected certificates (number, date, fingerprint, link crt.sh), explanation of how and what allowed the misissuance (or the incident), why problem was not detected before, measures taken to solve the situation, and the schedule of action planning, in addition to how the systems of ANF AC have been reinforced so that it does not return to happen. It will also be indicated if the hierarchy has been suspended or not and, where appropriate, a declaration of formal commitment to the Community. This report shall be published in a bug in Bugzilla under the NSS: CA Certificate Compliance component or by publishing the report in the mozilla.dev.security.policy mailing list.
In no case ANF AC intends not to comply with the requirements placed on us, and our predisposition is absolute in demonstrating compliance. The new hierarchies presented in this bug are totally clean. We provide test web pages in CCADB whose certificates do not present a single error or warning. Checks in certificate revocation check (examples attached), have a 100% compliance, without a single warning, or notice, which I have rarely seen in other CAs.
The main purpose was to close the previous bug and renounce to continue with the old hierarchy so as not to create confusion, and what is happening at the moment is quite the opposite, precisely causing even more confusion. References to the old hierarchy are constant, we are told to respond to incidents of the previous hierarchy in a bug in which that hierarchy is not included. How are we going to give responses of incidents of a hierarchy of another bug which at the moment is closed as WONTFIX?
We request clarification in this regard, if what is desired is that ANF AC gives a formal response to incidents of a hierarchy whose request for inclusion in Mozilla has been waived and which bug is WONTFIX, we consider that we cannot do so without authorization from Mozilla’s responsible, since it is contrary to what was previously indicated to us and leads to confusion. Basically, we believe that we cannot freely open a formal incidence about the old hierarchy in the bugs of the new ones, nor can we include, without authorization, formal notice of incidence in a hierarchy that is already withdrawn and closed.
If the aim is to know whether ANF AC is able to respond to an inciden with respect to the hierarchies currently under review, we see the following options:
- Simulate an incident in these hierarchies and as a test, analyze our response, which is not contemplated in the norms, nor do we believe that it provides any real value.
- Follow up on ANF AC and the incidents that may occur in order to check the quality of the response. Which we understand that this is what is established. Mozilla’s document itself states:
“…this is a best practices document, not an official policy, and does not use normative language. Therefore, failure to follow one or more of the recommendations here is not by itself sanctionable. However, failure to do so without good reason may affect Mozilla's general opinion of the CA. Our confidence in a CA is in part affected by the number and severity of incidents, but it is also significantly affected by the speed and quality of incident response.”
- Accept the ETSI compliance audit, which is required by the Baseline Requirements and Mozilla Policy.
As important is the prospect that the question of whether or not the auditor was examining for compliance with the Baseline Requirements or with the eIDAS Regulation, the latter of which certainly does not require compliance with the former, and in both cases, are inadequate for compliance with Mozilla Policy.
Ryan, as far as we know, WebTrust audits as well as ETSI audits are accepted by Mozilla. Since the Mozilla Root Store Policy, in its 3.1.1 section. accepts the corresponding ETSI standards as audit criteria, which is adequate for compliance with the Mozilla Policy.
This is, and has always been, completely irrelevant, particularly when taking a risk based approach. The difference between "damage to third parties" or not is, in the CA space, "luck", usually of the "sheer dumb" kind.
Mozilla states in [CA/Responding To An Incident], that the breach of one or more of the recommendations of that document is NOT SANCTIONABLE and, where appropriate, will be taken into account the number and severity of the incidents. Regarding this last point, it should be noted that the document itself mentions the “severity of the incidents”.
The Mozilla document itself refers to the "severity of the incident" being considered. But it is not only Mozilla who considers the de impact factor, when a risk-based approach is adopted, either under ISO 27001, or ISO 31010, in no case is the risk factor analyzed by itself. It is essential to take into account the “impact” that would cause if it materialized and the “probability” of its occurrence. You do not take these factors into account?
ALL the certificates issued by the former hierarchy were TEST certificates, all of them revoked now. Most of those certificates were only for testing with Google's transparency servers, and the rest are internal tests. Does that mean we do not give it importance? Of course not, but it has to be valued in its right measure. Again, that ALL those certificates corresponded to a hierarchy not included in the Mozilla Root Store, none corresponding to the hierarchies currently under review. Logically, unless reading error and unless in some section indicates that all hierarchies of an organization are submitted.
It is true that Mozilla’s documents indicate that, regardless of the severity or not of the incident, the incidents have to be reported. But it is also objective to consider that the incidents to be reported correspond to hierarchies submitted for review or approved. At least, this can be interpreted to the extent that Mozilla's documents say nothing else and, when we were invited by Mozilla to renounce the old hierarchy, and present new hierarchies. Otherwise, what other sense could it have?
|
|
Reporter | |
Comment 8•6 years ago
|
||
|
|
Reporter | |
Comment 9•6 years ago
|
||
|
|
||
Comment 10•6 years ago
|
||
(In reply to Pablo Díaz from comment #7)
The main purpose was to close the previous bug and renounce to continue with the old hierarchy so as not to create confusion, and what is happening at the moment is quite the opposite, precisely causing even more confusion. References to the old hierarchy are constant, we are told to respond to incidents of the previous hierarchy in a bug in which that hierarchy is not included. How are we going to give responses of incidents of a hierarchy of another bug which at the moment is closed as WONTFIX?
It's important to understand what the purpose of a Root Inclusion Request is, and how the process works. The Root Inclusion Request is an attempt, by the Mozilla Community, to build an understanding about the operation of a potential Root CA, their policies and practices, their benefit to Mozilla users and the broader community, and any risks that might be introduced by trusting them.
New CAs start out with basically a clean slate. The community knows nothing about them, and has no predictors as to their success or failure as a CA. Information like audits and CP/CPSes are carefully examined, as are the responses to various questions, to make sure that this is an organization capable of behaving as trustworthy and respected as any of the existing CAs included.
Existing CAs applying for new or replacement roots similarly go through a process, in which their past performance and issues are evaluated, and the risk of continued trust is considered. More information is available for existing CAs, and thus it's important to consider that information, and all the information available, in making a decision.
While it's true that ANF's previous request was closed out, it's important to note that this was a CA that was, according to multiple other Root Programs, required to comply with the Baseline Requirements. Thus, it's understandable to be quite concerned about the trustworthiness of ANF, especially when removing a CA is much more time, effort, and risk, than declining to include a CA. It's not simply the certificate hierarchy that's investigated, but also the processes, management, oversight, decision making, supervision - all of the things that would exist as checks and balances to prevent or detect issues.
My request for an incident report was to highlight that, of all the CAs pending application, ANF was, as recently as the beginning of this year, operated in one of the least trustworthy fashions ever seen for a CA. Were ANF included, it likely would have been removed, and prevented from reapplying without a significant restructuring of management, technical and operational controls, and oversight. If it helps to think of it numerically, "most" CAs start at 0, and work to build up enough evidence to get to 100. Despite this being a new bug, ANF is basically starting from "-100" (untrustworthy), and thus it's important to not only demonstrate the minimum required information, but to show how those many clearly problematic behaviours have been corrected.
Referring to audits and CP/CPS don't help here; arguably, they make it worse, because the audits and CP/CPS were not impacted by the issues that affected the old hierarchy, when they should have been. That's why I wanted to provide both the opportunity and encouragement for ANF to demonstrate that it was capable of behaving as a trustworthy CA, by showing a detailed approach to incident management and response that would help provide assurance, to the Mozilla community, that if something went wrong with the new hierarchy (as it did with the old hierarchy), that ANF would be better positioned to respond, and that it had already taken meaningful steps to ensure things won't go wrong. The incident report provided failed to demonstrate this, because it missed even the most basic of compliance issues.
ANF is not required to respond to any of this, of course. However, it would be grossly negligent to ignore ANF's past operations when considering a new hierarchy. After all, being a CA is about being trustworthy, and that's not something audits can ever demonstrate or prove.
As important is the prospect that the question of whether or not the auditor was examining for compliance with the Baseline Requirements or with the eIDAS Regulation, the latter of which certainly does not require compliance with the former, and in both cases, are inadequate for compliance with Mozilla Policy.
Ryan, as far as we know, WebTrust audits as well as ETSI audits are accepted by Mozilla. Since the Mozilla Root Store Policy, in its 3.1.1 section. accepts the corresponding ETSI standards as audit criteria, which is adequate for compliance with the Mozilla Policy.
I'm afraid this still misunderstands the issue. The issue is not the use of ETSI. It's that your chosen auditor failed to actually examine compliance with the ETSI standards. An audit that claims to be against the ETSI standards, but fails to actually checks them, is an untrustworthy audit, and arguably, an untrustworthy auditor. Root Programs are not just interested in the statement of what standard is used, but about assurances that the standards are actually evaluated. The failure of the auditor to detect such significant issues of non-compliance is, arguably, a disqualifying event for that auditor.
ALL the certificates issued by the former hierarchy were TEST certificates, all of them revoked now.
No, they were not. Any CA applying for recognition in Mozilla's program should understand the requirements in the Baseline Requirements. These were not test certificates. That's what's being seen as problematic here: ANF was doing testing, using production services, and not even using an appropriate profile to reduce that risk. That's indistinguishable from gross negligence.
|
|
Reporter | |
Comment 11•6 years ago
|
||
I can assure that ANF AC fully assumes the necessary effort to demonstrate that we currently have the capacity and willingness to meet the obligations imposed by Mozilla's policies.
(In reply to Ryan Sleevi from comment #10)
ANF is not required to respond to any of this, of course. However, it would be grossly negligent to ignore ANF's past operations when considering a new hierarchy. After all, being a CA is about being trustworthy, and that's not something audits can ever demonstrate or prove.
I understand that the approach is that ANF AC formally prepares the detailed incident reports and include them in the corresponding bug of the old Hierarchy, unless otherwise indicated. We proceed to do so.
|
||
Updated•6 years ago
|
|
|
||
Comment 12•6 years ago
|
||
The information for this root inclusion request is here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000501
It appears that the request is for inclusion of two root certificates, as follows.
-
CN=ANF Secure Server Root CA; OU=ANF CA Raiz; O=ANF Autoridad de Certificacion; C=ES
SHA-256 Fingerprint: FB8FEC759169B9106B1E511644C618C51304373F6C0643088D8BEFFD1B997599
Valid From: 2019 Sep 04 -
CN=ANF Global Root CA; OU=ANF Clase 1 CA; O=ANF Autoridad de Certificacion; C=ES
SHA-256 Fingerprint: E0AFBD2C0EE95A68CD9A3C590B2D3FE07C0A6D0BE796AE5291E424D47792178E
Valid From: 2016 May 20
Pablo,
Is it your intent to re-request inclusion of the "ANF Global Root CA" root?
Per Bug #555156, there are many compliance problems within this CA hierarchy.
Or is it your intent for this new request to only be about inclusion of the new "ANF Secure Server Root CA" root?
|
|
Reporter | |
Comment 13•6 years ago
|
||
Hello Kathleen,
Sorry for missing your comment. We appreciate your support.
(In reply to Kathleen Wilson from comment #12)
Or is it your intent for this new request to only be about inclusion of the new "ANF Secure Server Root CA" root?
I confirm that in order to simplify the process and avoid confusion, we will focus our request for inclusion only on the new hierarchy:
CN=ANF Secure Server Root CA; OU=ANF CA Raiz; O=ANF Autoridad de Certificacion; C=ES
SHA-256 Fingerprint: FB8FEC759169B9106B1E511644C618C51304373F6C0643088D8BEFFD1B997599
Valid From: 2019 Sep 04
|
|
||
Comment 14•6 years ago
|
||
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=00000501
In particular:
-
It is not clear to me if the audit criteria listed in the audit statement matches the criteria required by section 3.1.2.2 of Mozilla's Root Store Policy https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3122-etsi
Related to this, Audit Letter Validation (ALV) of the audit statements gives error: Failed to validate EKU 'Server Authentication' because the standard names and standard policies are not found in the audit letters (case insensitive): ... "en 319 411-1 v1.1.1, dvcp;ovcp;ptc-br"; ... -
Based on the CPS, it appears that TEST certificates are allowed. If TEST TLS certificates are allowed, then it must be very clear and documented in the CPS that domain ownership validation is must still be performed for TEST certificates. Otherwise the CPS needs to make it very clear that TEST TLS certificates cannot be issued.
CPS section 3.1.2: "In the event that the data entered in the DN is fictitious or its disability is expressly indicated (e.g. "TEST"), the certificate will be considered without legal validity, only valid for performing interoperability technical tests."
CPS section 7.1.11: 1.3.6.1.4.1.18332.20.10 Test certificate identifier, with three possible status values ("active", "revoked" or "expired") -
Resolve all errors listed here https://certificate.revocationcheck.com/www.inledis.com ERROR: Response expired 357h16m4s ago ERROR: ThisUpdate is more than seven days old, CRLs must be updated and reissued at least every seven days (Mozilla Maintenance Policy section 3)
|
|
Reporter | |
Comment 15•6 years ago
|
||
Hello Kathleen. Requested clarifications:
-
AUDIT CRITERIA LISTED IN AUDIT STATEMENT: The audit statement, in section "Criteria ETSI applied" includes: Qualified certificate for website authentication (Art. 45 of the eIDAS Regulation and ETSI EN 319 401, ETSI EN 319 411-1 e 411-2). Includes EN 319 411-2 and EN 319 411-2 (Required by Mozilla's Root Store Policy). It includes both as EN 319 411-2 is an extension of part one for EU Qualified TSP issuing qualified certificates. Part 2 includes Part 1 by reference, so auditing against EN 319 411-2 is the same as auditing against both part 1 and 2.
Also, the audit statement includes QCP-w (Qualified Certificate Policy for Website Authentication Certificates).
In "Audit criteria" section, it can be found: "ETSI EN 319 411-1 v1.2.2" and "ETSI EN 319 411-2 v2.2.1" -
TEST CERTIFICATES ON CPS: ANF AC will proceed to approve the new CPS version which clarifies the issue of Test TLS certificates. The new version states that references to test certificates do not apply to SSL/TLS certificate, and that ANF AC does not issue TLS test certificates out of publicly trusted roots. I will indicate here the link to the new CPS version as soon as it is approved and published, as well as change it in CCADB. Please let me know if this is not enough.
-
REVOCATION CHECK INLEDIS.COM: All errors have been solved. There are no errors or warnings. I attach pdf with the revocationcheck page results.
|
|
Reporter | |
Comment 16•6 years ago
|
||
|
|
||
Comment 17•6 years ago
|
||
(In reply to Pablo Díaz from comment #15)
Hello Kathleen. Requested clarifications:
- AUDIT CRITERIA LISTED IN AUDIT STATEMENT: The audit statement, in section "Criteria ETSI applied" includes: Qualified certificate for website authentication (Art. 45 of the eIDAS Regulation and ETSI EN 319 401, ETSI EN 319 411-1 e 411-2). Includes EN 319 411-2 and EN 319 411-2 (Required by Mozilla's Root Store Policy). It includes both as EN 319 411-2 is an extension of part one for EU Qualified TSP issuing qualified certificates. Part 2 includes Part 1 by reference, so auditing against EN 319 411-2 is the same as auditing against both part 1 and 2.
Also, the audit statement includes QCP-w (Qualified Certificate Policy for Website Authentication Certificates).
In "Audit criteria" section, it can be found: "ETSI EN 319 411-1 v1.2.2" and "ETSI EN 319 411-2 v2.2.1"
So "Qualified certificate for website authentication (Art. 45 of the eIDAS Regulation and ETSI EN 319 401, ETSI EN 319 411-1 e 411-2)"
is the same as
"ETSI EN 319 411-2 (QCP-w)" as per
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3122-etsi ?
- TEST CERTIFICATES ON CPS: ANF AC will proceed to approve the new CPS version which clarifies the issue of Test TLS certificates. The new version states that references to test certificates do not apply to SSL/TLS certificate, and that ANF AC does not issue TLS test certificates out of publicly trusted roots. I will indicate here the link to the new CPS version as soon as it is approved and published, as well as change it in CCADB. Please let me know if this is not enough.
That should be OK, since you are only requesting the Websites (TLS) trust bit for this root.
- REVOCATION CHECK INLEDIS.COM: All errors have been solved. There are no errors or warnings. I attach pdf with the revocationcheck page results.
verified
|
|
Reporter | |
Comment 18•6 years ago
|
||
(In reply to Kathleen Wilson from comment #17)
So "Qualified certificate for website authentication (Art. 45 of the eIDAS Regulation and ETSI EN 319 401, ETSI EN 319 411-1 e 411-2)"
is the same as
"ETSI EN 319 411-2 (QCP-w)" as per
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#3122-etsi ?
Yes.
That should be OK, since you are only requesting the Websites (TLS) trust bit for this root.
We proceeded to update the CPS to clarify the non-issuance of SSL TLS test certificates out of publicly trusted roots, in Page 39, section 3.1.2: "References to test certificates do not apply to SSL / TLS certificates. ANF AC does not issue SSL / TLS test certificates out of publicly trusted roots."
This CPS has already been approved and it is published: https://anf.es/pdf/Certification_Practices_Statement_v27.pdf
Shall I update the link in CCADB myself? (it is marked as "Data verified")
|
|
||
Comment 19•6 years ago
|
||
I updated the Case in the CCADB with the link to the updated CPS.
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000501
I am still having difficulty in regards to the audit statement not using the same terminology as in section 3.1.2.2 of Mozilla's Root Store Policy.
I am not finding how the audit statement meets this requirement: "An audit showing conformance with the EVCP policy is required if issuing EV certificates."
|
|
Reporter | |
Comment 20•6 years ago
|
||
Hello Kathleen,
QCP-w, introduced in ETSI EN 319 411-2, (4.2.5 Certificate policy), point 5 says:
"[...] When the certificate is issued to a legal person the requirements for QCP-w include all the EVCP requirements, plus additional provisions suited to support EU qualified certificates issuance and management as specified in Regulation (EU) No 910/2014 [i.1]. "
And QCP-w is developed in ETSI EN 319 412-4, basically requires to follow BRs and EVG for the construction of the certificates.
Also, in the audit statement section "Audit criteria (with version number)"; "Baseline Requirements version 1.6.6" and "EV Guidelines version 1.7.0" are included.
|
|
||
Comment 21•6 years ago
|
||
(In reply to Pablo Díaz from comment #20)
I asked experts about the audit statement (https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/CSQA-Attestation-ANF-2019_1-14862-signed.pdf.aspx?lang=it-IT) and here is their response:
""
Regarding: ANF Audit Attestation of their auditor CSQA
That’s regarded to be buggy in the sense that their auditor did not specify the ETSI policies he has audited the different issuing CA (ICA) for. It’s crucial to clearly say which ICA was defined to issue end entity certs of what ETSI policy and connected herewith, to identify the policy the ICA and all underlying processes and procedures has been audited against. Recommendation: auditor must update AA to clearly state and assign policies.
Apart from that: yes, an audit for ETSI EN 319 411-2 policy QCP-w (cert for legal person) comprises ETSI EN 319 411-1 policy EVCP (see 319 411-2, 4.2.5 5) plus OVR-5.1-03 and OVR-6.8.6-04).
""
|
|
Reporter | |
Comment 22•6 years ago
|
||
(In reply to Kathleen Wilson from comment #21)
Recommendation: auditor must update AA to clearly state and assign policies.
Thank you Kathleen. I have contacted our auditors to request the AA update. As soon as I receive the update I will communicate it in this bug and update the data in CCADB.
|
|
||
Comment 23•6 years ago
|
||
Pablo,
After discussing this with my counterparts, I have learned that the response that I gave in Comment #21 is incorrect...
Mozilla intentionally requires that if you want EV treatment, your audit statement must explicitly state that the audit was also performed according to the EVCP criteria.
Here is Mozilla's opinion: "QCP-w is not the same, because it allows for the issuance of QWACs to LCPs, which EVCP does not allow" (Specifically, see REG-6.2.2-04, which acknowledges QCP-w can be used with LCP, as well as the referenced OVR-5.1-03)
and "QCP-w is not the same, because it doesn't necessarily mean all of the EVCP requirements have been incorporated when they're superseded by a QCP-w requirement"
So please also have your auditor very clearly indicate which TLS related criteria were used in the audit, such as DVCP, OVCP, and/or EVCP.
|
|
Reporter | |
Comment 24•6 years ago
|
||
Hello Kathleen, thank you for your response.
(In reply to Kathleen Wilson from comment #23)
Here is Mozilla's opinion: "QCP-w is not the same, because it allows for the issuance of QWACs to LCPs, which EVCP does not allow" (Specifically, see REG-6.2.2-04, which acknowledges QCP-w can be used with LCP, as well as the referenced OVR-5.1-03)
and "QCP-w is not the same, because it doesn't necessarily mean all of the EVCP requirements have been incorporated when they're superseded by a QCP-w requirement"
With all due respect, I have to contradict this statement "QCP-w allows for the issuance of QWACs to LCPs". There is no "LCP" in REG-6.2.2-04. There is no mention to LCP in EN 319 411-2 due to the fact that LCP does not apply to any EU qualified certificate. Actually, the requirement pointed out (OVR-5.1-03) states:
-If the certificate is issued to a legal person, all requirements defined for EVCP in ETSI EN 319 411-1 [2], shall apply.
-If the certificate is issued to a natural person, all requirements defined for NCP in ETSI EN 319 411-1 [2], shall apply.
(QCP-w is also explained in Section 4.2.5 of EN 319 411-2, point 5).
(In reply to Kathleen Wilson from comment #23)
So please also have your auditor very clearly indicate which TLS related criteria were used in the audit, such as DVCP, OVCP, and/or EVCP.
We will now proceed to ask our auditor to clarify the TLS related criteria used in the audit. As soon as I receive the update I will communicate it in this bug and update the data in CCADB.
|
|
||
Comment 25•6 years ago
|
||
Pablo: I think the confusion is around the fact that QCP-w allows the issuance of certificates to individuals under the QCP-w profile, while the EV guidelines do not permit such issuance. This creates potential issues, for example, if the assessed controls were related solely to the validation of natural persons, or, conversely, if the issuance of QCP-w was done for natural persons (in such a way that EVCP would prohibit).
While it's certainly true that QCP-w attempts to overlay the requirements of EVCP for legal persons, the selective choices within the relevant requirements creates a situation where things forbidden by the EV Guidelines are indirectly permitted by QCP-w. As a consequence, the level of assurance as a consumer of such reports is diminished, which is why the need for explicit assurances that the relevant and appropriate controls were assessed.
Put differently, because QCP-w is more broad than EVCP, it's not sufficient or equivalent to simply accept QCP-w.
|
|
Reporter | |
Comment 26•6 years ago
|
||
Ryan, thank you for the clarification, I agree. We were able to solve it with our auditor and they have already published the Audit Attestation letter with the clarifications corresponding to the TLS criteria.
The link to the AA: https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/CSQA-Attestation_ANF_2019_02_14862-signed.pdf.aspx?lang=it-IT
TLS criteria has been introduced in the last section: "Certificate for website authentication (ETSI EN 319 411-1); Applicabile ETSI policies: DVCP, OVCP and EVCP " and in the policies of the issuing CA of Root ANF Secure Server Root CA.
Kathleen, could you please modify the link in the CCADB case. I am not allowed to update it as the data is already marked as verified.
|
||
Comment 27•6 years ago
|
||
Hello Kathleen,
thank you for asking ETSI ESI for feedback, here is Nick and my answer, coordinated with ACABc Members.
We started a new work item to avoid room for interpretions.
Best regards Arno
Statement A is correct with minor clarification: QCP-w WHEN ISSUED TO LEGAL PERSONS includes all the requirements of EVCP, plus additional requirements. When issued to a natural person it is considered to be outside the scope of CAB Forum and is based on the NCP.
Statement B: is incorrect as QCP-w conformant cannot apply LCP.
Statement C: is partially true. EVCP does not apply to certificates issued to natural persons. PSD2 certificates can currently conform to EVCP as there is currently no conflict between the PSD2 requirements and EVCP but if there is a divergence PSD2 requirements take precedence.
It is recommended that TSPs wishing to issue qualified certificates and conform to CAB Forum EV include both QCP-w and EVCP in the scope of the audit. Thus, your current policy is correct.
|
|
||
Comment 28•6 years ago
|
||
Kathleen: Assigning to you based on Comment #26. I'm not sure which "statement A" / "statement B" / "statement C" is referring to in this issue (I suspect it's related to https://github.com/mozilla/pkipolicy/issues/202 and not this issue), so I think Comment #27 is probably just misdirected.
|
|
||
Comment 29•6 years ago
|
||
Hello,
yes, my comment is related to
https://github.com/mozilla/pkipolicy/issues/202#issuecomment-577860241
Hope it solves the issue
Best regards
arno
|
|
||
Comment 30•6 years ago
|
||
(In reply to Pablo Díaz from comment #26)
The link to the AA: https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/CSQA-Attestation_ANF_2019_02_14862-signed.pdf.aspx?lang=it-IT
TLS criteria has been introduced in the last section: "Certificate for website authentication (ETSI EN 319 411-1); Applicabile ETSI policies: DVCP, OVCP and EVCP " and in the policies of the issuing CA of Root ANF Secure Server Root CA.
Kathleen, could you please modify the link in the CCADB case. I am not allowed to update it as the data is already marked as verified.
The CCADB Case has been updated.
|
|
||
Comment 31•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=00000501
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
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
|
|
Reporter | |
Comment 32•6 years ago
|
||
(In reply to Kathleen Wilson from comment #31)
ignificant 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
I proceed to read the other CP/CPS reviews from that link. Thank you Kathleen.
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 33•5 years ago
|
||
Need updated information regarding audits, CPS, and any subordinate CAs issued by the ANF root CAs.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 34•5 years ago
|
||
(In reply to Ben Wilson from comment #33)
Need updated information regarding audits, CPS, and any subordinate CAs issued by the ANF root CAs.
Updated Audit Attestation can be found here: https://www.csqa.it/getattachment/Sicurezza-ICT/Documenti/Attestazione-di-Audit-secondo-i-requisiti-ETSI/CSQA-Attestation-ANF-2020_12423_V4_Signed.pdf.aspx?lang=it-IT
CPS: https://anf.es/pdf/Certification_Practices_Statement_v28.pdf
PC: https://anf.es/pdf/CP_SSL_Electronic_Headquarters_v3_1.pdf
No new subordinate CA has been issued.
Please let me know if you require any further information,
|
|
Reporter | |
Comment 35•5 years ago
|
||
Both CP and CPS were updated:
CP: https://anf.es/pdf/CP_SSL_Electronic_Headquarters_v3_2.pdf
CPS: https://anf.es/pdf/Certification_Practices_Statement_v29.pdf
|
|
Assignee | |
Comment 36•5 years ago
|
||
ANF CP and CPS Review
CP: https://anf.es/pdf/CP_SSL_Electronic_Headquarters_v3_2.pdf (1.3.6.1.4.1.18332.55.1.1)
Certificate Policy: SSL and Electronic Headquarters, Certification Policy, SSL DV, OV, EV, QWAC and PSD2
CPS: https://anf.es/pdf/Certification_Practices_Statement_v29.pdf (1.3.6.1.4.1.18332.1.9.1.1)
Both dated 10/10/2020
CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2) - Good
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3) - Meh
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”
Page 2 - The second page of the CP/CPS states “This document is the property of ANF Certification Authority - Reproduction and dissemination is prohibited without the express authorization of ANF Certification Authority” This is in conflict with Mozilla’s statement of policy.
Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2) - Good
“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 1.1 of the CP states, “This Certificate Policy (CP) defines the procedural and operational requirements that ANF AC follows for the issuance and management of Publicly-Trusted Certificates; certificates for Secure Server SSL in accordance to Certification Authority/Browser Forum (CA/B Forum) Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificate (herinafter, Baseline Requirements), certificates for Secure Server SSL with Extended Validation in accordance to CA/Browser Forum Guidelines for Extended Validation Certificates (hereinafter, EV Guidelines) and Qualified Web Authentication Certificates (QWAC) in accordance to Regulation (EU) 910/2014 (hereinafter, eIDAS Regulation).”
“Its purpose is to detail and complete what is generically defined in ANF AC’s Certification Practice Statement (OID 1.3.6.1.4.1.18332.1.9.1.1) for this type of certificates and specify the policies ANF AC adopts to meet the current versions of the following policies, guidelines, and requirements: …
The CA/B Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates located at https://cabforum.org/baseline-requirements-documents ,
the CA/B Forum Guidelines for Extended Validation Certificates located at https://cabforum.org/extended-validation , … Mozilla Root Store Policy, ….”
“With regard to SSL/TLS Server Certificates or Code Signing Certificates, if any inconsistency exists between this CP and the requirements and guidelines above, then the CA/B Forum requirements and guidelines above take precedence.”
And the CPS states, “ANF AC conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at https://cabforum.org/baseline-requirements-documents/. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document, as long as these requirements do not contradict legal standards.”
“ANF AC conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificate published at https://cabforum.org/extended-validation/. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document, as long as these requirements do not contradict legal standards.”
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.) - Bad
According to the Baseline Requirements, Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU. A clientAuth EKU is allowed.
ANF’s application for inclusion in the Mozilla trust store is just for the “ANF Secure Server Root CA” with the websites trust bit. Section 1.2.2 of the CP sets forth the policy OIDs for the ANF Secure Server Root CA hierarchy. However, below that root exists the “ANF High Assurance Server CA” with EKUs of ExtKeyUsageServerAuth,ExtKeyUsageClientAuth,ExtKeyUsageCodeSigning. This is problematic. A new intermediate CA should be created that does not have the codeSigning EKU.
Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6) - OK
“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”
While this requirement can be met through entries in the CCADB, a CP or CPS can also include a CA hierarchy chart or a list of CAs that are covered by the CP/CPS.
Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3) - Good
“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.
Both the CP and CPS have a Table of Revisions in Section 1.2.1.
Statement of Non-Delegation for Domain Validation (BR § 1.3.2) - Meh
“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.”
Satisfaction of this requirement is a little unclear. ANF does not expressly state that it does not delegate the task of domain validation to third parties. However, it does say in section 1.3.2 of the CPS, “The only work carried out by its Registration Authorities is the on-site verification of the certificate subscriber and collation of documents, transmitting this documentation to ANF AC for verification and assessment of the documents and circumstances required for the issuance of the electronic certificates requested.” It would be much better if ANF expressly stated that it alone performs the domain validation tasks listed in section 3.2.2.4.
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) – Bad
“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.”
Section 4.9.2 of the CP says, “… Subscribers, Relying Parties, Application Software Suppliers, National Competent Authorities, and other third parties may submit Certificate Problem Reports informing ANF AC of reasonable cause to revoke the certificate.” Section 4.9.3 also provides 24x7 telephone numbers for during and after hours. However, the requirement is that information appear in section 1.5.2 of the CP/CPS.
Section 1.5.2 of the CP/CPS states that Subscribers, Relying Parties, Application Software Suppliers, and other third parties can contact ANF AC by means of the contact person in this section 1.5.2. for reporting suspected Private Key Compromise, Certificate misuse, other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to ANF AC’s Certificates or PKI. However, the contact person’s email address is to a single person’s email address in the Legal Department. It is highly unlikely that this method will be effective. Not only should there be a better email address for this notification of key compromise, but a link to the web site for problem reporting (https://www.anf.es/en/report-breach-misuse/) should appear in section 1.5.2, too.
Naming compliant with X.500, RFC5280 and BRs - Good
The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.
In various places in the CP/CPS, ANF recognizes the need to comply with X.500 and RFC 5280. In section 7.1.4 of the CP it also acknowledges the need to comply with subject naming requirements found in section 7.1.4.2 of the Baseline Requirements and section 9.2 of the EV Guidelines.
No internal names or reserved IP addresses (BR § 7.1.4.2.1) - Good
“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”
Section 3.2.2.4 of the ANF CP states, “ANF AC does NOT issue certificates containing a new gTLD under consideration by ICANN, or an Internal Domain Name.”
ALL certificates must meet Mozilla/BR validation requirements - Good
The CP/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).
The 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 prohibit MITM attacks by ensuring that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious, unauthorized interception of TLS communications by third parties.]
In section 3.2.2.4 of the ANF CP, it adequately describes the BR section 3.2.2.4 methods used: “ANF AC confirms that, prior to issuance, [it] has validated the Fully-Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed in section 3.2.2.4 of the Baseline Requirements, preferably: … (3.2.2.4.2) … (3.2.2.4.4) … (3.2.2.4.15) ….”
“ANF AC does NOT use the retired Validation of Domain methods specified in Section 3.2.2.4.1, Section 3.2.2.4.3, Section 3.2.2.4.5, Section 3.2.2.4.6, Section 3.2.2.4.9, Section 3.2.2.4.10 and Section 3.2.2.4.11 of the CA/B Forum Baseline Requirements. ANF AC does NOT use the method described in Section 3.2.2.4.10 of the Baseline Requirements, as it contains major vulnerabilities.”
CA validates domain part of all e-mail addresses (MRSP § 2.2.2) – Not applicable
“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.”
Not applicable because ANF is not seeking enablement of Mozilla’s secure email trust bit.
Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5) - Good
For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”
Section 4.2.1 of the CP states, “Prior to using any data source as a Reliable Data Source, ANF AC evaluates the source for its reliability, accuracy, and resistance to alteration or falsification. ANF AC takes into consideration the aspects highlighted in section 3.2.2.7 of the Baseline Requirements.”
For EV - “A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis.”
EV verification details appear in section 4.2.1.3 of the CP, including checking information with a QIIS or QGIS.
All information in a certificate must be verified (MRSP § 2.2.1) - Good
“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.”
Section 3.2.4 of the CPS states, “Non-verified information is not included on certificates issued by ANF AC.”
Data reuse (certificate renewal) limited to 825 days (MRSP § 2.1.5) (BR § 4.2.1) - Good
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”.
Section 4.2.1 of the CP states, “ANF AC may reuse previous validations provided that ANF AC obtained the data or document form a source specified under section 3.2 or completed the validation itself no more than 825 days prior to issuing the certificate.”
CAA record checking and recognized domain names in section 4.2 (BR § 2.2) - Good
“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.”
Section 4.2.1 of the CP states, “Prior to issuing a publicly-trusted SSL/TLS Server Certificate, ANF AC checks the DNS for the existence of a CAA record for each dNSName in the subjectAltName extension of the certificate to be issued, according to the procedure in RFC 6844. ANF AC processes the “issue” and “issuewild” property tags. The issuer domain name recognized for ANF AC CAA Record is “anf.es”. If the Certificate is issued, it will be issued within the TTL of the CAA record, or 8 hours, whichever is greater. ANF AC will respect the critical flag and not issue a certificate if ANF AC encounters an unrecognised property with this flag set.”
Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) - Bad
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”.
I was unable to find mention that RA system accounts required multi-factor authentication or similar technical controls.
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”
ANF should implement pre-issuance linting of TBS certificates using common linting tools. This can be mentioned in section 4.3 of the CP/CPS as part of the certificate issuance process.
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2) - Good
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)
As listed in section 4.9.1 of the ANF CP, the revocation reasons and timeframes look fine.
SMIME Reasons for Revocation (MRSP § 6.2) – Not applicable
“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 …”
Not applicable because ANF is not seeking enablement of Mozilla’s secure email trust bit.
CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6) - Good
According to CPS § 4.9.7, ANF AC issues a weekly CRL.
CA must not allow certificate suspension (BR § 4.9.13) - Good
According to CPS § 4.9.13, ANF AC does not authorize temporary suspension of certificates.
OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6) - Good
CPS § 4.10.1 states, “ANF AC, in accordance with the provisions of section 4.9.10. of the Baseline Requirements of CA/B Forum, performs an update of the OCSP request repository with a validity interval greater than or equal to 8 hours, and less than 10 days.
· For OCSP responses with validity intervals less than 16 hours, then ANF AC shall update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.
· For OCSP responses with validity intervals greater than or equal to 16 hours, then ANF AC shall update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than 4 days after the thisUpdate.”
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) - Meh
“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.”
Even though the CP and CPS do not mention a commitment to contact Mozilla or other application software suppliers (browsers) in the event of a private CA compromise or other serious incident, this is a requirement. ANF should ensure that its incident handling procedures include notification of all application software suppliers/vendors.
Also, it would be good to amend section 9.6.1 of the CPS so that Mozilla is included. Currently it says, “All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier.” We would like it to say, “All Application Software Suppliers who have agreed to include its Root Certificate in software distributed by such Application Software Supplier.”
CA must not generate Subscriber key pairs (MRSP § 5.2) - Good
“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”
Section 6.1.2 of the CP states, “ANF AC does NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”
Must meet RSA key requirements (MRSP § 5.1) - Good
Section 6.1.5 of the CP states that key sizes are at least 2048 bits and that end-user certificates are signed with RSA and using SHA-256.
Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1) – Not applicable
Not applicable
Certificate lifetimes limited to 398 days (BR § 6.3.2) - Good
“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”
Section 1.1.1 of the CP provides, “The validity of these certificates can be up to 397 days.”
Network Security (MRSP § 2.1.2) - Meh
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”.
Section 6.7 of the ANF CP only sets forth the following network security controls:
“Controls are implemented to protect the internal network of external domains accessible by third parties. Firewalls are configured to prevent access and protocols that are not required for service operations.
Sensitive data is encrypted when exchanged over non-secure networks (including subscriber registration data).
Ensures that local network components are in secure environments, as well as periodically auditing their configurations.
VPN communication channels are used, and confidential information transmitted over non-secure networks is encrypted using SSL/TLS protocols.”
Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2) - Good
“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”
Section 7.1 of the CPS states that the serial number is a “non-sequential number, greater than zero (0) containing at least 64 bits of output from a CSPRNG.”
EKUs required in end entity certificates (MRSP § 5.2) (BR § 7.1.2.3.f) - Meh
I did not find this specified for end entity certificates in a profile or otherwise. ANF should be aware that for end entity certificates “Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be present.”
Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1) - Good
The ANF CPS adequately addresses this requirement.
Any CN must also be in a SAN (BR § 7.1.4.2.2.a) - Good
Section 7.1.4 of the CP says that the Common Name certificate field is not included. If no CN is included, then this requirement is not applicable. Section 7.1.4.1 of the CP says that for the SAN, “This extension contains at least one entry of a dNSName containing the Fully-Qualified Domain Name.”
|
|
Assignee | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 37•5 years ago
|
||
Thank you Ben for your detailed report. We have just finished reviewing the OK, Meh and Bad observations.
Both CPS and CP have been updated following your recommendations, but won't be published until next monday (November 9), in order to include the new Intermediate CA which will be issued without the CodeSigning EKU.
In this comment I explain the solutions applied (or in the process of being applied) to the issues found.
(In reply to Ben Wilson from comment #36)
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3) - Meh
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”
Page 2 - The second page of the CP/CPS states “This document is the property of ANF Certification Authority - Reproduction and dissemination is prohibited without the express authorization of ANF Certification Authority” This is in conflict with Mozilla’s statement of policy.
In both CP/CPS: Page 2, the following is removed "Reproduction and dissemination is prohibited without the express authorization of ANF Certification Authority" and the following is added "2000 – 2020 CC-BY- ND (Creative commons licenses)"
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.) - Bad
According to the Baseline Requirements, Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU. A clientAuth EKU is allowed.
ANF’s application for inclusion in the Mozilla trust store is just for the “ANF Secure Server Root CA” with the websites trust bit. Section 1.2.2 of the CP sets forth the policy OIDs for the ANF Secure Server Root CA hierarchy. However, below that root exists the “ANF High Assurance Server CA” with EKUs of ExtKeyUsageServerAuth,ExtKeyUsageClientAuth,ExtKeyUsageCodeSigning. This is problematic. A new intermediate CA should be created that does not have the codeSigning EKU.
ANF High Assurance Server CA intermediate has not been used to issue any user certificate. A new intermediate CA without the codeSigning EKU will be issued. I will notify through this forum.
Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6) - OK
“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”
While this requirement can be met through entries in the CCADB, a CP or CPS can also include a CA hierarchy chart or a list of CAs that are covered by the CP/CPS.
I have a doubt about this one. Isn't this coverd with CPS section 1.3.1.1. or the diagram in 1.3.1.2? Should we add any further information?
Statement of Non-Delegation for Domain Validation (BR § 1.3.2) - Meh
“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.”
Satisfaction of this requirement is a little unclear. ANF does not expressly state that it does not delegate the task of domain validation to third parties. However, it does say in section 1.3.2 of the CPS, “The only work carried out by its Registration Authorities is the on-site verification of the certificate subscriber and collation of documents, transmitting this documentation to ANF AC for verification and assessment of the documents and circumstances required for the issuance of the electronic certificates requested.” It would be much better if ANF expressly stated that it alone performs the domain validation tasks listed in section 3.2.2.4.
CP section 3.2.2.3. the following is added: "ANF AC performs the domain validation tasks and does not delegate it to third parties."
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) – Bad
“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.”
Section 4.9.2 of the CP says, “… Subscribers, Relying Parties, Application Software Suppliers, National Competent Authorities, and other third parties may submit Certificate Problem Reports informing ANF AC of reasonable cause to revoke the certificate.” Section 4.9.3 also provides 24x7 telephone numbers for during and after hours. However, the requirement is that information appear in section 1.5.2 of the CP/CPS.
Section 1.5.2 of the CP/CPS states that Subscribers, Relying Parties, Application Software Suppliers, and other third parties can contact ANF AC by means of the contact person in this section 1.5.2. for reporting suspected Private Key Compromise, Certificate misuse, other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to ANF AC’s Certificates or PKI. However, the contact person’s email address is to a single person’s email address in the Legal Department. It is highly unlikely that this method will be effective. Not only should there be a better email address for this notification of key compromise, but a link to the web site for problem reporting (https://www.anf.es/en/report-breach-misuse/) should appear in section 1.5.2, too.
CPS section 1.5.2.1. Revocation Reporting Contact Person has been created containing more details on point of contact for Problem reporting.
Also, the single person's email address in the Legal Department has been replaced by a general address soporte@anf.es
Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) - Bad
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”.
I was unable to find mention that RA system accounts required multi-factor authentication or similar technical controls.
CPS section 1.3.2.1. The following has been added for clarification:
"The process of digitalization and transmission of the application file is made by the "RA Manager" application of ANF AC, which guarantees the security and privacy of information. The RA Manager incorporates the following security measures:
o The RA operator uses a qualified electronic signature certificate issued to them and subject to the RA Certificate Policy, to prove its identity before the program.
o The RA operator uses its qualified electronic signature certificate to authenticate with PAdES LT signature, all the documents associated with the processing of the application it carries out.
o RA Manager verifies the validity of the certificate and that the holder is an operator authorized by ANF AC.
o RA Manager, prior to the acceptance of the transaction, performs validation of the electronic signatures prepared by the RA operator."
CPS section 1.3.2.2. Identity Verification Offices (IVO) - The following has been added for clarification:
"They are equipped with a qualified electronic signature certificate and access to the AR Manager application. They follow the same procedures and apply the same security measures outlined in the previous section."
CP section 4.2.1. Performing identification and authentication functions - The following has been added for clarification
"RRA and IVO function, procedure and security measure applied in the procedures they carry out are in accordance with section 1.3.2 defined in the ANF AC’s CPS."
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”
ANF should implement pre-issuance linting of TBS certificates using common linting tools. This can be mentioned in section 4.3 of the CP/CPS as part of the certificate issuance process.
This was already implemented, but unfortunately was not specified in the documentation.
CP 4.3.1: the following is added: "Prior to issuing the certificate, the issuing system proceeds to validate the certificate format using linting tools: Zlint, x509lint and certlint."
CPS 4.3.1: the following is added: "Prior to issuing the certificate, the issuing system proceeds to validate the certificate format using linting tools."
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) - Meh
“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.”
Even though the CP and CPS do not mention a commitment to contact Mozilla or other application software suppliers (browsers) in the event of a private CA compromise or other serious incident, this is a requirement. ANF should ensure that its incident handling procedures include notification of all application software suppliers/vendors.
Also, it would be good to amend section 9.6.1 of the CPS so that Mozilla is included. Currently it says, “All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier.” We would like it to say, “All Application Software Suppliers who have agreed to include its Root Certificate in software distributed by such Application Software Supplier.”
The PDF form for problem reporting downloaded at https://www.anf.es/en/report-breach-misuse/ specifies:
"In the case of SSL certificates, the subscriber and interested third parties registered in CA/Browser Forum (https://cabforum.org/) will receive the content of the report without the personal data of the reporting entity through their channels established communication (for example, https: // bugzilla.mozilla.org/)."
Should it be included in the CP or CPS as well?
CPS section 9.6.1 the indicated correction has been applied. "All Application Software Suppliers who have agreed to include its Root Certificate in software distributed by such Application Software Supplier.”
Network Security (MRSP § 2.1.2) - Meh
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”.
Section 6.7 of the ANF CP only sets forth the following network security controls:
“Controls are implemented to protect the internal network of external domains accessible by third parties. Firewalls are configured to prevent access and protocols that are not required for service operations.
Sensitive data is encrypted when exchanged over non-secure networks (including subscriber registration data).
Ensures that local network components are in secure environments, as well as periodically auditing their configurations.
VPN communication channels are used, and confidential information transmitted over non-secure networks is encrypted using SSL/TLS protocols.”
In CPS section 6.7. the following has been added "ANF AC conforms to CAB Forum Network Security Guidelines".
ANF AC implements security measures included in the ETSI for QTSPs, ISO 27001 and even PCI DSS, as well as the related specifications of CA/B Forum. No express mention had been made in the public documentation. We expressly include this indication in the CPS.
EKUs required in end entity certificates (MRSP § 5.2) (BR § 7.1.2.3.f) - Meh
I did not find this specified for end entity certificates in a profile or otherwise. ANF should be aware that for end entity certificates “Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be present.”
It is present in the CP section 7.1.2. in the table, "extendedKeyUsage" row. Should we add more information on this?
I will provide the links to the updated CP / CPS and the new intermediate on monday (November 9).
Please let me know if you require any further information.
Pablo Díaz
|
|
Reporter | |
Comment 38•5 years ago
|
||
UPDATED INFORMATION
CP: https://anf.es/pdf/CP_SSL_Electronic_Headquarters_v3_3.pdf (1.3.6.1.4.1.18332.55.1.1)
Certificate Policy: SSL and Electronic Headquarters, Certification Policy, SSL DV, OV, EV, QWAC and PSD2
CPS: https://anf.es/pdf/Certification_Practices_Statement_v30.pdf (1.3.6.1.4.1.18332.1.9.1.1)
Both dated 09/11/2020. Contain the fixed issues indicated in comment #37.
New subordinate CA issued:
- CN: ANF Secure Server CA
- Serial Number: 203079930ae06e7640bF556b
- KeyUsage: keyCertSign, cRLSign and digitalSignature
- EKU: id-kp-serverAuth and id-kp-clientAuth
- SHA1 Fingerprint: 3F:B4:8D:04:5F:B6:A1:9C:14:71:49:FC:10:66:4D:89:E1:17:AD:22
- SHA2 Fingerprint: 30:6B:F8:09:96:36:A4:4F:FF:B5:EE:DC:E6:E3:0C:0F:36:C7:D4:3F:6C:CA:5A:2C:A3:AB:71:66:8F:35:33:20
- Download: http://www.anf.es/es/certificates-download/ANFSecureServerCA.cer
|
|
Assignee | |
Comment 39•5 years ago
|
||
Review of Updated CP and CPS:
https://anf.es/pdf/CP_SSL_Electronic_Headquarters_v3_3.pdf
https://anf.es/pdf/Certification_Practices_Statement_v30.pdf
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3) - Meh
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”
Page 2 - The second page of the CP/CPS states “This document is the property of ANF Certification Authority - Reproduction and dissemination is prohibited without the express authorization of ANF Certification Authority” This is in conflict with Mozilla’s statement of policy.
In both CP/CPS: Page 2, the following is removed "Reproduction and dissemination is prohibited without the express authorization of ANF Certification Authority" and the following is added "2000 – 2020 CC-BY- ND (Creative commons licenses)"
Good
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.) - Bad
According to the Baseline Requirements, Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU. A clientAuth EKU is allowed.
ANF’s application for inclusion in the Mozilla trust store is just for the “ANF Secure Server Root CA” with the websites trust bit. Section 1.2.2 of the CP sets forth the policy OIDs for the ANF Secure Server Root CA hierarchy. However, below that root exists the “ANF High Assurance Server CA” with EKUs of ExtKeyUsageServerAuth,ExtKeyUsageClientAuth,ExtKeyUsageCodeSigning. This is problematic. A new intermediate CA should be created that does not have the codeSigning EKU.
ANF High Assurance Server CA intermediate has not been used to issue any user certificate. A new intermediate CA without the codeSigning EKU will be issued. I will notify through this forum.
Good
Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6) - OK
“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”
While this requirement can be met through entries in the CCADB, a CP or CPS can also include a CA hierarchy chart or a list of CAs that are covered by the CP/CPS.
I have a doubt about this one. Isn't this coverd with CPS section 1.3.1.1. or the diagram in 1.3.1.2? Should we add any further information?
Good - thanks for the clarification
Statement of Non-Delegation for Domain Validation (BR § 1.3.2) - Meh
“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.”
Satisfaction of this requirement is a little unclear. ANF does not expressly state that it does not delegate the task of domain validation to third parties. However, it does say in section 1.3.2 of the CPS, “The only work carried out by its Registration Authorities is the on-site verification of the certificate subscriber and collation of documents, transmitting this documentation to ANF AC for verification and assessment of the documents and circumstances required for the issuance of the electronic certificates requested.” It would be much better if ANF expressly stated that it alone performs the domain validation tasks listed in section 3.2.2.4.
CP section 3.2.2.3. the following is added: "ANF AC performs the domain validation tasks and does not delegate it to third parties."
Good - I see that language in CP section 3.2.2.4
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) – Bad
“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.”
Section 4.9.2 of the CP says, “… Subscribers, Relying Parties, Application Software Suppliers, National Competent Authorities, and other third parties may submit Certificate Problem Reports informing ANF AC of reasonable cause to revoke the certificate.” Section 4.9.3 also provides 24x7 telephone numbers for during and after hours. However, the requirement is that information appear in section 1.5.2 of the CP/CPS.
Section 1.5.2 of the CP/CPS states that Subscribers, Relying Parties, Application Software Suppliers, and other third parties can contact ANF AC by means of the contact person in this section 1.5.2. for reporting suspected Private Key Compromise, Certificate misuse, other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to ANF AC’s Certificates or PKI. However, the contact person’s email address is to a single person’s email address in the Legal Department. It is highly unlikely that this method will be effective. Not only should there be a better email address for this notification of key compromise, but a link to the web site for problem reporting (https://www.anf.es/en/report-breach-misuse/) should appear in section 1.5.2, too.
CPS section 1.5.2.1. Revocation Reporting Contact Person has been created containing more details on point of contact for Problem reporting.
Also, the single person's email address in the Legal Department has been replaced by a general address soporte@anf.es
Good
Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) - Bad
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”.
I was unable to find mention that RA system accounts required multi-factor authentication or similar technical controls.
CPS section 1.3.2.1. The following has been added for clarification:
"The process of digitalization and transmission of the application file is made by the "RA Manager" application of ANF AC, which guarantees the security and privacy of information. The RA Manager incorporates the following security measures:
o The RA operator uses a qualified electronic signature certificate issued to them and subject to the RA Certificate Policy, to prove its identity before the program.
o The RA operator uses its qualified electronic signature certificate to authenticate with PAdES LT signature, all the documents associated with the processing of the application it carries out.
o RA Manager verifies the validity of the certificate and that the holder is an operator authorized by ANF AC.
o RA Manager, prior to the acceptance of the transaction, performs validation of the electronic signatures prepared by the RA operator."CPS section 1.3.2.2. Identity Verification Offices (IVO) - The following has been added for clarification:
"They are equipped with a qualified electronic signature certificate and access to the AR Manager application. They follow the same procedures and apply the same security measures outlined in the previous section."
Good - but there is a typo in the title of this section 1.3.2.2 of the CPS - "OVP"
CP section 4.2.1. Performing identification and authentication functions - The following has been added for clarification
"RRA and IVO function, procedure and security measure applied in the procedures they carry out are in accordance with section 1.3.2 defined in the ANF AC’s CPS."
Good
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”
ANF should implement pre-issuance linting of TBS certificates using common linting tools. This can be mentioned in section 4.3 of the CP/CPS as part of the certificate issuance process.
This was already implemented, but unfortunately was not specified in the documentation.
CP 4.3.1: the following is added: "Prior to issuing the certificate, the issuing system proceeds to validate the certificate format using linting tools: Zlint, x509lint and certlint."
CPS 4.3.1: the following is added: "Prior to issuing the certificate, the issuing system proceeds to validate the certificate format using linting tools."
Good
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) - Meh
“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.”
Even though the CP and CPS do not mention a commitment to contact Mozilla or other application software suppliers (browsers) in the event of a private CA compromise or other serious incident, this is a requirement. ANF should ensure that its incident handling procedures include notification of all application software suppliers/vendors.
Also, it would be good to amend section 9.6.1 of the CPS so that Mozilla is included. Currently it says, “All Application Software Suppliers with whom the Root CA has entered into a contract for inclusion of its Root Certificate in software distributed by such Application Software Supplier.” We would like it to say, “All Application Software Suppliers who have agreed to include its Root Certificate in software distributed by such Application Software Supplier.”
The PDF form for problem reporting downloaded at https://www.anf.es/en/report-breach-misuse/ specifies:
"In the case of SSL certificates, the subscriber and interested third parties registered in CA/Browser Forum (https://cabforum.org/) will receive the content of the report without the personal data of the reporting entity through their channels established communication (for example, https: // bugzilla.mozilla.org/)."Should it be included in the CP or CPS as well?
OK - certificate problem reporting isn't the issue here. One of the early steps in the ANF Business Continuity and Disaster Recovery Plan (BCP/DRP) should say that ANF will contact Mozilla and the other trust stores immediately in the event of a CA compromise. This language doesn't have to be in the CP/CPS if it is in the ANF BCP/DRP. ANF should email "certificates@mozilla.org" and if security is of high concern, then it should file a secure bug (by checking the "Security" check box in Bugzilla - https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS.
CPS section 9.6.1 the indicated correction has been applied. "All Application Software Suppliers who have agreed to include its Root Certificate in software distributed by such Application Software Supplier.”
Good
Network Security (MRSP § 2.1.2) - Meh
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”.
Section 6.7 of the ANF CP only sets forth the following network security controls:
“Controls are implemented to protect the internal network of external domains accessible by third parties. Firewalls are configured to prevent access and protocols that are not required for service operations.
Sensitive data is encrypted when exchanged over non-secure networks (including subscriber registration data).
Ensures that local network components are in secure environments, as well as periodically auditing their configurations.
VPN communication channels are used, and confidential information transmitted over non-secure networks is encrypted using SSL/TLS protocols.”In CPS section 6.7. the following has been added "ANF AC conforms to CAB Forum Network Security Guidelines".
ANF AC implements security measures included in the ETSI for QTSPs, ISO 27001 and even PCI DSS, as well as the related specifications of CA/B Forum. No express mention had been made in the public documentation. We expressly include this indication in the CPS.
Good - thanks
EKUs required in end entity certificates (MRSP § 5.2) (BR § 7.1.2.3.f) - Meh
I did not find this specified for end entity certificates in a profile or otherwise. ANF should be aware that for end entity certificates “Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present. The value anyExtendedKeyUsage MUST NOT be present.”
It is present in the CP section 7.1.2. in the table, "extendedKeyUsage" row. Should we add more information on this?
Good - thanks
|
|
Assignee | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 40•5 years ago
|
||
Thank you for your review.
(In reply to Ben Wilson from comment #39)
Good - but there is a typo in the title of this section 1.3.2.2 of the CPS - "OVP"
Yes, OVP is IVO in spanish. It has been fixed and will be published.
OK - certificate problem reporting isn't the issue here. One of the early steps in the ANF Business Continuity and Disaster Recovery Plan (BCP/DRP) should say that ANF will contact Mozilla and the other trust stores immediately in the event of a CA compromise. This language doesn't have to be in the CP/CPS if it is in the ANF BCP/DRP. ANF should email "certificates@mozilla.org" and if security is of high concern, then it should file a secure bug (by checking the "Security" check box in Bugzilla - https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS.
I understand. Contact with Mozilla and other trust stores in the event of CA Compromise is covered in the BCP/DRP. Also have an internal procedure document "Responding to an Incident SSL" with OID 1.3.6.1.4.1.18332.99.2 with the detailed procedure to follow with respect to Mozilla and other trust stores in case of incident or certificate misissuance, which was elaborated taking into account Mozilla's guidelines https://wiki.mozilla.org/CA/Responding_To_An_Incident.
|
|
Reporter | |
Comment 41•5 years ago
|
||
Please find attached the updated BR Self Assessment for ANF Autoridad de Certificación (ANF AC).
|
|
Reporter | |
Comment 42•5 years ago
|
||
|
|
Reporter | |
Comment 43•5 years ago
|
||
To clarify. The intermediate CA used to issue certificates for the Test Websites was created (see comment #38) on Nov 9th 2020: "ANF Secure Server CA" https://crt.sh/?id=3946194886
Current test websites are:
- Valid: https://testvalidsslev.anf.es
- Expired: https://testexpiredsslev.anf.es
- Revoked: https://testrevokedsslev.anf.es
As stated in comment #37, the Intermediate CA “ANF High Assurance Server CA” (issued sep 5, 2019) has not been used to issue any user certificate (as stated also in CPS 1.3.1.2), only the certificates for the first test websites, which are no longer valid. “ANF High Assurance Server CA” ICA was revoked, lastCRL was issued in accordance to ETSI EN 319 411-2. The ARL can be found at: http://crl.anf.es/crl/ANFSecureServerRootCA-arl.crl
This information is also updated in CCADB. They Key destruction is postponed for an external auditor to come to our data center to witness the key destruction ceremony. A key destruction ceremony minute will gather the evidence and will be handed to our eIDAS auditor in our upcoming eIDAS Audit.
|
|
Assignee | |
Comment 44•5 years ago
|
||
Public discussion of this CA's inclusion request began on 10-March-2021 and is scheduled to close on 31-March-2021.
https://groups.google.com/g/mozilla.dev.security.policy/c/MLyRWsLHAdA/m/KN6g4GydBwAJ
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 45•4 years ago
|
||
Public discussion closed today https://groups.google.com/g/mozilla.dev.security.policy/c/MLyRWsLHAdA/m/znDuQRiEBwAJ and notice of last-call provides a period until April 8, 2021, and I am recommending that ANF's CA be approved for inclusion for websites and as an EV root CA.
|
|
||
Comment 46•4 years ago
|
||
As per Comment #45, and on behalf of Mozilla I approve this request from Autoridad de Certificación (ANF AC) to include the following root certificate:
** ANF Secure Server Root CA; (Websites); EV
I will file the NSS and PSM bugs for the approved changes.
|
|
||
Comment 47•4 years ago
|
||
I have filed bug #1703942 against NSS and bug #1703944 against PSM for the actual changes.
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 48•2 years ago
|
||
Description
•