Public Discussion re: Inclusion of the TunTrust Root CA
Ben Wilson
This is to announce the beginning of the public discussion phase of the Mozilla root CA inclusion process for the TunTrust Root CA. See https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 through 9).
The TunTrust Root CA is operated by Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA).
This current CA inclusion application has been tracked in the CCADB and in Bugzilla–
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000499
https://bugzilla.mozilla.org/show_bug.cgi?id=1587779
This new root CA certificate is valid from 2019 to 2044, and it is proposed for inclusion with the websites bit (for OV certificates issued to entities under the ccTLD ".tn").
Mozilla is considering approving ANCE/NDCA’s request. This email begins the 3-week comment period, after which, if no concerns are raised, we will close the discussion and the request may proceed to the approval phase (Step 10).
Root Certificate Information:
TunTrust Root CA
crt.sh –
https://crt.sh/?q=2E44102AB58CB85419451C8E19D9ACF3662CAFBC614B6A53960A30F7D0E2EB41
Download –
http://www.tuntrust.tn/pub/TnTrustRootCA.pem
CP/CPS:
Current CPS is Version 4.5 / December 2, 2020
https://www.tuntrust.tn/sites/default/files/Ressources/CPCPS-TunTrustPKI.pdf
Repository location:
https://www.tuntrust.tn/repository
TunTrust's 2021 BR Self-Assessment (Excel) is located here:
https://bugzilla.mozilla.org/attachment.cgi?id=9203908
Audits:
TunTrust’s WebTrust auditor is Deloitte, and the most recent audit reports are dated 12/15/2020. These may be downloaded by clicking on the WebTrust seals at the bottom of TunTrust’s repository page.
Incidents:
In September 2020, TunTrust filed Bugzilla Bug #1663953 representing a 20-hour period during which OCSP was unreachable due to human error while executing a patch management script that deleted the OCSP VM. Remedial measures are in progress, including the hiring of a third party for patch management, which should be completed this month. For more details, see Bug Comment #9.
No misissuances were found under the TunTrust Root CA and the TunTrust Services CA (issuing CA) appears to be properly formatted. Here are the name constraints (marked critical) for the TunTrust Services CA:
Permitted: DNS: tn; DirName: C = TN
Excluded: IPv4: 0.0.0.0/0.0.0.0; IPv6: 0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
Thus, this email begins a three-week public discussion period, which I’m scheduling to close on or about 30-April-2021.
A representative of TunTrust must promptly respond directly in the discussion thread to all questions that are posted.
Sincerely yours,
Ben Wilson
Mozilla Root Program
Ryan Sleevi
Is the intent that those constraints should be respected by applications?
Just noting that nameConstraints on roots are not widely supported. I believe Mozilla added support previously in response to HARICA, although ultimately HARICA ended up removing those constraints. For purposes of this discussion, should it be reasonable to evaluate TunTrust "as if" it was an unconstrained CA, since for all intents and purposes, for the majority of Internet users, that's exactly how they will be?
Ben Wilson
Ryan Sleevi
TunTrust Services CA: This issuing CA is restricted to only issue OV SSL certificates to domain names- under “.tn” top-level domain and owned by entities operating under the Tunisian Jurisdiction.
Matthew Hardeman
Ben Wilson
Is TunTrust applying with the intention of being name constrained to the .tn name space of their own volition or is this an agreed/negotiated constraint as a mitigating factor for other uncertainties or non-compliances?
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/3c4f4ae7-810b-4a71-9289-9441530fc908n%40mozilla.org.
Matthew Hardeman
Andrew Ayer
Ben Wilson <bwi...@mozilla.com> wrote:
> *CP/CPS:*
> Current CPS is Version 4.5 / December 2, 2020
>
> https://www.tuntrust.tn/sites/default/files/Ressources/CPCPS-TunTrustPKI.pdf
"TunTrust may not check CAA records for the following exceptions: [...]
If the CA or an Affiliate of the CA is the DNS Operator (as defined in
RFC 7719) of the domain's DNS."
This exception has proven problematic in practice
<https://bugzilla.mozilla.org/show_bug.cgi?id=1670337>. To assure
the community that TunTrust has implemented this exception correctly,
could they please explain in detail how they determine that they or an
affiliate are the DNS Operator for a domain? The answer should contain
enough detail for another CA to independently implement it, and include
details like DNS queries made, DNS servers used, how DNS responses are
interpreted, etc.
Regards,
Andrew
Matthew Hardeman
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20210407163437.09090c4451f7299457acc216%40andrewayer.name.
Syrine Tlili
According to our Tunisian regulation, we are not authoritative on “.tn” domain and we are prevented by law to be authoritative, as DNS activity does not fall into our activity scope defined by law.
We are automatically checking the CAA records for all the certificate requests equally. We do not have affiliates and the only DNS operator in Tunisia is the «Agence Tunisienne d’Internet» (https://www.ati.tn/ ; https://whois.ati.tn/ ). Exception on checking CAA records does not apply to us.
The CT logs bring evidence that we are not restricting organizations in the Tunisian Jurisdiction from having their SSL certificates from other CAs (the best example is our website, our SSL certificate was purchased from a CA that is already included in the Mozilla and Chrome trust stores). We are also not restricting organizations in the Tunisian jurisdiction from purchasing SSL certificates with domain names other than “.tn” (for instance : .com). We never imposed to Tunisian citizens and entities to manually add our Root CA certificates to their browsers and software.
In regards to our investment into compliance, both initial and ongoing, we have shown that we spare no money and no effort to reach compliance with BR, Mozilla Policy, and Webtrust requirements.
Being ISO 27001 and ISO 9001 certified since 2018, we are applying a PDCA approach that requires a continuous improvement of our processes and services. As evidence, we did not delay to do the necessary investment in response to the OCSP incident that we reported in bug 1663953. We provided timely report to the community and we are thoroughly following an action plan to remediate to the incident. We are now in the process of preparing the ISO 22301 v2019 certification related to business continuity management as part of improving our services (especially after the above mentioned incident).
I also would like to highlight that our budget and expenditures are regularly being supervised and controlled by supervising entities. Being a government entity does not allow us to operate with no accountability and no follow-up on goal achievement. I also do clearly confirm that being trusted by main root policy programs is one of our main strategic objectives.
Andrew Ayer
Syrine Tlili <syrine...@tuntrust.tn> wrote:
> We are automatically checking the CAA records for all the certificate
> requests equally. We do not have affiliates and the only DNS operator
> in Tunisia is the «Agence Tunisienne
> d’Internet» (https://www.ati.tn/ ; https://whois.ati.tn/ ). Exception
> on checking CAA records does not apply to us.
checking. If this is not accurate, it should be updated.
Regards,
Andrew
Syrine Tlili
Ben Wilson
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/3b85ce38-7809-49ff-a2a3-1a9c2a936c30n%40mozilla.org.
Syrine Tlili
Hi All :
We would like to move forward with our inclusion request in public discussion since April 7th 2021. Based on the public discussion thread [1] and on the new section “CA/Quantifying Value” [2], we have submitted a document in our Bugzilla case [3] that provides answers and clarifications on our CA.
[1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/LT_5efOFsSU
[2] https://m.wiki.mozilla.org/CA/Quantifying_Value
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1587779
Ben Wilson
Watson Ladd
All,TunTrust has provided an overview of its compliance infrastructure, which I have reviewed. See https://bugzilla.mozilla.org/attachment.cgi?id=9226817. I'm now asking the community for further comments and responses to TunTrust's inclusion request.
Syrine Tlili
Ben Wilson
HiWe added a document with more details on TunTrust CA budget. See
You received this message because you are subscribed to a topic in the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this topic, visit https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/dTTp4ZfUW34/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/54f7f7c8-0c5f-403f-bfa1-5a82e7718cbdn%40mozilla.org.
Syrine Tlili
Ben Wilson
Ben Wilson
All,
For your review, here is my own, abridged version of TunTrust’s value justification.
See https://wiki.mozilla.org/CA/Quantifying_Value and https://bugzilla.mozilla.org/attachment.cgi?id=9226817 .
Ownership and Management Structure
The beneficial owner of the TunTrust Root CA is the Agence Nationale de Certification Electronique (“ANCE”) under the Ministry of Communication Technologies of Tunisia pursuant to Law no. 2000-83 of 9 August 2000.
Tunisian Ministry of Communications Technologies
|
ANCE Board of Directors (TunTrust)
|
ANCE Director-General
| | |
Audit and Risk Analysis Department IMS Department Technical Department
|
Engineers (conduct continuous monitoring, compliance, risk assessment, etc. and report to Board of Directors)
ANCE (TunTrust) implements and maintains an Integrated Management System (IMS) that complies with ISO 9001 and ISO 27001. The IMS design is based on a Plan-Do-Check-Act (PDCA) approach to ensure continuous improvement of compliance and incident management processes to meet security, quality and compliance requirements.
CA Hierarchy Highlights
· TunTrust Services CA: This issuing CA is restricted to only issue OV SSL certificates to domain names under “.tn” top-level domain and owned by entities operating under the Tunisian Jurisdiction.
· TunTrust Qualified CA: This issuing CA is technically constrained to prevent issuance of SSL- certificates.
· Starting June 2022: Issuing S/MIME certificates in compliance with the currently-in-progress CA/B Forum S/MIME Baseline Requirements. S/MIME certificates would be used on Tunisian national platforms: e-banking services, e-gov services, e-health, etc.
· Starting June 2023: Issuing SSL Certificates with no constraints on the top-level domain name, nor on the entity's jurisdiction starting June 2023.
Budgeting
TunTrust's budget document is uploaded here: https://bugzilla.mozilla.org/attachment.cgi?id=9228562
It's annual compliance budget is determined based on:
· The compliance plan derived from the continuous risk assessment;
· Action plans derived from external and internal audit reports;
· Resources identified by each department of TunTrust that are required to achieve compliance and to maintain and improve the TunTrust IMS; and
· As new technology becomes available, the possibility of introducing it to improve the efficiency and security of the IMS is to be considered.
The compliance annual budget is validated by the board of directors and then approved by the Ministry. TunTrust holds monthly follow-up meetings to prevent forecast deviation and ensure enough budget allocation in case of unforeseen compliance issues. The annual budget can be updated in case of urgent compliance issues, and TunTrust indicates that it and its Board are willing to allocate the necessary budget in a timely manner to quickly address compliance incidents (prevention and/or remediation actions).
CA System
TunTrust uses Primekey EJBCA Enterprise Solution, with a subscription to professional support and maintenance to keep its CA updated and compliant with audit and policy requirements. Hardware and software are purchased with vendor support and maintenance services to have access to the latest stable releases and security patches. TunTrust's continuous investment plan is to improve its infrastructure through maintenance services and procurement strategies to acquire new hardware/software aiming at improving the efficiency and security of the IMS. All systems and equipment that would be in End-of Life or End-of-Support states are substituted with upgraded versions or newer equipment.
Personnel
Key TunTrust personnel appear to have sufficient PKI domain experience and system and security training.
Individuals in trusted roles receive regular training on evolving technologies and changes to audit frameworks and requirements (WebTrust, CA/B Forum, Mozilla Security Policy, ISO 9001 and ISO 27001). TunTrust also conducts an annual security awareness program.
Annual risk assessments evaluate the strength of the compliance team in terms of numbers and expertise.
Compliance
TunTrust uses PDCA/continuous improvement, change management processes, and a watch process.
As evidence of its proactive approach to compliance, TunTrust omitted the OU field from its OV SSL Certificate Profile in advance of CABF Ballot SC47.
With respect to the documented watch procedure, engineers from the Audit and Risk Analysis Department are formally designated to regularly report to the Board of Directors about any potential compliance issue or newly adopted approaches that they might find about while following:
· Discussions in Mozilla's dev-security-policy forums (the previous and the current ones);
· Updates to the Mozilla root store policy (starting from the discussions on the draft on Github);
· Mozilla Incident Dashboard - CA incidents and misissuance reports;
· Discussions in the Working Groups and Subcommittees of the CA/B Forum - subscribed to the mailing lists of the SCWG, the Validation list, the Public list, the NetSec list and the Infrastructure list;
· New ballots from the state of “Under Consideration” to the “Review Period” of the Guidelines;
· The CT logs group, https://groups.google.com/g/certificate-transparency;
· Chromium CT policy and Certificate Transparency Logs that are recognized by Chromium, https://cs.chromium.org/chromium/src/components/certificate_transparency/data/log_list.json;
· Updates to linting tools (zlint, cablint, certlint);
· Updates to Microsoft Root Store Policy Program Requirements and Audit Requirements;
· Updates to the WebTrust Principles and Criteria on the website of CPA Canada;
· Updates to the ETSI standards on the etsi.org website;
· Updates to the ISO 9000 and 27000 series on the iso.org website.
Engineers from the Technical Department and from the Audit and Risk Analysis Department are formally designated to regularly report to the Board of Directors about any technical updates and new recommendations in the PKI and Information Security industries that may impact its systems.
Automation
As part of its continuous infrastructure development strategy, automated security and compliance controls are continuously enforced in addition to real-time monitoring and alerting systems. TunTrust has implemented automation in its systems and equipment, such as:
· Automated monitoring systems that detect configuration changes and alerts administrators in real-time of these changes;
· Automated systems that monitor system and equipment performance (CPU, RAM, disk space, etc.) and alerts administrators in real-time of any problems;
· Control over Certificate Attributes to conform to the CA/B Forum Baseline Requirements (such as prohibiting the underscore character, etc.);
· Automated Patch Management for Windows systems (Ongoing automation for RedHat systems, refer to incident bug);
· System and network audit logging process, backup and recovery, and IT asset inventorying;
· Pre-configured EJBCA Validators: CAA Checking, Black List Checking and Weak key Checking; and
· Lint Checking: TunTrust uses zlint, cablint and certlint as linting tools before Certificate Issuance.
Risk Assessment
TunTrust’s risk assessment is updated annually (as part of the annual compliance program) and before implementing major changes (new platforms, major updates to systems, physical and environmental changing factors, etc.). It includes strategic and operational risks. The risk assessment and risk mitigation plan are reviewed by independent auditors in the context of audits performed. TunTrust maintains and regularly (at least annually and before major changes) updates its risk assessment using ISO 27005 for risk management. Per the ISO 27001 audit, TunTrust is required to justify all decisions taken to deal with the identified risks.
Audits and Assessments
TunTrust undergoes:
· WebTrust Audits since 2019;
· ETSI audits since 2015;
· ISO audits since 2015;
· An annual information security audit as mandated by the Tunisian National Law. This mandatory audit includes a technical audit (vulnerability scan, internal and external pentesting, etc.), an organizational audit (in accordance with the ISO 27001 standard) and a risk assessment (in accordance with the ISO27005 standard); and
· Internal audits of systems and processes in accordance with compliance requirements.
Summary
In summary, TunTrust has:
· a regularly reviewed risk assessment that covers operational risks;
· automated monitoring systems that detect changes to configuration files and other security events and send real-time alerts;
· security and quality metrics that are controlled through periodic self-audits, vulnerability scans and internal and external penetration tests; and
· automation and minimized human actions on systems where possible.
Based on my reading of TunTrust's value justification, it appears that we should move forward with approving TunTrust's application for CA inclusion. I look forward to any additional comments.
Sincerely yours,
Ben
Ben Wilson
On April 7, 2021, we began public discussion[1] on the TunTrust root CA inclusion request[2] (Step 4 of the Mozilla Root Store CA Application Process[3]).
Summary of Discussion and Completion of Action Items [Application Process, Steps 5-8]:
Initially, there was a question whether name constraints would be placed on the TunTrust Root CA for the .tn ccTLD. There was uncertainty on exactly how this would be addressed and concern expressed that government-operated, name-constrained CAs present risk and limited value to Mozilla users, as expressed by comments in this thread: [4].
TunTrust clarified that the “TunTrust Services CA … is restricted to only issue OV SSL certificates to domain names under “.tn” top-level domain and owned by entities operating under the Tunisian Jurisdiction” until June 2023, when there would be no constraints based on the top-level domain name or an entity’s jurisdiction.[5]
As to government-operated CAs, Mozilla has allowed them historically. They have unique challenges in dealing with local regulations and requests. Still, we require that such CAs always maintain secure, independent, and compliant operations--including taking timely action to ensure compliance, providing transparency, and engaging in good communication.
Another comment expressed concern that TunTrust did not intend to check CAA records when TunTrust or an affiliate was the DNS Operator (as defined in RFC 7719) of the domain's DNS. As a result, TunTrust published version 4.7 of its CPS[6] to remove such statement. Also, as of July 1, 2021, the Baseline Requirements have removed this exception to CAA checking.[7]
Based on other comments about the TunTrust application, Mozilla conducted a separate discussion on “Quantifying the Value of Adding a New CA”[8], and we published a new wiki page, “CA/Quantifying Value” in which we state, “The applicant must present an explanation of the benefits to our users so that the community can identify, measure, value, and understand the benefits of including the root certificate and determine whether it is worth the risk of including it.”[9]
TunTrust submitted a value justification[5] and an operating budget[10], which I have reviewed, summarized, and found satisfactory.[11] I do not have any further questions, and I do not believe that there are any remaining action items.
This is notice that I am closing public discussion (Application Process, Step 9) and that it is Mozilla’s intent to approve this request for inclusion (Step 10).
This begins a 7-day “last call” period for any final objections.
Thanks,
Ben
[1] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/dTTp4ZfUW34/m/xfK1LQXSBQAJ
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1587779
[3] https://wiki.mozilla.org/CA/Application_Process
[4] https://groups.google.com/g/mozilla.dev.security.policy/c/tr_PDVsZ6-k/m/5CBRufpOZZAJ
[5] https://bugzilla.mozilla.org/attachment.cgi?id=9226817
[6] https://www.tuntrust.tn/sites/default/files/Ressources/CPCPS-TunTrustPKI.pdf
[7] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.7-redline.pdf
[8] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/LT_5efOFsSU
[9] https://wiki.mozilla.org/CA/Quantifying_Value
[10] https://bugzilla.mozilla.org/attachment.cgi?id=9228562
[11] https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/dTTp4ZfUW34/m/0FN9hAYkAgAJ