Dear Wayne, The TunRootCA2 root CA operates under the following CPS: http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf ==> The TunRootCA2 operates under a new version of the CP/CPS: : http://www.certification.tn/sites/default/files/documents/CPCPS-NG-EN-02.pdf
The TunserverCA2 subordinate CA operates under a different CPS: http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf ==> The TunServerCA2’s subordinate CA operates under a new version of the CP/CPS : http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf ==Good== * Misissued certificates reported earlier in this thread have been revoked ==> Yes. The RA of the TunServerCA2 has revoked all the misissued certificates and issued new ones for its clients. ==Meh== * Numerous warning level lint errors in issued certificates: https://crt.sh/?caid=5680&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 ==> 99182607 : The certificate has been issued on the 28th Feburary 2017 and was revoked the 03rd of March 2017. ==> 242366304 : The certificate has been issued on 25th October 2017 and was revoked on the 02nd of November 2017. ==> 201192937 : This is the certificate of the OCSP server which checks the status of the TLS/SSL certificates issued under TunServerCA2. * 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). ==> This problem has been resolved. The reason of this slowness was that during the last two weeks, we migrated to our new backup site. * 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. ==> Yes the great majority of certificates issued by this CA fall under the .tn TLD. However, this CA also issues certificates under others TLD like .com, .net and .org. * The subordinate CA certificate contains no EKU extension so is not constrained to issuing certain types of certificates. ==> Yes, the subordinate CA certificate doesn’t contain a EKU extension. TunServerCA2 signs SSL certificate, CRL and OCSP certificate. This subordinate contains Certificate Sign and CRL Sign key usage. * 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. ==> Yes the delegated 3rd parties are permitted. But, the domain validation is only performed by the CRA of TunServerCA2 (see section 1.3.2.2 of the new version of the CP/CPS). * 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? ==> See section 3.2.2 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * 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. ==> See section 3.2.2 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * 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. ==> Yes we confirm that TunServerCA2 does not permit that the person who controls the domain name to request revocation. Only the subscriber and the subscriber’s legal representative are allowed to request revocation. ==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. ==> To resolve the missing SAN entries, a specific coding has been done this week on the RA scripts. The common name specified in the CSR is, from now on, automatically included in the SAN entries. In addition to that, a check of the issued certificate using the lintcert will be done by the operators before delivering the certificate to the RSC. ==> * The current subordinate CA CPS is dated October-2016. The current root CPS is dated July-2015. Mozilla policy requires annual CPS updates. ==> The revision dates of the subordinate CA CPS are: the 26th of June 2015, 28th of July 2015, 21st of October 2015, 21st of January 2016, 12th of February 2016, 18th of October 2016, 27th of November 2017 and 27th of February 2018. ==> The revision dates of the root CPS are : 01st of june 2015, 28th of july 2015 and 27th of November 2017. In the future, both of the TunRootCA2 and TunServerCA2 CPSs will be reviewed at least once a year to meet the requirement of the Mozilla policy. * The CPS does not comply with the BR requirement to document support for Certificate Authority Authorization (CAA). Has CAA been implemented? ==>See section 4.2.1 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * 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. ==> See section 3.2.2 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * 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. ==> The TunServerCA2 does not allow IP Address to be listed in certificates. BR Olfa _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
