This request has been in public discussion for more than 6 months, so I would like to make a decision soon. If you have comments or concerns with this request, please post them here by 6-March 2018.
On Tue, Feb 27, 2018 at 7:33 AM, Olfa Kaddachi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > > These updated documents address the concerns I raised below. > > ==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. > I think you meant "SCR" (i.e. Subscriber) not "RSC". Please be aware that finding errors after a certificate is issued but before it is delivered to the SCR/Subscriber is still misissuance. I strongly encourage CAs to implement linting prior to issuance. > ==> * 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. > When was CAA checking as described in the updated CPS first 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. > ==> 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. > > This response does not answer my question, but the statements that caused my concern have been removed from the CPS. > > BR > Olfa > > Wayne _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
