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 <> wrote:

> Dear Wayne,
> The TunRootCA2 root CA operates under the following CPS:
> ==>     The TunRootCA2 operates under a new version of the CP/CPS: :
> CPCPS-NG-EN-02.pdf
> The TunserverCA2 subordinate CA operates under a different CPS:
> CPCPS-PTC-BR-EN-05.pdf
> ==>     The TunServerCA2’s subordinate CA operates under a new version of
> the CP/CPS :
> 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:
> 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
> ( 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
> of the new version of the CP/CPS).
> * The only method of domain validation specified in the BR Self Assessment
> is the now deprecated How and when will the Government of
> Tunisia comply with CA/Browser Forum ballot 218?
> ==>     See section 3.2.2 of the new version
> 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, but they
> claim not to use that method in the same document.
> ==>     See section 3.2.2 of the new version
> 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:;
> 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
> 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
> 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

Reply via email to