Public Discussion re: Inclusion of the TunTrust Root CA

488 views
Skip to first unread message

Ben Wilson

unread,
Apr 7, 2021, 2:47:10 PMApr 7
to dev-secur...@mozilla.org

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

unread,
Apr 7, 2021, 3:00:32 PMApr 7
to Ben Wilson, dev-secur...@mozilla.org
Ben:

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

unread,
Apr 7, 2021, 3:47:14 PMApr 7
to Ryan Sleevi, dev-secur...@mozilla.org
Even though the name constraints were not implemented in the root CA certificate, but in the intermediate CA certificate, I anticipate that Mozilla will apply the Tunisia country constraints on the root separately.  I mentioned the name constraints in the intermediate CA to alert everyone to the fact that TunTrust had implemented name constraints in that fashion.  So the Mozilla community should assume that this will be a technically constrained root CA.  I should have made that more clear.

Ryan Sleevi

unread,
Apr 7, 2021, 4:09:21 PMApr 7
to Ben Wilson, Ryan Sleevi, dev-secur...@mozilla.org
Thanks for clarifying Ben.

It's not clear from the related bug [1] or Root Case [2] the role in which this CA will "provide some service relevant to users of our software products;" [3]. As noted within their request for inclusion, the closest statement is as follows:
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.

This seems to present and limited value to, and post unnecessary risk to, Mozilla users, at least based on past discussions [5] on government-operated, name-constrained CAs. Further, the restriction of issuance to OV certificates seems like it introduces significant risk of compliance issues, judging by Mozilla's own past investigations [6]. It's well known, for example, that the inclusion of organization data can create significant risk to agility, both in terms of individual certificates and CA migrations, so the choice to restrict to OV only seems like it introduces additional risk to Mozilla users. Understandably, that's an intrinsic requirement of the stated purpose ("owned by entities operating under the Tunisian Jurisdiction"), but that seems to present challenges.

In the past, we've seen CAs with limited target audiences be significant sources of compliance issues [7] [8] [9], as their narrow focus (e.g. constrained to a small set of users or a single organization) discourages the necessary investment into compliance, both initial and ongoing. I didn't see any response to this effect in the inclusion request, but I'm curious if this has been part of any consideration so far, to understand the risk? I totally understand and appreciate all CAs start small, but the barrier for inclusion-by-default within a given product seems to be weighted by the risk to the product's users versus the potential benefit to those users, and it's not quite clear with the narrow focus, technical constraints, and intentional lack of agility how that brings benefit to Mozilla users.

If the assumption of risk is based on the existence of nameConstraints, does that mean Mozilla would consider including as a root CA CAs that are constrained to a single organization domain name? If not, it may be useful contemplating where that line is, since it's not clear how this situation would be much more distinct.

While I totally plan to continue to dive deeper, I thought it relevant to highlight these past data points, since they seem relevant to the conversation as part of the considerations.

Matthew Hardeman

unread,
Apr 7, 2021, 4:12:47 PMApr 7
to dev-secur...@mozilla.org, dev-secur...@mozilla.org
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?

Ben Wilson

unread,
Apr 7, 2021, 4:15:45 PMApr 7
to Matthew Hardeman, dev-secur...@mozilla.org
Matthew,
I believe it is the former - the request has been of TunTrust's own volition. At least I haven't been in any negotiations with them.
Ben


On Wed, Apr 7, 2021 at 2:12 PM Matthew Hardeman <mhar...@gmail.com> wrote:
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

unread,
Apr 7, 2021, 4:23:11 PMApr 7
to Ben Wilson, dev-secur...@mozilla.org
Interesting.  I understand they intend to scope their practice to issuance for in-nation entities subject to their jurisdiction, but it seems strange to preemptively request what amounts to a significant barrier to subscriber base development/growth.  Do the entities they intend to serve never hold or manage domains outside the .tn scope?

I'm perplexed as to why a new applicant would seek extra existential challenges without an understanding of benefit in exchange.

Andrew Ayer

unread,
Apr 7, 2021, 4:34:40 PMApr 7
to dev-secur...@mozilla.org
On Wed, 7 Apr 2021 12:46:56 -0600
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

Section 4.2.4 states:

"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

unread,
Apr 7, 2021, 4:45:38 PMApr 7
to Andrew Ayer, dev-secur...@mozilla.org
If they actually are the government of Tunisia, and all the issuance will be in the .tn name space, and that rule will be technically constrained, aren't they, in effect, definitionally authoritative for all possible domain labels inside .tn?

--
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.

Syrine Tlili

unread,
Apr 8, 2021, 11:34:54 AMApr 8
to dev-secur...@mozilla.org, mhar...@gmail.com, dev-secur...@mozilla.org, Andrew Ayer
Hi:
To provide more clarification, there are no name constraints on the Root CA, we actually constrained our issuing sub-CA to the ".tn" ccTLD and Tunisian entities. Our intent is to be able to build up new sub-CAs with no restrictions in a step-by-step approach towards establishing confidence in our Root CA. This restriction has been implemented in the scope of a progressive approach that we follow to start small and then scale safely.

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.


Syrine Tlili

Andrew Ayer

unread,
Apr 8, 2021, 11:36:19 AMApr 8
to Syrine Tlili, dev-secur...@mozilla.org
On Thu, 8 Apr 2021 08:20:58 -0700 (PDT)
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.

Your CPS currently lists three exceptions where you might skip CAA
checking. If this is not accurate, it should be updated.

Regards,
Andrew

Syrine Tlili

unread,
Apr 15, 2021, 4:48:17 AMApr 15
to dev-secur...@mozilla.org, Andrew Ayer, dev-secur...@mozilla.org, Syrine Tlili
Hi:

This section on  CAA checking exceptions is now updated in our CP/CPS.

Regards,
Syrine Tlili   

Ben Wilson

unread,
Apr 20, 2021, 2:20:45 PMApr 20
to dev-secur...@mozilla.org
All,
Kathleen and I discussed iTrusChina's and TunTrust's root inclusion applications this morning and agreed that we should extend the public discussion period and leave them open for discussion beyond April 30th. Meanwhile, I will work on follow-up questions for them regarding their added value to users vs. added risk.
Thanks,
Ben

--
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.

Syrine Tlili

unread,
Jun 14, 2021, 10:21:36 AM (4 days ago) Jun 14
to dev-secur...@mozilla.org, bwi...@mozilla.com

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

Reply all
Reply to author
Forward
0 new messages