The TunrootCA2 root operates under the following CPS: http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf
The TunserverCA2 subordinate CA operates under a different CPS: http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf I have reviewed the supplied BR Self Assessment, the CPSes, and related information, and have the following comments: ==Good== * Misissued certificates reported earlier in this thread have been revoked ==Meh== * Numerous warning level lint errors in issued certificates: https://crt.sh/?caid=5680&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 * From the US, the server is returning an error or taking more than one minute to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl (crt.sh is also timing out) * The great majority of certificates issued by this CA fall under the .tn TLD; however, the Government of Tunisia has not requested that the root be constrained to issuance for .tn names. * The subordinate CA certificate contains no EKU extension so is not constrained to issuing certain types of certificates. * Delegated 3rd parties are permitted. The CPS does not clearly state the BR requirement that domain validation may not be performed by a delegated third party. * The only method of domain validation specified in the BR Self Assessment is the now deprecated 3.2.2.4.5. How and when will the Government of Tunisia comply with CA/Browser Forum ballot 218? * The Government of Tunisia’s answer for wildcard domain validation in their BR Self Assessment implies the use of method 3.2.2.4.1, but they claim not to use that method in the same document. * CPS section 4.9.2 does not permit a person who controls a domain name contained in a certificate to request revocation unless they are the Subscriber or the Subscriber's legal representative. ==Bad== * Missing SAN entries: https://crt.sh/?cablint=25&iCAID=5680&minNotBefore=2017-01-01 This CA continues to misissue certificates, so the manual controls described earlier in this thread are inadequate. * The current subordinate CA CPS is dated October-2016. The current root CPS is dated July-2015. Mozilla policy requires annual CPS updates. * The CPS does not comply with the BR requirement to document support for Certificate Authority Authorization (CAA). Has CAA been implemented? * The CPS does not describe how domain validation is performed and which of the BR methods are utilized as required by Mozilla policy section 2.2. * The CPS claims in section 4.2.1 that the databases of regional IP address registries are used to verify domain control. Please explain how this is possible. Next steps: 1. I would ask a representative of the Government of Tunisia to answer the above questions. 2. The CPS issues need to be corrected and new versions published. 3. Given the ongoing misissuance, I would not recommend approval of this request until pre-issuance linting has been implemented. Wayne _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
