1587779 - Add TunTrust Root CA root certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task, P3)

Description

[syrine.tlili]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Comment 1

[syrine.tlili]

Attachment: TunTrust Root CA's BR Self Assessment.xlsx

Comment 2

[syrine.tlili]

Attachment: ANCE_TunTrust_RKGC_Audit_Report_26_April_2019.pdf

Comment 3

[syrine.tlili]

Attachment: ANCE_TunTrust_Webtrust_for_CA_BR_SSL_and_Network_Security_Point_in_Time_Audit_30_April_2019.pdf

Comment 4

[syrine.tlili]

Attachment: ANCE_TunTrust_Webtrust_for_CA_Point_In_Time_Audit_30_April_2019.pdf

Comment 5

[syrine.tlili]

Agence Nationale de Certification Electronique of Tunisia wants to request for the inclusion of our new root certificate, namely TunTrust Root CA, to be included in Mozilla Root Store.

The audit case for the new Root inclusion request is in CCADB
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000499

We have held a key generation ceremony (KGC) regarding our new Root CA, TunTrust Root CA, and internally operated Subordinate CAs. The new PKI hierarchy is as follows :
TunTrust Root CA: root-signing all TunTrust issuing CAs and kept offline
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.

We have completed a point-in-time audit performed in accordance with applicable standards under WebTrust scheme and a KGC audit used to ensure the integrity and confidentiality of the key pairs.
We provide you the download links of the related audit reports which can be found from the following links:
WebTrust for CA point-in-time audit report
https://www.tuntrust.tn/sites/default/files/Ressources/ANCE_TunTrust_Webtrust_for_CA_Point_In_Time_Audit_30_April_2019.pdf
WebTrust for CA-SSL BR and Network Security point-in-time audit report
https://www.tuntrust.tn/sites/default/files/Ressources/ANCE_TunTrust_Webtrust_for_CA_BR_SSL_and_Network_Security_Point_in_Time_Audit_30_April_2019.pdf
Audit report of Root & Sub Key Generation Ceremony
https://www.tuntrust.tn/sites/default/files/Ressources/ANCE_TunTrust_RKGC_Audit_Report_26_April_2019.pdf

We have also completed a period-of-time audit performed in accordance with applicable standards under WebTrust scheme for TunTrust Root CA for the period from 30 April 2019 to 30 September 2019 . We will provide you with the related audit reports once received from auditors.

This new bug is related to our previous bug 1233645 where you have recommended the generation of a new root CA for inclusion in Mozilla Trusted Store.

Best Regards

Syrine Tlili
Agence Nationale de Certification Electronique
https://www.tuntrust.tn

Comment 6

[Kathleen Wilson]

Syrine, Thank you for creating a new root inclusion case and this new Bugzilla bug. This is on my to-do list to review, but I have a backlog of such work. I will add a comment to this bug when I do the review.

Comment 7

[Kathleen Wilson]

The information for this root inclusion request is here:

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000499

Root Case Record # 1
Subject: CN=TunTrust Root CA; O=Agence Nationale de Certification Electronique; C=TN
Issuer: CN=TunTrust Root CA; O=Agence Nationale de Certification Electronique; C=TN
Valid From: 2019 Apr 18
Valid To: 2044 Apr 18
Certificate Serial Number: 27B4BD1D08289F6D78E2CEDCEEF25DCA3A702990
SHA-256 Fingerprint: BABBCA986946352CF9BF382E880652F4E94DBC4FEDD0F1CC21FA9973C96D65AB
Signature Hash Algorithm: SHA256WithRSA
Public Key Algorithm: RSA 4096 bits

Root Case Record # 2
Subject: CN=TunTrust Root CA; O=Agence Nationale de Certification Electronique; C=TN
Issuer: CN=TunTrust Root CA; O=Agence Nationale de Certification Electronique; C=TN
Valid From: 2019 Apr 26
Valid To: 2044 Apr 26
Certificate Serial Number: 1302D5E2404C92468616675DB4BBBBB26B3EFC13
SHA-256 Fingerprint: 2E44102AB58CB85419451C8E19D9ACF3662CAFBC614B6A53960A30F7D0E2EB41
Signature Hash Algorithm: SHA256WithRSA
Public Key Algorithm: RSA 4096 bits

Syrine, Please explain the difference between the two "TunTrust Root CA" certificates (Root Case Records #1 and #2), and why you are requesting inclusion for both of them.

Comment 8

[syrine.tlili]

Hi Kathleen,

The Root Case Record # 1 was issued on 2019 Apr 18 with the following key usage : Digital Signature, Certificate Sign and CRL Sign.
According to section 7.1.2.1. of the CA/Browser Forum Baseline Requirements « If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set. » and in our case the Root CA will not sign OCSP response.
Hence, our auditor who witnessed the KGC recommanded to issue the root certificate without the key usage Digital Signature. So the The Root Case Record # 2 was issued on 2019 Apr 26 with these key usage : Certificate Sign and CRL Sign.

We are requesting only the inclusion of Root Case Record # 2.

Regards.

Comment 9

[Kathleen Wilson]

(In reply to syrine.tlili from comment #8)

Hi Kathleen,

The Root Case Record # 1 was issued on 2019 Apr 18 with the following key usage : Digital Signature, Certificate Sign and CRL Sign.
According to section 7.1.2.1. of the CA/Browser Forum Baseline Requirements « If the Root CA Private Key is used for signing OCSP responses, then the digitalSignature bit MUST be set. » and in our case the Root CA will not sign OCSP response.
Hence, our auditor who witnessed the KGC recommanded to issue the root certificate without the key usage Digital Signature. So the The Root Case Record # 2 was issued on 2019 Apr 26 with these key usage : Certificate Sign and CRL Sign.

We are requesting only the inclusion of Root Case Record # 2.

Regards.

Thanks for the clarification. I will remove the data for the first instance of this root cert from the CCADB, in order to avoid confusion.

Comment 10

[Kathleen Wilson]

The information for this root inclusion request is available at the following URL.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000499

This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.

There is a queue waiting for detailed CP/CPS reviews:
https://wiki.mozilla.org/CA/Dashboard#Detailed_CP.2FCPS_Review

It takes significant time and concentration to do a detailed CP/CPS review, so please be patient. In the meantime, I recommend looking at the results of the detailed CP/CPS reviews that have been previously completed.
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21

Syrine, Please provide the WebTrust Seals for the period-of-time audits for this CA hierarchy when they become available.

Comment 11

[syrine.tlili]

Hi:

We have received our webtrust audit reports available for download at the following links:

WebTrust for CA period-of-time audit report
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=237002
Webtrust for CA seal
https://www.cpacanada.ca/webtrustseal?sealid=10307

WebTrust for CA-SSL BR and Network Security period-of-time audit report
https://www.cpacanada.ca/generichandlers/cpachandler.ashx?AttachmentID=237003

WebTrust for CA-SSL BR and Network Security seal
https://www.cpacanada.ca/webtrustseal?sealid=10308

Regards.

Comment 12

[Ben Wilson]

Here are some comments regarding the TunTrust CPS.

TunTrust CP/CPS Review (Tunisian Server Certificate Authority PTC BR Certificate Policy / Certification Practice Statement, v. 10.1, 2019-Nov-15)

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) - OK

“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”

Section 9.5 states, “TunTrust owns the intellectual property rights in TunTrust’s services, including the certificates, trademarks used in providing the services, and this CP/CPS.”

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 CPS states, “TunTrust conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.”

Section 2.2 states, “TunTrust conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.”

Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.) - Good

Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.

The *Tuntrust Qualified CA* has EKUs of TLS Web Client Authentication, E-mail Protection, Microsoft Smartcardlogin EKUs.

The *Tuntrust Services CA* has the TLS Web Server Authentication and TLS Web Client Authentication EKUs.

“The end entity certificate profile has the CABF OID of 2.23.140.1.2.2.” (baseline-requirements OV)

Section 7.1.6.1 states, “SSL certificates must contain the certificate policy identifier 2.23.140.1.2.2.”

Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6) – see above

“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”

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.

Section 1.2 contains a table of changes.

Section 2.3 states “Revision Table in Section 1.2 indicates reviews and updates made to this CP/CPS by adding a dated changelog entry and incrementing the CP/CPS version number, even if no other changes are made to the document.”

Section 9.12.1 states “This CP/CPS is reviewed at least annually and may be reviewed more frequently. Revisions of this CP/CPS are reviewed and approved within TunTrust Board of Directors. Amendments are made by posting an updated version of the CP/CPS to the online repository. Changes to this CP/CPS are indicated by an incremental version number.”

Statement of Non-Delegation for Domain Validation (BR § 1.3.2) - Good

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

Section 1.3.2 “TunTrust does not delegate the execution of Section 3.2 requirement to a Delegated Third Party.”

Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) - Meh

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

“Certificate Problem Reports can be submitted via email to: [e-mail]”

This is good that the email address contains the word “revoke”, but it can be improved by adding additional instructions and/or improvements to sections 4.9.2 and 4.9.3 and information available at the revocation URL of http://www.tuntrust.tn/fr/content/revocation-certificat. A version in English would also help.

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.

Section 3.1.4 states, “Fields contained in OV SSL Certificates are in compliance with this CP/CPS. In general, the rules for interpreting name forms can be found in International Telecommunication (ITU) and Internet Engineering Task Force (IETF) Standards, such as the ITU-T X.500 series of standards and applicable IETF RFCs.”

Section 7.1.4 also addresses naming – “Name forms are in the X.500 distinguished name form as implemented in RFC 3739. The content of the Certificate Issuer Distinguished Name field matches the Subject DN of the Issuing CA to support Name chaining as specified in RFC 5280, section 4.1.2.4.”

Additional language could be added about how TunTrust complies with the OV naming requirements found in section 7.1.4.2.2 (Subject Distinguished Name Fields) of the Baseline Requirements.

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

CPS Section 3.2.2.5 – “TunTrust does not issue certificates with IP addresses.”

CPS Section 7.1.4.2.1 - “TunTrust does not issue: certificates with a subjectAlternativeName extension or Subject commonName field containing an IP Address or Internal Name”

ALL certificates must meet Mozilla/BR validation requirements - Good

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)

CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.

[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

Section 3.2.2.4, “TunTrust confirms that prior to issuance, TunTrust has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed below. …

3.2.2.4.2 … [Process description]; 3.2.2.4.4 … [Process description]; 3.2.2.4.13 … [Process description]; and 3.2.2.4.14 … [Process description]”

Data sources need to be accurate (BR § 3.2.2.7) - 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 3.2.2.7 - “TunTrust uses Tunisian governmental entities as data sources and third party databases sourced from Tunisian governmental entities and regularly updated such that TunTrust considers it a reliable data source Before relying on any data provided, TunTrust will verify the following attributes:

- The age of the information provided,

- The frequency of updates to the information source,

- The data provider and purpose of the data collection,

- The public accessibility of the data availability, and

- The relative difficulty in falsifying or altering the data.”

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

CPS Section 3.2.4 reads, “Unverified information is never included in TunTrust end entities Certificates. All Subscriber information included in Certificates are duly verified.”

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 states, “TunTrust does not re-use previous validation information.”

CAA record checking and recognized domain names in section 4.2 (BR § 2.2) – Meh/Bad

“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 2.2 states, “Prior to issuing SSL Certificates, TunTrust checks for CAA records for each dNSName in the subjectAltName extension of the Certificate to be issued as specified in RFC 6844 as per Section 3.2.2.8. TunTrust's CAA issuer domain is "tuntrust.tn."”

Section 3.2.2.8 contains a very good and extensive explanation of TunTrust’s CAA record checking process. However, unfortunately, this doesn’t comply with the Baseline Requirements that this explanation appear somewhere in section 4.2 of the CPS.

Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) - Meh

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

Section 4.3.1 states “Certificate issuance by TunTrust CAs requires a Tuntrust RA operator in Trusted Role authorized by TunTrust to deliberately issue a direct command in order for TunTrust CAs to perform a certificate signing operation.”

Section 6.5.1 states “Strong identification and authentication for all accounts capable of directly causing Certificate Issuance (physical access control to enter in the room by ID badge and PIN + logic control by certificate to access the system);” but it is not entirely clear that this relates to issuance of end entity certificates as well.

Section 4.3.1 of the CPS is not expressly clear that the Trust Role / RA Operator is using multi-factor authentication.

Pre-issuance linting (Recommended Practices) – Very Good

“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”

Section 4.3.1 – “TunTrust CAs uses an automated issuance process that integrates pre-issuance linting tools, kept up-to-date, which can check a tbsCertificate (To Be Signed Certificate - the certificate complete except for the signature) for a large number of standards violations (Baseline Requirements, RFCs, etc.). Certificate issuance is held up for manual review if a linting error or warning is found. The linting error is flagged and brought to the attention of management to complete further internal verification and final decision on the certificate issuance.”

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2) – Good/Meh

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

In sections 4.9.1.1 and 4.9.1.2, TunTrust lists the reasons for revocation similar to those listed in the Baseline Requirements. However, TunTrust’s section 4.9.1.1 is missing this reason- “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based -on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)”.

Section 4.9.5 provides “The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation does not exceed the time frame set forth in Section 4.9.1.1.” - Good

CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6) - Good

Section 4.9.7 states, “The CRL of the issuing CAs are issued every twenty four (24) hours or whenever a Certificate is revoked. The value of the nextUpdate field is not more than six days.”

CA must not allow certificate suspension (BR § 4.9.13) - Good

“No suspension of Certificates is performed by TunTrust.”

OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6) - Good

Section 4.9.10 of the TunTrust CPS states:

\1. TunTrust OCSP responses have a validity interval greater than or equal to eight hours;

\2. TunTrust OCSP responses have a validity interval less than or equal to ten days;

\3. TunTrust OCSP responses have validity intervals less than sixteen hours, therefore TunTrust updates the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) – Meh/Bad

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

Section 5.7.3 needs to include an acknowledgement that TunTrust will notify Mozilla and other root stores in the event of a key compromise.

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. “Applicants are solely responsible for the generation of the private keys used in their Certificate Requests. TunTrust does not provide SSL key generation, escrow, recovery or backup operations.”

Must meet RSA key requirements (MRSP § 5.1) - Good

Section 6.1.5 states that TunTrust uses RSA key pairs and it:

- Ensures that the modulus size, when encoded, is at least 2048 bits, and;

- Ensure that the modulus size, in bits, is evenly divisible by 8.

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 6.3.2 – “Effective August 27th, 2020, the end-user Certificates (SSL OV Certificates) have a Validity period not greater than 398 days.”

Network Security (MRSP § 2.1.2) - Good

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

TunTrust has a good/adequate explanation of its network security. It should remember to periodically review the CABF’s Network and Certificate System Security Requirements. See https://cabforum.org/network-security-requirements/

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

CPS section 7.1 states, “TunTrust generates non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.”

EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f) - OK

TunTrust should be aware that all end entity certificates must contain “[e]ither the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values ….”

Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1) - Good

Section 6.1.5.3 of the CPS only references SHA256.

Any CN must also be in a SAN (BR § 7.1.4.2.2.a) - Meh/Bad

I didn’t find a description of how TunTrust will populate the CommonName (CN) field, although it might be there somewhere.

Comment 13

[syrine.tlili]

(In reply to Ben Wilson from comment #12)

Here are some comments regarding the TunTrust CPS.

Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) - Meh

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

“Certificate Problem Reports can be submitted via email to: [e-mail]”

This is good that the email address contains the word “revoke”, but it can be improved by adding additional instructions and/or improvements to sections 4.9.2 and 4.9.3 and information available at the revocation URL of http://www.tuntrust.tn/fr/content/revocation-certificat. A version in English would also help.

Additional instructions have been added to sections 1.5.2 and 4.9.3. An English Version of the Problem Reporting and Certificate Revocation URL has been added.

CAA record checking and recognized domain names in section 4.2 (BR § 2.2) – Meh/Bad

“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 2.2 states, “Prior to issuing SSL Certificates, TunTrust checks for CAA records for each dNSName in the subjectAltName extension of the Certificate to be issued as specified in RFC 6844 as per Section 3.2.2.8. TunTrust's CAA issuer domain is "tuntrust.tn."”

Section 3.2.2.8 contains a very good and extensive explanation of TunTrust’s CAA record checking process. However, unfortunately, this doesn’t comply with the Baseline Requirements that this explanation appear somewhere in section 4.2 of the CPS.

We added section 4.2.4 Certificate Authority Authorisation that details TunTrust’s CAA record checking process in compliance with the Baseline Requirements.

Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) - Meh

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

Section 4.3.1 states “Certificate issuance by TunTrust CAs requires a Tuntrust RA operator in Trusted Role authorized by TunTrust to deliberately issue a direct command in order for TunTrust CAs to perform a certificate signing operation.”

Section 6.5.1 states “Strong identification and authentication for all accounts capable of directly causing Certificate Issuance (physical access control to enter in the room by ID badge and PIN + logic control by certificate to access the system);” but it is not entirely clear that this relates to issuance of end entity certificates as well.

Section 4.3.1 of the CPS is not expressly clear that the Trust Role / RA Operator is using multi-factor authentication.

We updated section 4.3.1 with a explicit statement on the multi-factor authentication of RA operator for certificate issuance as follows : "The RA operators accounts capable of causing certificate issuance or performing Registration
Authority functions are enforced with multi-factor authentication (certificate in cryptographic token + PIN
code)."

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2) – Good/Meh

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

In sections 4.9.1.1 and 4.9.1.2, TunTrust lists the reasons for revocation similar to those listed in the Baseline Requirements. However, TunTrust’s section 4.9.1.1 is missing this reason- “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based -on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)”.

Section 4.9.1.1 has been updated, the "Debian Weak key" reason for revocation has been moved from the "five days delay for revocation" to the 24 hours delay for revocation in compliance with the Baseline Requirements.

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) – Meh/Bad

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

Section 5.7.3 needs to include an acknowledgement that TunTrust will notify Mozilla and other root stores in the event of a key compromise.

Section 5.7.3 has been updated with an acknowledgment of Mozilla notification in case of a key compromise. In Section 5.7.1, we included an acknowledgment to notify Mozilla when TunTrust fails to comply with any requirements of the CP/CPS.

Any CN must also be in a SAN (BR § 7.1.4.2.2.a) - Meh/Bad

I didn’t find a description of how TunTrust will populate the CommonName (CN) field, although it might be there somewhere.

The end-entity certificate profiles are detailed in Appendix B. The CommonName field is optional and if present it must contain a FQDN that is one of the values contained in the SAN extension.

Please let us know if you require any further information.
Syrine

Comment 14

[syrine.tlili]

UPDATED CP/CPS

https://www.tuntrust.tn/sites/default/files/Ressources/CPCPS-TunTrustPKI.pdf

BR
Syrine.

Comment 15

[TunTrust]

Attachment: TunTrust Root CA's BR Self Assessment.xlsx

Comment 16

[TunTrust]

Hello,

We have the needinfo flag set. Could you please tell us which information do you need from our side?
We already updated our CP/CPS in December following your comments and we also uploaded a more recent version of the BR self assessment.

Thank you.

Comment 17

[Ben Wilson]

(In reply to syrine.tlili from comment #13)

(In reply to Ben Wilson from comment #12)

Review of TunTrust CP/CPS Review (Tunisian Server Certificate Authority PTC BR Certificate Policy / Certification Practice Statement, v. 4.5, 2020-Dec-02)

Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3) - Fixed

Additional instructions have been added to sections 1.5.2 and 4.9.3. An English Version of the Problem Reporting and Certificate Revocation URL has been added.

CAA record checking and recognized domain names in section 4.2 (BR § 2.2) – Fixed

We added section 4.2.4 Certificate Authority Authorisation that details TunTrust’s CAA record checking process in compliance with the Baseline Requirements.

Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3) - Fixed

We updated section 4.3.1 with a explicit statement on the multi-factor authentication of RA operator for certificate issuance as follows : "The RA operators accounts capable of causing certificate issuance or performing Registration
Authority functions are enforced with multi-factor authentication (certificate in cryptographic token + PIN
code)."

Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2) – Fixed

Section 4.9.1.1 has been updated, the "Debian Weak key" reason for revocation has been moved from the "five days delay for revocation" to the 24 hours delay for revocation in compliance with the Baseline Requirements.

Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7) – Fixed

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

Section 5.7.3 needs to include an acknowledgement that TunTrust will notify Mozilla and other root stores in the event of a key compromise.

Section 5.7.3 has been updated with an acknowledgment of Mozilla notification in case of a key compromise. In Section 5.7.1, we included an acknowledgment to notify Mozilla when TunTrust fails to comply with any requirements of the CP/CPS.

Section 5.7.3 of the CPS now states that TunTrust will notify Mozilla and other root stores in the event of a key compromise.

Any CN must also be in a SAN (BR § 7.1.4.2.2.a) - Fixed

I didn’t find a description of how TunTrust will populate the CommonName (CN) field, although it might be there somewhere.

The end-entity certificate profiles are detailed in Appendix B. The CommonName field is optional and if present it must contain a FQDN that is one of the values contained in the SAN extension.

The CPS now states, “If present, this field [the CommonName] contains a Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension.”

Comment 18

[Ben Wilson]

This was moved into public discussion today with a close of public discussion scheduled for 30-Apr-2021.
During the public discussion period, the Agence Nationale de Certification Electronique of Tunisia is expected to respond to questions and comments from the Mozilla community.
See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/dTTp4ZfUW34/m/xfK1LQXSBQAJ

Comment 19

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

Comment 20

[syrine.tlili]

Attachment: TunTrust CA/Quantifying Value

Comment 21

[syrine.tlili]

Attachment: TunTrust CA Budget.pdf

Tuntrust CA Budget 2018-2022

Comment 22

[syrine.tlili]

Hi All,

We added a document on our budget 2018-2022.

We remain at your disposal for any further information.

Regards,
Syrine

Comment 23

[Ben Wilson]

Here is my summary of TunTrust's value justification: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/dTTp4ZfUW34/m/0FN9hAYkAgAJ

Comment 24

[Ben Wilson]

I have completed the summary of the public discussion and closed it, stating an intent to approve this request for inclusion, thus beginning a 7-day “last call” period for any final objections. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/dTTp4ZfUW34/m/2uOO-qIXAgAJ

Comment 25

[Kathleen Wilson]

As per Comment #24, and on behalf of Mozilla I approve this request from Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) to include the following root certificate:

** TunTrust Root CA (Websites); Not EV

I will file the NSS bug for the approved changes.

Comment 26

[Kathleen Wilson]

I have filed bug #1728394 against NSS for the actual changes.