TunRootCA2 root inclusion request

[Aaron Wu]

This request from the Government of Tunisia is to include the “Tunisian Root Certificate Authority - TunRootCA2” root certificate, and enable the Websites trust bit.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1233645

BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8865381

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=8884764

* Root Certificate Download URL:
http://www.certification.tn/pub/TunRootCA2.crt

* Documents are in French, translated in English
CP/CPS in French: http://www.certification.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-05.pdf

CP/CPS in English: http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf


* CA Hierarchy:
This root will have internally-operated subordinate CAs.
Currently it has one internally-operated subordinate CA:
- Tunisian Server Certificate Authority - TunServerCA2

* This request is to turn on the Websites trust bit. EV treatment is not requested.

* CP/CPS of the Tunisian Server Certificate Authority PTC BR:

** Section 1.3.4:
“In the context of this CP / CPS, a Server Certificate Responsible (SCR) is a natural person who is responsible for using the certificate of the server or computer device identified in the certificate and the private key corresponding to this certificate, on behalf of the entity identified in that certificate. The SCR is contractually, hierarchically or legally bound to this entity.”

** Section 3.2.2:
“Authentication of a client organization is done by checking the following documents:
The certificate application form duly completed and signed by the applicant, acting as a certificate request, containing in particular the postal address, the professional e-mail address and the telephone number enabling the NDCA to contact the future bearer;
• A copy of the National Identity Card, passport or residence card of the applicant and the SCR;
• An extract from the trade register not exceeding three months;
The bearer must be informed that the personal identity information he has provided for the registration file will be retained.
The verification and validation of the request are carried out in accordance with the provisions described in section 4.2.”

** Section 4.2.1:
"For the purpose of verifying the identities of the applicants, the RA, performs the following operations:
check the consistency of the registration dossier and the supporting documents submitted;
verify the accuracy of the purchase order and payment;
verify that the organization holds the domain name by consulting the official databases of AFRINIC or INTERNIC domain names, and
ensure that the SCR is aware of the terms and conditions applicable to the use of the certificate.
Upon completion of these transactions, the RA sends the request to the CA components responsible for certificate production. The RA then retains a copy of the proof of identity submitted in paper or electronic form having a legal value.”


* EV Policy OID: Not Requesting EV treatment

* Test Websites
Valid certificate: https://valid-ov.certification.tn
Revoked certificate: https://revoked-ov.certification.tn
Expired certificate: https://expired-ov.certification.tn

* CRL URLs:
http://crl.certification.tn/TunRootCA2.crl
http://crl.certification.tn/TunServerCA2.crl
CP/CPS section 2.3: A new CRL is published every 24 hours

* OCSP URLs:
http://ocsp.certification.tn
OCSP responses have a maximum expiration time of 10 days.

* Audit: Annual audits are performed by LSTI according to the ETSI TS 102 042 for CA and BR audit criteria.
https://bug1233645.bmoattachments.org/attachment.cgi?id=8879910


* Forbidden or Problematic Practices (https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices)
None Noted

This begins the discussion of the request from the Government of Tunisia is to include the “Tunisian Root Certificate Authority - TunRootCA2” root certificate, and enable the Websites trust bit.

I will greatly appreciate your constructive and thoughtful feedback on this request.

Aaron

[Charles Reiss]

On 07/19/17 05:10, Aaron Wu wrote:
> - Tunisian Server Certificate Authority - TunServerCA2

https://crt.sh/?id=21813439 is a certificate issued by this CA which has
a domain name in the common name but only an email address in the SAN.
(The certificate has TLS server/client usage EKUs.)


https://crt.sh/?id=99182607 is a revoked certificate issued by this CA
which has a domain name in the common name which does not match the
domain name in the SAN, which is for a different TLD. (A new certificate
with both names in SANs, https://crt.sh/?id=99462700 , has a notBefore
which appears to have around the same timestamp as the revocation.)


https://crt.sh/?id=15126121 is an expired certificate (notBefore March
2016; notAfter March 2017) issued by this CA which has a wildcard name
in the common name while the SAN contains specific domain names that
would be covered by the wildcard only.


https://crt.sh/?id=10975511 is an expired certificate with a notBefore
of Oct 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress
SAN of 127.0.0.1. (I believe that by 2014, the BRs prohibited issuing
internal name certs with validity past November 2015.)

[Charles Reiss]

On 07/19/2017 05:10 AM, Aaron Wu wrote:
> - Tunisian Server Certificate Authority - TunServerCA2

https://crt.sh/?id=79470561&opt=cablint is a certificate for the
internal name 'adv-mail.calladvance.local' issued by this CA with a
notBefore of 2017.

[kaddachi olfa]

https://crt.sh/?id=21813439 is a certificate issued by this CA which has a domain name in the common name but only an email address in the SAN. (The certificate has TLS server/client usage EKUs.)

==> The CA proceeded to notify the end entity of the certificate https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new certificate is issued by TunServerCA2.to this end entity.

********

https://crt.sh/?id=99182607 is a revoked certificate issued by this CA which has a domain name in the common name which does not match the domain name in the SAN, which is for a different TLD. (A new certificate with both names in SANs, https://crt.sh/?id=99462700 , has a notBefore which appears to have around the same timestamp as the revocation.)

==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on 2017-03-03 and issue a new one for the end entity https://crt.sh/?id=99462700. The new certificate contains both names in SAN (DNS=vpn.tunisieclearing.com and Nom DNS=vpn.tunisieclearing.tn). The CA, at the time of issuance, has verified that the Applicant had the right to use and had the control of the both Domain Names.

*********

https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; notAfter March 2017) issued by this CA which has a wildcard name in the common name while the SAN contains specific domain names that would be covered by the wildcard only.

==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 2016-03-21 when the CA discover the mistake in the SAN extension. A new certificate is issued on the same day (2016-03-21) with the right SAN (*.sonede.com.tn). See the certificate below:

-----BEGIN CERTIFICATE-----
MIIGuTCCBKGgAwIBAgIQQVkWAyEXAyAwgwPw3/OEojANBgkqhkiG9w0BAQsFADB8
MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp
Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj
YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNjAzMjEwMDAwMDBaFw0x
NzAzMjAyMzU5NTlaMIHMMQswCQYDVQQGEwJUTjFBMD8GA1UECgw4U1RFIE5BVElP
TkFMRSBEIEVYUExPSVRBVElPTiBFVCBERSBESVNUUklCVVRJT04gREVTIEVBVVgx
KDAmBgNVBAsMH0RJUkVDVElPTiBDRU5UUkFMRSBJTkZPUk1BVElRVUUxGDAWBgNV
BAMMDyouc29uZWRlLmNvbS50bjEmMCQGCSqGSIb3DQEJARYXd2VibWFzdGVyQHNv
bmVkZS5jb20udG4xDjAMBgNVBAcMBVRVTklTMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAtUqxkjJGrnLQ+fx4vif+PV9FlwTByGoQ5F/2Kc67u9iM0zBt
ttkcUHzdwoSkPLaYKezT3FQhuE7c1BKRBfne95zmDJ6kKbvoehUG6niJP6qOQ5p2
aT3oHPI87e20SQPFvvZMSbDftDq9/cH/69d+NkSlfAvihks7hp/zZv9QDdxaZh/O
SfA12SRUy0/Q2n7VKnJrUPBK3Ydyl0KOS5p6LNxOUG4faJ9Fil3OO2b54etyMMcc
QTiDqwDUXMohR3KzCQpUD9RGba41Stqwj7PO25YtNJbSSfCq5Sn9nZn8K9iapIDQ
1uwLO+VJf2SwEZl4iZulAhmXLieq/lv+oZreWQIDAQABo4IB5DCCAeAwDAYDVR0T
AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG
AQUFBwMCMBoGA1UdEQQTMBGCDyouc29uZWRlLmNvbS50bjAfBgNVHSMEGDAWgBSH
q/dpS1D2YVf/P1uOHXDGomyqxjA9BgNVHR8ENjA0MDKgMKAuhixodHRwOi8vY3Js
LmNlcnRpZmljYXRpb24udG4vVHVuU2VydmVyQ0EyLmNybDB7BggrBgEFBQcBAQRv
MG0wLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLmNlcnRpZmljYXRpb24udG46ODA4
MDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL3B1Yi9U
dW5TZXJ2ZXJDQTIuY3J0MIGnBgNVHSAEgZ8wgZwwgZkGCGCGFAECBgEIMIGMMCwG
CCsGAQUFBwIBFiBodHRwczovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL2NwczBcBggr
BgEFBQcCAjBQMCwWJU5hdGlvbmFsIERpZ2l0YWwgQ2VydGlmaWNhdGlvbiBBZ2Vu
Y3kwAwIBARogaHR0cHM6Ly93d3cuY2VydGlmaWNhdGlvbi50bi9ycGEwDQYJKoZI
hvcNAQELBQADggIBABUXwoV4YIrF4SVRUsb/dPhCO0uxcyVylVGz2y+OIDIsuy+d
7yJl4gCeLsMIIexWVqupnx1qzX8LR6ZMpVWbTeie0EFOppBU6S1OcFvf+6kQ9FNa
RwCUn+fcYr5+NQRZD2OmfIeiqJ/vo0yNKQ2j5KENG1JZ8AgyeJ1RBK8IxAHNe9oE
sdqjxXL54fh6t4zxfgavaRv9dZo+Ph4udEq1Ea/dKXg0pfsM1/bVpO+V1yaiL+lk
fH/diGWUVV5HTlmtPCXU3idUKZytOWsP+NljHxQAmVzv38aAvvC9r2Dgc/MScCHP
b7iBDDfwZRVj78MIAjHlf5cOAUCAJUmEC0lXnBNSRKAmYThCr+SVuKrqcwGcq5+X
yNo46/ba6y/M/Q3TPCgDlFzgpxJ2Ox3jntSuA6qhLgJagC1HJce0wqAfCy4rAYuD
WpsGr0rm65DSYgr+MZlcp4UNE1M+plKl7rXClYg5lRVX1c4glYr9+Do05z49ZRHq
1C8LpHbBYkDVbz/EsuDLZ+Y1wpo4Nec+PEfKm/Tc6Cyfr8JmHOhJ/YmaRg2UBh2q
1PE3gKyb5SZmmLmFBgwO5G91EvQOCSyuI/s7bzP5ra392q7Z9iFzadETjGjflWEq
pMMUmphu3cCez871AUvDhMKKDlEdGob8Xw3RTwz485FuUdL8qb2vw36Jhhki
-----END CERTIFICATE-----


**********

https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name certs with validity past November 2015.)

==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an IPAddress SAN of 127.0.0.1. The new certificate for the end entity (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See certificate below:

-----BEGIN CERTIFICATE-----
MIIGqTCCBJGgAwIBAgIQQVkWEhQXEhOUxb2pudH/dDANBgkqhkiG9w0BAQsFADB8
MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp
Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj
YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNjEyMTQwMDAwMDBaFw0x
NzEyMTMyMzU5NTlaMIGkMQswCQYDVQQGEwJUTjEOMAwGA1UEChMFQ0VQRVgxHzAd
BgNVBAsTFkRJUkVDVElPTiBDRU5UUkFMRSBUSUMxHjAcBgNVBAMTFW1haWwudHVu
aXNpYWV4cG9ydC50bjEuMCwGCSqGSIb3DQEJARYfYWRtaW5pc3RyYXRldXJAdHVu
aXNpYWV4cG9ydC50bjEUMBIGA1UEBxMLVFVOSVMgQ0VERVgwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDBhGvVLiT77ZY3DwlHO/1wzU58lyoINz5JH9xp
2FU1oyuQ3QXS3uRSjpn4ndCmo1jV1Tm88rmSw0/v0I7lRK3JFnAOo3HEScNMOiv4
JQb/qVNdCMJNdwL4pmgUSguRU/j0Ti7LPK6ThONoy6mOb0autkhFSbfxXI/li1cF
IUz/G715gBTMMAY0maS6eCPmnOiKQtqyHXdj95rhsKhPlJjSvUntTzMHBtjMiPmj
qkax5lJH4kRYcq++Q+pmmTY/osuBWDWD4bLYRjzNV6Wi5PkH6uEFaoqmRhJhq0Bs
dNo1Bqhhv90bXh246q3170gbLjcnVaJIb8QpoUQOgK1SsYK3AgMBAAGjggH8MIIB
+DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHwYDVR0jBBgwFoAUh6v3
aUtQ9mFX/z9bjh1wxqJsqsYwPQYDVR0fBDYwNDAyoDCgLoYsaHR0cDovL2NybC5j
ZXJ0aWZpY2F0aW9uLnRuL1R1blNlcnZlckNBMi5jcmwwewYIKwYBBQUHAQEEbzBt
MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5jZXJ0aWZpY2F0aW9uLnRuOjgwODAw
PAYIKwYBBQUHMAKGMGh0dHA6Ly93d3cuY2VydGlmaWNhdGlvbi50bi9wdWIvVHVu
U2VydmVyQ0EyLmNydDCBpwYDVR0gBIGfMIGcMIGZBghghhQBAgYBCDCBjDAsBggr
BgEFBQcCARYgaHR0cHM6Ly93d3cuY2VydGlmaWNhdGlvbi50bi9jcHMwXAYIKwYB
BQUHAgIwUDAsFiVOYXRpb25hbCBEaWdpdGFsIENlcnRpZmljYXRpb24gQWdlbmN5
MAMCAQEaIGh0dHBzOi8vd3d3LmNlcnRpZmljYXRpb24udG4vcnBhMDgGA1UdEQQx
MC+CFW1haWwudHVuaXNpYWV4cG9ydC50boIWY2VwZXgtbWFpbC5DRVBFWC1OVC5U
TjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DANBgkqhkiG9w0BAQsFAAOCAgEAR0KY
nSesbliAs0OtMnTWzNM1UtZdw9FeuB8BwSq26OQRFjbK37f76GDuRRmqNvzH0Kea
aK0HEiMpqTBlP37E2W7gp7ZXtYnERtbDz2gt9+X151dyoChAW3/mkLWVTQe0iEon
Oh8BuCsM56d3T2hB8inE0OIN/2794LAOIivmhI+6AK/iSzGemT2YO/+mZx6dMddr
PMkBdv+nKxa/vpL4fBhwkTWI2s9tDpVlB3Bok91K49oyPFo7J0zRWUzjkckLlMe5
mXRbXg9LiwDrcsNuuo/dyFMGZwEO9Y85uAOBGrUHUr3S819gfZkOz8wpZTxxEipT
BF+mjx/yNpat6ys0p9PQthlrHi99eadJGspszR3MAC5rx4q2B2mXynmtYGJqaHZh
kG6mLQfHSyOneIkIw5p5gPFGvXklgSULtgOWBnzHR7DH7HvN8776mLZFUn++BU17
JC/nZ7/xV4TeM6LchODP9NqxNE1z1HIgAH4jVAdV9C8mRzAON5qTo5GzNtq/BmRq
UiP38X66NhjG3kCSTNphuM5o/Cgoo/fH2wgeDdkDdYJNQ3GFmTgbQEQNHG+H6SNW
0bzIyzmpB65XuQ2c66AwhTE8Dvyk5yzfOQeKXa8pNkojGkBLZ2OzJSKiUl5tNMVe
+Y2fb5FZtFMdzJ/WD0XmyPxRbhPJMtmsm8VCE4A=
-----END CERTIFICATE-----


**************************************
https://crt.sh/?id=79470561&opt=cablint is a certificate for the internal name 'adv-ail.calladvance.local' issued by this CA with a not Before of 2017.

==> The CA proceeded to notify the end entity of the certificate https://crt.sh/?id=79470561&opt=cablint. The certificate is revoked on 28/07/2017 and replaced by a new certificate which does not contain in SAN extension the internal name "adv-mail.calladvance.local". See ertificate below:

-----BEGIN CERTIFICATE-----
MIIGzDCCBLSgAwIBAgIQQVkXBygYAQhwsemy3u00aTANBgkqhkiG9w0BAQsFADB8
MQswCQYDVQQGEwJUTjEuMCwGA1UEChMlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZp
Y2F0aW9uIEFnZW5jeTE9MDsGA1UEAxM0VHVuaXNpYW4gU2VydmVyIENlcnRpZmlj
YXRlIEF1dGhvcml0eSAtIFR1blNlcnZlckNBMjAeFw0xNzA3MjgwMDAwMDBaFw0x
ODAxMDgyMzU5NTlaMIGuMQswCQYDVQQGEwJUTjEeMBwGA1UEChMVQURWQU5DSUEg
VEVMRVNFUlZJQ0VTMRUwEwYDVQQLEwxESVJFQ1RJT04gSVQxJzAlBgNVBAMTHm1h
aWwuYWR2YW5jaWEtdGVsZXNlcnZpY2VzLmNvbTEuMCwGCSqGSIb3DQEJARYfYWRt
aW5AYWR2YW5jaWEtdGVsZXNlcnZpY2VzLmNvbTEPMA0GA1UEBxMGVFVOSVNBMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtw1jMHicoELF3MkXQKu2oNjR
6k/apP0qodi8WFdlLulET1WkxvQr30j0tRAkiTuvH9P1qNVKOAXpalBtOpJXGfxH
eT+et28LZ9p+lGlkKsCElP8d8lotMYzkFbndgMc0ed61jZEhkoBHzObibECzA2kI
m8q7nXAMjz5s726rUVS3jR3E5Zn3X4Bw5gYzrkFhcUG7w9Rf4MNfz9hrRqiH0j0+
XBYVm41X+qnJrnLt9GBI+eYbWuIkt1TROQQbCpwrC0vrjkBfB6739hpbiID7o9Vg
01/AnfStIhqZTTLfLGt4N0dgBEHMSRWzzuffA8oOfrDLWH24OBs/PLmkj25wDQID
AQABo4ICFTCCAhEwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1Ud
IwQYMBaAFIer92lLUPZhV/8/W44dcMaibKrGMD0GA1UdHwQ2MDQwMqAwoC6GLGh0
dHA6Ly9jcmwuY2VydGlmaWNhdGlvbi50bi9UdW5TZXJ2ZXJDQTIuY3JsMHsGCCsG
AQUFBwEBBG8wbTAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AuY2VydGlmaWNhdGlv
bi50bjo4MDgwMDwGCCsGAQUFBzAChjBodHRwOi8vd3d3LmNlcnRpZmljYXRpb24u
dG4vcHViL1R1blNlcnZlckNBMi5jcnQwgacGA1UdIASBnzCBnDCBmQYIYIYUAQIG
AQgwgYwwLAYIKwYBBQUHAgEWIGh0dHBzOi8vd3d3LmNlcnRpZmljYXRpb24udG4v
Y3BzMFwGCCsGAQUFBwICMFAwLBYlTmF0aW9uYWwgRGlnaXRhbCBDZXJ0aWZpY2F0
aW9uIEFnZW5jeTADAgEBGiBodHRwczovL3d3dy5jZXJ0aWZpY2F0aW9uLnRuL3Jw
YTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DBRBgNVHREESjBIgh5tYWlsLmFkdmFu
Y2lhLXRlbGVzZXJ2aWNlcy5jb22CJmF1dG9kaXNjb3Zlci5hZHZhbmNpYS10ZWxl
c2VydmljZXMuY29tMA0GCSqGSIb3DQEBCwUAA4ICAQADMlsU8yAX+wT9VwKMFqEM
fD0da3gNesgSvy77TM1F4R5fOkWvYsJ9vv0TbxY5jvyvaG90MxnE86uptNgS+BSZ
dKnXkRBeM9X/cUsmJU1mnkmHCdG9vqRldGjhcbqmBd5hsCaBGi4i5aSxUcKMZ8Yi
UTxa0dQAUzvIxqjLSpVtx+ZRD0Tu1zx/Hgw+qiKxFqZnm1aao94gB3zca3UB5Bwf
tM23pSbHGct6nFZPzKj5URFX+pgFEeZ62kLLx52ejSyJJ0mqiz4OmDEE8Gnr/Ifz
/qZ7S3bpAJRlq33l2n/+GWT1Q+lM9fGdJX526bTviaoAMbhhQHizCh60eP6q02mN
R0aY4Es2rJ4vJWM/pCw6RgSeud+jWxej9S2q0e9AajLJRtPsnQh3UxEfUn4xc11m
LfOUYJZpJFVZQF4C5RLoLeff4NgqdxTLuh9DF7vH5jyDNMLMvX8hhqMLBcEA9DGA
Tb9fSNVRGQXZO3Ad+2AWyZYHE5dHS8NfKm3mu8a+j00OVxHNTn8tKGIN1cNcwb14
CyqiboCdipcZpuTTv1VYBsH9Si7jAk+JZVAyipiqSTT2LVtnO2BQU3M8fWQulrxJ
XrvvSfgUrF63GH0F0XipK14CfplnMUWp27gPGyztRhGFUuq34D4UYut7LmiCIlUY
w8BN8ZBFiUDOSmydQeB6ew==
-----END CERTIFICATE-----


Olfa Kaddachi

[Jonathan Rudenberg]

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> ==> The CA proceeded to notify the end entity of the certificate https://crt.sh/?id=21813439. The certificate is revoked on 28/07/2017. No new certificate is issued by TunServerCA2.to this end entity.
>

> ==> Yes the CA has revoked the certificate https://crt.sh/?id=99182607 on 2017-03-03 and issue a new one for the end entity https://crt.sh/?id=99462700. The new certificate contains both names in SAN (DNS=vpn.tunisieclearing.com and Nom DNS=vpn.tunisieclearing.tn). The CA, at the time of issuance, has verified that the Applicant had the right to use and had the control of the both Domain Names.
>

> ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 2016-03-21 when the CA discover the mistake in the SAN extension. A new certificate is issued on the same day (2016-03-21) with the right SAN (*.sonede.com.tn). See the certificate below:
>

> ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an IPAddress SAN of 127.0.0.1. The new certificate for the end entity (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See certificate below:
>

> ==> The CA proceeded to notify the end entity of the certificate https://crt.sh/?id=79470561&opt=cablint. The certificate is revoked on 28/07/2017 and replaced by a new certificate which does not contain in SAN extension the internal name "adv-mail.calladvance.local". See ertificate below:
>

> Olfa Kaddachi

These incidents appear to demonstrate a lack of sufficient technical controls to prevent certificates from being issued with unvalidated and invalid data. Would you please describe:

1) the technical controls currently implemented in the issuance process;
2) the deficiencies identified in those controls after the misissuance of each of these certificates;
3) the implemented and planned improvements to the technical controls to prevent these errors from happening again.

Thanks,

Jonathan

[Jonathan Rudenberg]

For reference, I’ve added crt.sh links for the replacement certificates below.

> On Jul 29, 2017, at 09:08, kaddachi olfa via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>

> https://crt.sh/?id=15126121 is an expired certificate (notBefore March 2016; notAfter March 2017) issued by this CA which has a wildcard name in the common name while the SAN contains specific domain names that would be covered by the wildcard only.
>

> ==> The CA has revoked the certificate https://crt.sh/?id=15126121 on 2016-03-21 when the CA discover the mistake in the SAN extension. A new certificate is issued on the same day (2016-03-21) with the right SAN (*.sonede.com.tn). See the certificate below:
>

https://crt.sh/?id=15597407

> https://crt.sh/?id=10975511 is an expired certificate with a notBefore of Oct 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress SAN of 127.0.0.1. (I believe that by 2014, the BRs rohibited issuing internal name certs with validity past November 2015.)
>

> ==>Yes https://crt.sh/?id=10975511 is an expired certificate which contain an IPAddress SAN of 127.0.0.1. The new certificate for the end entity (mail.tunisiaexport.tn) has been issued by the CA on 14-12-2016. See certificate below:

https://crt.sh/?id=180718609

> https://crt.sh/?id=79470561&opt=cablint is a certificate for the internal name 'adv-ail.calladvance.local' issued by this CA with a not Before of 2017.
>

> ==> The CA proceeded to notify the end entity of the certificate https://crt.sh/?id=79470561&opt=cablint. The certificate is revoked on 28/07/2017 and replaced by a new certificate which does not contain in SAN extension the internal name "adv-mail.calladvance.local". See ertificate below:

https://crt.sh/?id=180718608

[Olfa Kaddachi]

Hi Jonathan,

Please find below the description of the technical and organizational controls required:

1) The currently process of certificates issuance is composed by 4 steps:
step 1: Registration process:
This step consists of the verification of the following items:
•the subscriber identify
•the accuracy of the certificate requests (RA is using currently this URL to check the CSR
https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp)
•the possession of the domain names (who is, organization, validation phone,...)
•....
After that, the RA operator insert all the required data in the RA interface, theses controls are implemented:
•control of the syntax of the server name
•control of the email of the server administrator
•control of the identifier of the administrator
•check of the CSR

step2: Validation process:
In this step, another registration operator (different of the first one), check all the inserted data. This check consists of the verification of inserted data against paper data.
step3: Issuance of the certificate:
In this step, the only control consists of the check of the data in the CSR against the inserted data. In the event of any error, the request is rejected.
step4: Check of the issued certificate:
In this step, another registration operator check the issued certificate before its delivery.

2) The deficiencies identified in those controls after the misissuance of each of these certificates are essentially:
•controls on the field subject alternative names :
o this field must not contains private addresses
o this filed must not contain 127.0.0.1 address
o this filed must not contain a local FQDN
o this field must at least contain the CN

3) The implemented and planned improvements to the technical controls to prevent these errors from happening again:
The NDCA is implementing a new system (Managed PKI solution) which includes such controls in different fields (CN, mail of administrator, check of CSR, check of subject alternative names, ...).

Thanks
Olfa

[Gervase Markham]

Hi Olfa,

On 31/07/17 11:55, Olfa Kaddachi wrote:
> 2) The deficiencies identified in those controls after the misissuance of each of these certificates are essentially:
> •controls on the field subject alternative names :
> o this field must not contains private addresses
> o this filed must not contain 127.0.0.1 address
> o this filed must not contain a local FQDN
> o this field must at least contain the CN

Given that some of these are BR requirements, why were these controls
not in place already?

>From what date would you say that your CA has been compliant with the
CAB Forum Baseline Requirements?

> 3) The implemented and planned improvements to the technical controls to prevent these errors from happening again:

When will these improvements be implemented? And, given that these are
only four possible ways a certificate can be messed up, what other
checks are going to be implemented at the same time?

Gerv

[Olfa Kaddachi]

Dear Gerv,

Given that some of these are BR requirements, why were these controls not in place already?

==> Some of these controls are already in place (such as the field CN and Subject Alternative Name that does not contain a private IP address).
In addition to that NDCA has implemented a procedure for the RA operators which include these sections:
1- Validation of the Organization

- In case of a commercial and private organization: The RA operator checks the web site http://www.registre-commerce.tn. Then, he inserts the Tax Identification Number to verify the existence of the organization.

- In the case of a public organization : The RA operator checks the web site http://www.infojort.com. Then, he inserts the Tax Identification Number to verify the existence of the organization.
2- Domain Validation :
For the National domains, the RA operator checks the web site of the Tunisian Internet Agency which is responsible of the management of the national domain ".tn" and the IP addressing in Tunisia ( http://whois.ati.tn ).
For the international domains, the RA operator checks the international whois.
In both cases, the RA operator checks if the domain name is the property of the applicant.
3- CSR Validation
The RA operator checks the CSR with this URL https://cryptoreport.websecurity.symantec.com/checker/views/csrCheck.jsp





4- Validation of the technical data included in the CSR: The RA operator checks :

Digital Signature Algorithm: SHA256
Key Algorithm: RSA
Key Size: 2048

5- Validation of the data inserted in the CSR against the data filled in the form :
Common name:
Organization:
Organizational unit:
City/locality:
State/province:
Country:
6- Validation of the email : The RA operator checks if the email is in this form:
ad...@domaine.com
Postm...@domaine.com
admini...@domaine.com
webm...@domaine.com
7- Validation of the information related to the legal person and the subscriber
8- Phone Call to the webmaster of the server
Moreover, the NDCA is now implementing a new Managed PKI platform which will be in production by the end of September 2017. For the moment, the only improvement done, is the printing of all the subject alternative names in the certificate for the RA operators, in addition to the other fields (CN, O, OU, mail) in such a way that they can visually check all the fields before the delivery of the certificate.

>From what date would you say that your CA has been compliant with the CAB Forum Baseline Requirements?

==> The TunRootCA2 and TunServerCA2 passed two successive external audit performed by LSTI. The last audit took place from 27th to 30th September 2016 in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1.
The audit was performed by LSTI as a full audit. This audit confirms the validity of the certificate N° 11140 issued on November 2015 and valid until November 2018. The next full audit will be performed from 11th to 15th of September 2017.

When will these improvements be implemented? And, given that these are only four possible ways a certificate can be messed up, what other checks are going to be implemented at the same time?

==> These improvements have already been implemented by our service provider during this week. The tests will be done from 14th to 25th of August 2017. The beginning of production is planned for the end of September after the audit.
We already have other checks besides those four in our information system such as checking the fields in the CSR. These checks are already implemented.
Olfa

[Fotis Loukos]

Hello,
I started reading your CP/CPS and I noticed that you do not use the
standard CA/B Forum terminology. Is this on purpose? Is it just a
translation issue?

Furthermore, I believe that the English Root CA CP/CPS should be added
to the bug, I can only find the translation of the SSL SubCA CP/CPS.

And just a final note, I can't seem to be able to access the mail sent
by Gerv the 15th of August (the one I'm replying to) at the google
groups thread
(https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wCZsVq7AtUY).
Maybe it got lost somehow and the CA contacts are using google groups to
get an update on their discussion.

Regards,
Fotis

On 15/08/2017 03:41 μμ, Gervase Markham via dev-security-policy wrote:

> On 03/08/17 08:01, Olfa Kaddachi wrote:
>> ==> Some of these controls are already in place (such as the field CN and Subject Alternative Name that does not contain a private IP address).
>

> That doesn't quite answer my question.
>
> Let me ask another way: for how long has the Government of Tunisia CA
> been aware of the Baseline Requirements? From what date do you assert
> that you have been compliant with these requirements?

>
>> 4- Validation of the technical data included in the CSR: The RA operator checks :
>>
>> Digital Signature Algorithm: SHA256
>> Key Algorithm: RSA
>> Key Size: 2048
>

> Why can such things not be checked programmatically? It seems you are
> opening yourselves up to the possibility of human error.

>
>> Moreover, the NDCA is now implementing a new Managed PKI platform which will be in production by the end of September 2017. For the moment, the only improvement done, is the printing of all the subject alternative names in the certificate for the RA operators, in addition to the other fields (CN, O, OU, mail) in such a way that they can visually check all the fields before the delivery of the certificate.
>

> A visual check may not catch every problem. For example, would it catch
> a trailing space?

>
>> >From what date would you say that your CA has been compliant with the CAB Forum Baseline Requirements?
>> ==> The TunRootCA2 and TunServerCA2 passed two successive external audit performed by LSTI. The last audit took place from 27th to 30th September 2016 in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1.
>

> And that audit includes a BR audit?
>
> Did the audit report have any qualifications?
>
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


--
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com

[Olfa Kaddachi]

Hello,

It is mentioned in the page 9 section 1.1 that :
The CA servers complies with the current version of the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" (BR) published at http://www.cabforum.org.
In the event of inconsistency between this document and the CAB Forum BR requirements, the CAB Forum BR requirements apply. "

We will proceed to the transalation of the Root CP/CPS as soon as possible.

[Olfa Kaddachi]

Hi,

please find at this URL the translation of the root CP/CPS.
http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf

Best regards

[wth...@mozilla.com]

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

[Olfa Kaddachi]

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

[Wayne Thayer]

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-secur...@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.

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

[Jonathan Rudenberg]

> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> 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.

Given the misissued certificates in CT under the existing root, I believe this request should be rejected, and a new clean root with audits should be required before moving forward.

The errors in the issued certificates indicate a lack of technical controls in addition to improperly implemented certificate profiles. Given this, an explanation should also be provided of what changes have been made to the issuance environment to ensure these types of mistakes will not happen under the new root.

There are a bunch of warnings, but these jumped out at me as being very serious:

These certificates have a commonName that is not included as a dNSName SAN:

- https://crt.sh/?id=99182607&opt=cablint
- https://crt.sh/?id=242366304&opt=cablint

This certificate has a SAN with a domain ending in .local, which is a reserved special-use TLD:

- https://crt.sh/?id=79470561&opt=cablint

It’s important to remember that these are only the certificates that we know about via CT. There may be certificates with similar or other issues that are not logged.

Jonathan

[Jonathan Rudenberg]

> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>
>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>
>> 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.
>
> Given the misissued certificates in CT under the existing root, I believe this request should be rejected, and a new clean root with audits should be required before moving forward.
>
> The errors in the issued certificates indicate a lack of technical controls in addition to improperly implemented certificate profiles. Given this, an explanation should also be provided of what changes have been made to the issuance environment to ensure these types of mistakes will not happen under the new root.

I just took a closer look at the thread, and it appears that some misissuance was pointed out in July and most of the controls that were suggested as a solution relied on humans. These controls appear to have predictably failed, as multiple misissued certificates are from this fall, well after the fixes should have been in place.

[Wayne Thayer]

On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jona...@titanous.com>

wrote:

>
> > On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> >
> >> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >>
> >> 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.
> >
> > Given the misissued certificates in CT under the existing root, I
> believe this request should be rejected, and a new clean root with audits
> should be required before moving forward.
> >
>

This course of action doesn't seem consistent with our treatment of the
many included CAs that have experienced these problems.

> > The errors in the issued certificates indicate a lack of technical
> controls in addition to improperly implemented certificate profiles. Given
> this, an explanation should also be provided of what changes have been made
> to the issuance environment to ensure these types of mistakes will not
> happen under the new root.
>
> I just took a closer look at the thread, and it appears that some
> misissuance was pointed out in July and most of the controls that were
> suggested as a solution relied on humans. These controls appear to have
> predictably failed, as multiple misissued certificates are from this fall,
> well after the fixes should have been in place.
>

> Olfa's most recent response indicates that additional/technical controls
were added this week. However, I'm not convinced that they are adequate.

[Jonathan Rudenberg]

> On Feb 27, 2018, at 16:47, Wayne Thayer via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jona...@titanous.com>
> wrote:
>
>>
>>> On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>>
>>>
>>>> On Feb 27, 2018, at 16:17, Wayne Thayer via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>>>
>>>> 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.
>>>
>>> Given the misissued certificates in CT under the existing root, I
>> believe this request should be rejected, and a new clean root with audits
>> should be required before moving forward.
>>>
>>
> This course of action doesn't seem consistent with our treatment of the
> many included CAs that have experienced these problems.

Given that revocation checking doesn’t work, and CT doesn’t provide a complete picture, especially without browser enforcement, accepting this root would have the result of exposing Mozilla's users to certificates that are known to be misissued.

I realize that some inclusion requests have been accepted in the past despite existing misissued certificates, but I don’t think that is sufficient justification for continuing to do so. Why shouldn’t we require CAs to cut a new root when the data indicates that accepting the existing root will put users at risk?

Jonathan

[Olfa Kaddachi]

Dear Jonathan,

Given the misissued certificates in CT under the existing root, I believe this request should be rejected, and a new clean root with audits should be required before moving forward.

==>All the misissued certificates have been revoked by the NDCA and new correct ones were substituted to the clients. The TunServerCA2 has been audited yearly by a qualified auditor (LSTI, France) since 2015. A new root will not resolve these problems because all of these issues are a part of the validation process in the RA. That’s why we implemented new technical controls in the TunServerCA2 RA to reject all the CSR that contain any problem of this kind.

The errors in the issued certificates indicate a lack of technical controls in addition to improperly implemented certificate profiles. Given this, an explanation should also be provided of what changes have been made to the issuance environment to ensure these types of mistakes will not happen under the new root.

==>Two technical controls have been implemented:
1. In the RA of the TunServerCA2, a specific coding has been done 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 control that ensures that the SAN entries contain the Common Name has been implemented.
2. An automatic check of TBS certificates using TBSCertificate crt.sh API has been added today and integrated into the issuance
processes. Actually, we followed the suggestion of Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online published in https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/oTQ9OYgS8D4).

There are a bunch of warnings, but these jumped out at me as being very serious:

These certificates have a commonName that is not included as a dNSName SAN:

- https://crt.sh/?id=99182607&opt=cablint

==>We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved since last week by implementing a code that includes automatically the Common Name in the SAN entries. Moreover, all the domain names declared in the certificate (CN and Subject Alternative Names) are checked by the RA according to the 3.2.2.4 of the CAB/Forum.

- https://crt.sh/?id=242366304&opt=cablint
==>We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved since last week by implementing a coding that includes automatically the Common Name in the SAN entries.

This certificate has a SAN with a domain ending in .local, which is a reserved special-use TLD:

- https://crt.sh/?id=79470561&opt=cablint

=> We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved by updating our CSR checker to include the inspection of all the SAN entries declared in the CSR that contain a “.local” in CN or in any of the SAN entries. All of these cases are automatically rejected by the TunServerCA2 RA and the RSC has to generate a new correct CSR.

It’s important to remember that these are only the certificates that we know about via CT. There may be certificates with similar or other issues that are not logged.

==> We have checked all the issued certificates by a daemon which integrates the crt.sh API. This daemon checked the issued certificates one by one in the RA database: There are 15 misissued certificates since the issuance of the TunServerCA2. You find below the serial number of each one, the Error reported by cablint, x509lint and zlint:

41591505131605113993BB051309A9A8

cablint WARNING Certificate Policies should not contain notice references
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR CAs must include keyIdentifer field of AKI in all non-self-issued certificates
zlint ERROR CAs must support key identifiers and include them in all certificates
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint NOTICE Subscriber Certificate: commonName is deprecated.

==> This issue has been fixed after the first audit in august 2015.

41591509041609025C4CD135DDB18DDD

cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Name has deprecated attribute emailAddress
cablint WARNING Special name in SAN
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR DNSNames must have a valid TLD.
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint NOTICE Subscriber Certificate: commonName is deprecated.

==> This certificate has been revoked and a new correct one issued for the client.

4159151023161021A29E9C80721A9E52

cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Extension should be critical for KeyUsage
cablint WARNING Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR Effective October 1, 2016, CAs must revoke all unexpired certificates that contains a reserved IP or internal name.
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint WARNING The keyUsage extension SHOULD be critical
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==> This certificate expired in the 21st of October 2016.

41591603111703106E72B4E6B753F8E3

cablint ERROR commonNames in BR certificates must be from SAN entries
cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Extension should be critical for KeyUsage
cablint WARNING Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint WARNING The keyUsage extension SHOULD be critical
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==>This issue is fixed with the new automatic technicals controls.

41591603301703290E16B4E7B593C481

cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Extension should be critical for KeyUsage
cablint WARNING Name has deprecated attribute emailAddress
cablint WARNING Special name in SAN
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR DNSNames must have a valid TLD.
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint WARNING The keyUsage extension SHOULD be critical
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==> This issue is fixed with the new automatic technicals controls.

4159160412180411114E3A7D0FEDA87E

cablint ERROR BR certificates must not contain rfc822Name type alternative name
cablint ERROR commonNames in BR certificates must be from SAN entries
cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
x509lint ERROR Invalid type in SAN entry
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension
zlint ERROR The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types.
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==> This issue is fixed with the new automatic technicals controls.


415916061017060953E7E2AC04D0FE54

cablint ERROR BR certificates must not contain rfc822Name type alternative name
cablint ERROR commonNames in BR certificates must be from SAN entries
cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
x509lint ERROR Invalid type in SAN entry
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension
zlint ERROR The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types.
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==> This issue is fixed with the new automatic technicals controls.

41591612091712080154AE004DC753E1

cablint ERROR BR certificates must not contain rfc822Name type alternative name
cablint ERROR commonNames in BR certificates must be from SAN entries
cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
x509lint ERROR Invalid type in SAN entry
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension
zlint ERROR The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types.
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==> This issue is fixed with the new automatic technicals controls.

4159170109180108A0A676CA5F5C3F70

cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Extension should be critical for KeyUsage
cablint WARNING Name has deprecated attribute emailAddress
cablint WARNING Special name in SAN
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR DNSNames must have a valid TLD.
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint WARNING The keyUsage extension SHOULD be critical
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==> This issue is fixed with the new automatic technicals controls.

4159170228180227F03C255A5BE535F6

cablint ERROR commonNames in BR certificates must be from SAN entries
cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Extension should be critical for KeyUsage
cablint WARNING Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint WARNING The keyUsage extension SHOULD be critical
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==> This issue is fixed with the new automatic technicals controls.

41591706151906144B98D55B34AD958D

cablint ERROR commonNames in BR certificates must be from SAN entries
cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Extension should be critical for KeyUsage
cablint WARNING Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR Effective October 1, 2016, CAs must revoke all unexpired certificates that contains a reserved IP or internal name.
zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint WARNING The keyUsage extension SHOULD be critical
zlint NOTICE Subscriber Certificate: commonName is deprecated.

==>This issue is fixed with the new automatic technicals controls.

41591710251910243E52C0A86C15D20C

cablint ERROR commonNames in BR certificates must be from SAN entries
cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Name has deprecated attribute emailAddress
cablint INFO TLS Server certificate identified
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==>This issue is fixed with the new automatic technicals controls.

4159180223200222BF945607FA19132A

cablint ERROR commonNames in BR certificates must be from SAN entries
cablint WARNING Certificate Policies should not contain notice references
cablint WARNING Name has deprecated attribute emailAddress
cablint WARNING Trailing whitespace in commonName
cablint INFO TLS Server certificate identified
x509lint ERROR The string contains non-printable control characters
x509lint WARNING explicitText is not using a UTF8String
x509lint WARNING Policy information has qualifier other than CPS URI
x509lint INFO Subject has a deprecated CommonName
x509lint INFO Unknown validation policy
zlint ERROR Characters in labels of DNSNames MUST be alphanumeric, - , _ or *
zlint ERROR DNSNames must have a valid TLD.
zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension
zlint WARNING AttributeValue in subject RelativeDistinguishedName sequence SHOULD NOT have trailing whitespace
zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option
zlint WARNING Compliant certificates should use the utf8string encoding for explicitText
zlint NOTICE Subscriber Certificate: commonName is deprecated.
==> This certificate contained a special caracter in the CSR. This

I just took a closer look at the thread, and it appears that some misissuance was pointed out in July and most of the controls that were suggested as a solution relied on humans. These controls appear to have predictably failed, as multiple misissued certificates are from this fall, well after the fixes should have been in place.

 It’s true that at the beginning only human controls were implemented. However, today many other technical controls are implemented in the TunServerCA2 RA, including:
1. The update of the CSR checker in the RA to reject automatically any CSR that contains a .local, IP address.
2. The certtbslint API is integrated in the TunServerCA2 RA to prohibit the issuance of a certificate which the result has a severity fatal or error.

3. Update in the code of TunServerCA2 RA to include automatically the CN in the SAN entries and to check if it is repeated.

Dear Wayne,

Olfa's most recent response indicates that additional/technical controls were added this week. However, I'm not convinced that they are adequate.

==> We hope that the additional technical controls described above, will convince you and we assure you that these controls will prohibit the occurrence of this type of mistakes from now on.

Olfa

[Anis]

the inclusion of the certification authority in Mozilla is a challenge for the Tunisian government, efforts of more than 4 years of massive work, international audits, the improvement of this authority does not stop to prove the seriousness of the team that works day and night to succeed this challenge, despite the errors we read in this group, but I do not think they are so fatal compared to other errors of other certification authorities, I wish you give this authority a chance as you gave it to others. I found the responsiveness to answer you while remedying any noncompliance encountered, and the transparency that showed by listing the errors encountered and not detected by you.
For me, if I could give my opinion, I would say favorable.
Anis

[Ryan Sleevi]

On Tue, Feb 27, 2018 at 4:17 PM, Wayne Thayer via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

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

Wayne,

Thanks for encouraging this discussion and making sure it reaches a timely
conclusion.

To assist in the review, I've tried to summarize the issues to date:
Incident 1:
- 2016-01-04: As part of the initial Information Gathering, Kathleen Wilson
noted incomplete reply to the list of Mozilla Problematic Practices
regarding DNS names appearing within the subjectAltName. In response, on
2016-01-20, TunRootCA 2 replies -
https://bugzilla.mozilla.org/show_bug.cgi?id=1233645#c5 - stating that they
only use the subjectAlternativeName.
- 2017-02-28: TunRootCA2 violates this requirement -
https://crt.sh/?id=99182607
- 2017-03-03: TunRootCA2 revokes this certificate -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ
- 2017-07-19: Charles Reiss raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ

Incident 2:
- 2016-01-04: TunRootCA2 states their validation practices
- 2016-03-11: TunRootCA2 violates those - https://crt.sh/?id=15126121
- 2016-03-21: TunRootCA2 revokes that certificate -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/4erfw5lwCQAJ
- 2017-07-19: Charles Reiss raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ

Incident 3:
- 2012-07-01: Baseline Requirements effective date, with restrictions on
reserved IPs and internal server names.
- 2015-10-23: TunRootCA2 issues a certificate with a reserved IP address
with a validity period later than 2015-11-1.
- 2016-12-14: TunRootCA2 replaces the certificate
- 2017-07-19: Charles Reiss raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ

Incident 4:
- 2012-07-01: Baseline Requirements effective date, with restrictions on
reserved IPs and internal server names.
- 2017-01-09: TunRootCA2 issues a certificate for an internal server name
- 2017-07-19: Charles Reiss raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/rHhr0-NjBgAJ
- 2017-07-28: TunRootCA2 revokes this certificate

During the discussion of these incidents, TunRootCA2 disclosed that RAs
handled domain name validation, and they used another CA's tools to check
the validity of CSRs. RAs were then empowered to issue the domain
information directly to cause issuance. This suggests a strong lack of
technical controls and understanding by RAs. In response, TunRootCA2
indicated they were deploying a new PKI platform.

On 2018-02-27, TunRootCA2 claims they no longer use DTPs for domain
validation, as per
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ


Incident 5:
- 2017-10-23: TunRootCA2 misissues again -
https://crt.sh/?id=242366304&opt=cablint
- 2018-02-22: Wayne Thayer raises this issue -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ
- 2018-02-27: TunRootCA2 revokes the certificate -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/PCZek1DyAgAJ

Incident 6:
- 2018-02-22: Wayne Thayer completes initial review -
https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/gxLNUDyaBgAJ
- 2018-02-23: TunRootCA2 misissues again -
https://crt.sh/?id=346579818&opt=cablint
- 2018-02-28: TunRootCA2 revokes the certificate


Like Jonathan, I am concerned about the technical controls instituted. From
this thread, it does not give the impression of a technically competent
organization. While the requirements for more detailed. While a number of
these incidents predate the normalized Mozilla Incident Report template (
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y392OBvDvr8/Pf4VCG_-BQAJ
), it was designed precisely to address these issues, and the more recent
replies do not provide particular reassurance that these incidents have
been fully understood.

The failures Wayne raised, particularly around documentation, are
troubling. Equally troubling is that in the course of audits, these issues
were not disclosed - or, if they were, the revocation of the certificate in
response to these incidents was not disclosed to the broader community.

Yet, at the same time, there are still-trusted CAs that have demonstrated
similar issues - although perhaps not to the same degree of becoming a
problematic pattern or an insufficient response - and they still remain
trusted. A recommendation to instill trust in such a new CA, one that has
demonstrated problematic patterns already, suggests that CAs may continue
to display such patterns without risk of distrust - which would overall be
harmful. Yet, if the recommendation is not to trust, what should the
remediation steps be to find a positive path forward?

I do not believe this CA should be trusted, given these patterns. I do not
feel the evidence supports a confident understanding of the critical role
that CAs play, nor an understanding of the technical risks and mitigations.
While it is good that TunRootCA2 has adopted practices such as linting, it
simply moves the problem to be more opaque - how many certificates fail
that check will not be known, nor will it be known how many failures are
now for policy reasons, rather than technical reasons. The community
largely relies on the information provided in audits - with the
expectations that CAs will self-report and self-disclose these issues - and
yet the audits not calling this information out is deeply worrying, both as
to quality and to completeness.

For this reason, I recommend this request be denied, and, as suggested
elsewhere, a new root be created. Further, I recommend that a new auditor
be selected, with the clear expectation and understanding that the
Government of Tunisia will promptly report any and all certificates that
are issued under this new root that have failed either the technical
controls or policy controls, in addition to revocation, to both their
auditor and to the Mozilla Community. Similarly, that there be a clear
expectation that any suspension of certification under the ETSI framework,
or any remedial actions to be taken as part of the annual audit prior to
the issuance of a certificate, be promptly and publicly disclosed.

These recommendations are based on the balance of the potential global risk
and the potential limited use that the existing CA is intended for.

[Paul Kehrer]

In addition to the issues Ryan has listed, during the root inclusion
process multiple issues with their OCSP responder and CRL endpoints were
observed and fixed only after the flaws were documented in the bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=1233645).

I believe any CA seeking inclusion should be capable of doing the sorts of
checks the Mozilla community performs long prior to seeking root inclusion.
Failures like this inspire no confidence in the technical acumen of the
administrators and I do not believe this root inclusion request should be
accepted.

-Paul

[syri...@gmail.com]

We do use another CA's tool to check the validity of CSR. As we do use the cr.sh tool developed also by another CA to check pre-certificate before issuance. So why is using a tool for checking CSR is problematic whereas using the crt.sh is approved ? The point here is to use an efficient tool to perform certificate checks regardless of the CA that owns it. Besides, given that the Tunisian government does not have a Mozilla trusted CA, we are forced to buy SSL certificates for Tunisian e-commerce websites from the CA who owns the CSR check tool that we use.
In order to have a consistent RA process, we use the CSR check tool to by from that trusted CA and also to check our own certificates

Since there are other still-trusted CAs that has the same problems, why is that the Tunisian CA treated with presumption of untrustworthiness . The decision-making process should be objective and fair for all CAs.

>
> I do not believe this CA should be trusted, given these patterns. I do not
> feel the evidence supports a confident understanding of the critical role
> that CAs play, nor an understanding of the technical risks and mitigations.
> While it is good that TunRootCA2 has adopted practices such as linting, it
> simply moves the problem to be more opaque - how many certificates fail
> that check will not be known, nor will it be known how many failures are
> now for policy reasons, rather than technical reasons. The community
> largely relies on the information provided in audits - with the
> expectations that CAs will self-report and self-disclose these issues - and
> yet the audits not calling this information out is deeply worrying, both as
> to quality and to completeness.

During all the Mozilla review process, our team showed a willingness and a seriousness in the treatment of these incidents. We have implemented all the technical checks required to prevent the occurrence of other miss- issued certificates (pre-issuance linting). We have also reported all missiussed certificates of our root CA since its creation. There are in total 15 mississued certificates as listed Olfa's last message https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/fFcZ3SepAQAJ

>
> For this reason, I recommend this request be denied, and, as suggested
> elsewhere, a new root be created. Further, I recommend that a new auditor
> be selected, with the clear expectation and understanding that the
> Government of Tunisia will promptly report any and all certificates that
> are issued under this new root that have failed either the technical
> controls or policy controls, in addition to revocation, to both their
> auditor and to the Mozilla Community. Similarly, that there be a clear
> expectation that any suspension of certification under the ETSI framework,
> or any remedial actions to be taken as part of the annual audit prior to
> the issuance of a certificate, be promptly and publicly disclosed.
>

The auditor who performed the conformity check of our CA is a Qualified Auditor as defined in the Baseline Requirements section 8.2. and required by Mozilla. I believe that your recommendation of selecting a new auditor is unacceptable. Calling into question the accreditation of the auditor is exceeding limits

> These recommendations are based on the balance of the potential global risk
> and the potential limited use that the existing CA is intended for.

I do believe that your recommendations are alarmist and lack of objectivity considering the potential limited use of our national CA .

[Ryan Sleevi]

On Fri, Mar 9, 2018 at 6:51 PM, syrine.tl--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
>
> We do use another CA's tool to check the validity of CSR. As we do use the
> cr.sh tool developed also by another CA to check pre-certificate before
> issuance. So why is using a tool for checking CSR is problematic whereas
> using the crt.sh is approved ? The point here is to use an efficient tool
> to perform certificate checks regardless of the CA that owns it. Besides,
> given that the Tunisian government does not have a Mozilla trusted CA, we
> are forced to buy SSL certificates for Tunisian e-commerce websites from
> the CA who owns the CSR check tool that we use.
> In order to have a consistent RA process, we use the CSR check tool to by
> from that trusted CA and also to check our own certificates
>

It is important to highlight here not that it's intrinsically bad to use
another tool - indeed, open-source and information sharing are good. The
point is that your own examination of your software and practices was so
deficient and lacking that you were unable to do even the most basic
operations of a CA correctly, and having misrepresented to Mozilla what
degree of checking you were doing.

A CSR, however, is such a basic check that even limited technical
competency can do this. That this is relying on an online check is deeply
disappointing and highlights a lack of technical competency - which the
issues bore out - including the OCSP failures that seemingly still persist.

Recall - the tool was written by a recently added CA, because they simply
read the specifications and wanted to ensure their systems followed them.
It would appear TunRootCA2 either did not read the specifications, or could
not be bothered to read them, or simply relies on off-the-shelf software to
be a CA - when so much more is expected.

> > Yet, at the same time, there are still-trusted CAs that have demonstrated
> > similar issues - although perhaps not to the same degree of becoming a
> > problematic pattern or an insufficient response - and they still remain
> > trusted. A recommendation to instill trust in such a new CA, one that has
> > demonstrated problematic patterns already, suggests that CAs may continue
> > to display such patterns without risk of distrust - which would overall
> be
> > harmful. Yet, if the recommendation is not to trust, what should the
> > remediation steps be to find a positive path forward?
>
>

> Since there are other still-trusted CAs that has the same problems, why is
> that the Tunisian CA treated with presumption of untrustworthiness . The
> decision-making process should be objective and fair for all CAs.
>

You can see I specifically addressed that. To repeat:
1) The Tunisian CA has demonstrated a problematic pattern of misissuance
and misconfiguration that has not, even until 2018-02-22, the most recent
review, stopped.
2) If we believe in a fair and objective process, then the Tunisian CA will
make the ecosystem worse by accepting, by setting a new low bar of
competency and correctness.

So, the fair and objective basis is to look at the pattern and trends - one
which would reasonably start a discussion of possible distrust - and simply
say the risk is not worth it.

> > I do not believe this CA should be trusted, given these patterns. I do
> not
> > feel the evidence supports a confident understanding of the critical role
> > that CAs play, nor an understanding of the technical risks and
> mitigations.
> > While it is good that TunRootCA2 has adopted practices such as linting,
> it
> > simply moves the problem to be more opaque - how many certificates fail
> > that check will not be known, nor will it be known how many failures are
> > now for policy reasons, rather than technical reasons. The community
> > largely relies on the information provided in audits - with the
> > expectations that CAs will self-report and self-disclose these issues -
> and
> > yet the audits not calling this information out is deeply worrying, both
> as
> > to quality and to completeness.
>

> During all the Mozilla review process, our team showed a willingness and
> a seriousness in the treatment of these incidents. We have implemented all
> the technical checks required to prevent the occurrence of other miss-
> issued certificates (pre-issuance linting). We have also reported all
> missiussed certificates of our root CA since its creation. There are in
> total 15 mississued certificates as listed Olfa's last message
> https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/
> fFcZ3SepAQAJ

Disclosure is not something that is exceptional - it is the minimum
required of a CA. The fact that new misissued certificates continued to be
issued throughout the process, since its inception, shows a problem. That
Baseline Requirements dates continued to be missed is equally problematic -
and shows a process failure at an organization that is not mature enough
yet to operate a publicly trusted CA.

Further, the selection of your audit scheme is one that lacks sufficient
transparency, given the issues, for the degree of trust being requested -
both to the community and the auditor.

> The auditor who performed the conformity check of our CA is a Qualified
> Auditor as defined in the Baseline Requirements section 8.2. and required
> by Mozilla. I believe that your recommendation of selecting a new auditor
> is unacceptable. Calling into question the accreditation of the auditor is
> exceeding limits
>

If you will look throughout this archives, you will find auditors routinely
questioned, and some explicitly prohibited as unacceptable. Similarly,
there are some auditors who, due to the quality of the audits relative to
the risk overseen as part of their examination, are no longer accepted.

The reality is that for several years, you have had critical control
failures. Under an ETSI scheme, that can result in the suspension of your
certificate, but, unfortunately, under ETSI, it can be reinstated after
remediation. Given that the auditor has not disclosed whether any
suspensions took place - or if the Tunisian Government even reported these
material findings to their auditors - we must naturally question the entire
sequence of audits since this roots foundation.

Given that, the only potential risk reduction the community has is to start
over, such that the point of trust begins from a known trustworthy time
period, without there being a continuing question as to what other
misissuance has been conducted in the past 2+ years.

> > These recommendations are based on the balance of the potential global
> risk
> > and the potential limited use that the existing CA is intended for.

> I do believe that your recommendations are alarmist and lack of
> objectivity considering the potential limited use of our national CA .

Everything I stated was supported by the facts. Similarly, given that trust
in a CA is global, and amounts to giving the Tunisian Government keys to
the Internet. In Particular, Section 2.1 details that CAs must provide
"some service relevant to _typical_ users of our software products"
(emphasis added). Given the global nature of the Internet, a CA limited to
a single country is arguably not typical, if the certificates it issues and
people consume are limited to that. Similarly, if the purpose is to provide
certificates that will be 'used' (relied upon) by only a limited amount of
users, then, by definition, they are not typical users.

As a CA, however, you surely understand the process of risk assessment and
mitigation. For example, it's unlikely that your CA is hardened against
solar radiation causing bitflips within critical systems. Why is this
acceptable? Because we know the probability of such flips is low, and while
the consequence of such a flip is high, the cost of protecting and
shielding against such stray neutrinos is prohibitive to the risk.
Conversely, we know that jumping from plane 39,000 meters in the sky is
possible - as Felix Baumgartner showed - yet the risk is incredibly high in
doing so. One must mitigate that with ample and careful training,
otherwise, it's foolishness to just do it.

Trusting a CA is like that. Operating a CA requires a high degree of
competence and excellence, and each CA applying for inclusion should be as
or more competent, as or more skilled, and as or more valuable, as they
otherwise bring the ecosystem down rather than lifting it up.

[syri...@gmail.com]

your effort lifting up CA ecosystem will not pay off by rejecting new CA application.
You should also consider rejecting trusted CAs that still have miss-issuance concerns despite their well-established certificate issuance process and this is a fact. You have much more renewal request than new inclusion

If you do have a list of unacceptable auditors, it should be clearly stated in Mozilla Policy so that all CAs will be informed.
Running through the archives is not considered an appropriate way of information for a selection process as demanding as this.

Having a fair and objective process requires applying the same acceptance or rejection criteria to all CAs.
Otherwise it will be a double standards process.
Anyway, we are looking forward to get the official outcome of Mozilla, and we will spare no effort to be listed among Mozilla Trusted CA

[Anis]

Hi Ryan

just I want to remind you of these discussion and your opinion below
in some was different than you say here !!!

https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/CfyeeybBz9c
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/K3sk5ZMv2DE

and
https://misissued.com/batch/1/

can you explain please
Anis

[Ryan Sleevi]

I already have, but it seems you don't understand how a pattern of
misissuance is problematic. I'm glad you agree that there's a pattern of
misissuance, though - it does make it much easier to argue that the CA
should not be trusted when there's agreement that they're not able to
adhere to the Baseline Requirements.

[Ryan Sleevi]

> your effort lifting up CA ecosystem will not pay off by rejecting new CA
> application.
>

Sure it is, when the CA has a pattern of misissuance.

> You should also consider rejecting trusted CAs that still have
> miss-issuance concerns despite their well-established certificate issuance
> process and this is a fact. You have much more renewal request than new
> inclusion
>

That has happened as well - if you look at PROCert for example.

> If you do have a list of unacceptable auditors, it should be clearly
> stated in Mozilla Policy so that all CAs will be informed.
> Running through the archives is not considered an appropriate way of
> information for a selection process as demanding as this.
>

This is covered in Section 2.3 of the Policy.

> Having a fair and objective process requires applying the same acceptance
> or rejection criteria to all CAs.
> Otherwise it will be a double standards process.
>

Section 7.1 of the policy covers this.

""We will determine which CA certificates are included in Mozilla's root
program based on the benefits and risks of such inclusion to typical users
of our products. ""

Inclusions are not guaranteed - they are a balancing act of risk.

""We will make such decisions through a public process, based on objective
and verifiable criteria."

It is objective and verified that the Tunisian Government has had a
problematic series of misissuances, up to and including this past month,
and has consistently failed to ensure proper controls are in place.
Further, it is objective and verifiable, these were readily detectable by
the Tunisian Government, but weren't noticed as such until the issue was
raised. These included issues after the Tunisian Government reported them
remediated.

Further, based on does not mean limited to.

""We reserve the right to not include certificates from a particular CA in
our root program.""

Any root request can be rejected, for any reason, or not reason at all, at
any time.

> Anyway, we are looking forward to get the official outcome of Mozilla, and
> we will spare no effort to be listed among Mozilla Trusted CA

Can you explain your motivations for this? Such a globally trusted root
carries with it profound security risk to the ecosystem. What is the
overall goal for such trust, given that it does not in any way reduce risk
of distrust. If anything, it increases the risk for all Subscribers and
Relying Parties, given the pattern of misissuances shown and the apparent
lack of technical expertise to support and protect that infrastructure.

[Anis]

Hi Ryan
I am so sorry but is the same error.
CN NAME NOT INCLUDE IN THE SAN
Local IP ADRESS
Policy not upto date ....
Is clear for me and i understand.
All this error became from approuved authority. Is the risk no.
Then The ecosystem is not protected!!!!!
ANIS

[Ryan Sleevi]

These responses demonstrate why the request is troubling. They attempt to
paint it as "other people do it"

The risk of removing an included CA must balance the ecosystem disruption
to those non-erroneous certs, while the risk to ecosystem inclusion needs
to balance both the aggregate harm to the ecosystem (through lowered
standards) and the risk to the ecosystem of rejecting the request (of
which, until inclusion is accepted, is low)

The pattern of issues - particularly for a new CA - is equally problematic.
A CA, especially in light of the public discussions, should not be having
these issues in 2018, and yet, here we are.

We are in agreement on the objective facts - namely, that there is a
prolonged pattern of issues - and the criteria - namely, that CAs should
adhere to the policy in requesting inclusion. A strict adherence to those
objectives would be to fully deny the request. It sounds like where we
disagree, then, is not in the objective facts and criteria, but rather,
where the evaluation of that leaves relative to risk.

The position I am advocating is that, even if these individual matters
might be seen as less risky, especially, as has been mentioned, this CA is
"only" intended for .tn for the most case, the existence of such a pattern
(and the means of acknowledging-but-not-resolving-completely these issues)
is indicative that there will continue to be serious issues, and that the
risk is not simply limited to .tn, but threatens global Internet stability
and security. Given that the number of certificates being issued are, from
your own descriptions, aimed to be measured in the hundreds, further
highlights that the risk is rather substantial.

On Mon, Mar 12, 2018 at 2:14 AM, Anis via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Hi Ryan

[taher....@itgrapes.com]

Dear All,

Thank you for your detailed description of your concerns with the Tunisian CA.

I have been one of those guys that developped IT communities for more than 7 years in Tunisia, starting by Tunandroid (Tunisian Android Community), Google Developers Groups, organized the best Software Freedom Day in 2012, supported local Mozilla Community 2013-2014, GDG Country Champion in Tunisia 2012-2014 and represented the IT community in law projects to help developing the local ecosystem since 2013 and still.

The reason why I am telling you this is to assure you that I perfectly understand what a community is about: helping each others, making things better and sharing knowledge. Things have always been inclusive.

The Tunisian national digital certification agency has been under pressure for more then 3 years to have its CA certificates recognized by Mozilla and they did all which is possible to do to have the best security standards when they got audited and criticized and they have alwyas been very reactive.

I would highlight that we are speaking here about a national CA which is completely different from any other type of agencies. We are speaking about blocking a whole country from advancing.

It's already unacceptable to have such long process for country CA, if we have to fail and restart we have to fail quickly because time is very valuable. We can't afford restarting the process if the Tunisian CA gets rejected but instead I think anything can be corrected and updated this is how I.T. works.

Generally speaking I would insist on the fact that for country CAs, some kind of fast tracks should be established because the impact of time losing at country level is highly expensive.

I have no doubt about your support and hope you can help my country move forward and I am sure that the team in our national digital certification agency will do its best to assure you about how seriously we are working to make users globally trusting our CA protected.

Best regards,

Taher Mestiri

[Tim Hollebeek]

Nobody is blocking any country from advancing. There are no Mozilla rules
that prevent any country from having the best CA on the planet. If a bunch
of penguins at McMurdo station run an awesome CA, I'll ask some hard
questions about how they meet the OCSP requirements with their limited
bandwidth, but if they have good answers, I'm fine with internet security
now being penguins all the way down.

If you want your certificates to be accepted everywhere on the planet, you
need to follow the same rules as everyone else on the planet. No fast
tracks
or special rules for anyone, no matter how special they feel they are.

The same rules for everyone is the only sane route forward. Governments
often believe they deserve special treatment, and they may have the ability
to force that to be true within their own country, but that doesn't make it
a good idea for Mozilla.

-Tim

> https://clicktime.symantec.com/a/1/SIE5l2_N73ITS6JLILauNCMnmHnZxaKgs
> > >
> B01Two7VeY=?d=_v7KIjMsihDpLSiLJBAouCL3n_o9AK9VmyEb8nG9Z6gdhNh7Je
> RjHh
> > > 4qQ-
> OkZhRzqc_LUyI5vA9nghhhxTQxpmNGZCpSdBDmXod6aFvNzmG8ktYaF2q-
> Qmwfb_
> > >
> hdD5G7WxIEEJYkOVWJtCVGnyYl4DYpItqhBt0_Spz4X3UrDsaE6fDsXoeWpIrAn2
> qtCx
> > > IGVYGc88xGz0AavDxY-Kk0dOryc8KT6eeUumJHpgi--
> TH7yOuC30DzNBDRR0DQ4OkLgL
> > > blPHsYqV9AyzTt51I8fipD7X-_VDXq-pBCO9ThUQKAy3HofPSZWmSYwzlT-
> okF7gL-83
> > > V1pdtjN1Zv-eJjBDGaUiulNrIXzrrD_zsO2mpWSnZw_cXUFHx-
> dEMC9hteXMj9MuVDQR
> > > 8xNV-
> b9wLkiki2ABTG5srScX9qnFYdkQyEJ2uAIgg8l5p6LenynXdVYGqZPbQORbkf&u
> > > =https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

> > >
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/SIE5l2_N73ITS6JLILauNCMnmHnZxaKgsB
> 01Two7VeY=?d=_v7KIjMsihDpLSiLJBAouCL3n_o9AK9VmyEb8nG9Z6gdhNh7JeR
> jHh4qQ-
> OkZhRzqc_LUyI5vA9nghhhxTQxpmNGZCpSdBDmXod6aFvNzmG8ktYaF2q-
> Qmwfb_hdD5G7WxIEEJYkOVWJtCVGnyYl4DYpItqhBt0_Spz4X3UrDsaE6fDsXoe
> WpIrAn2qtCxIGVYGc88xGz0AavDxY-Kk0dOryc8KT6eeUumJHpgi--
> TH7yOuC30DzNBDRR0DQ4OkLgLblPHsYqV9AyzTt51I8fipD7X-_VDXq-
> pBCO9ThUQKAy3HofPSZWmSYwzlT-okF7gL-83V1pdtjN1Zv-
> eJjBDGaUiulNrIXzrrD_zsO2mpWSnZw_cXUFHx-dEMC9hteXMj9MuVDQR8xNV-
> b9wLkiki2ABTG5srScX9qnFYdkQyEJ2uAIgg8l5p6LenynXdVYGqZPbQORbkf&u=h
> ttps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[taher....@itgrapes.com]

Dear Tim,

Not sure your penguin-related example would make the picture sharper or ideas clearer.

I asked about fast tracks because it's taking long time to get things processed related to the fact that all this is running by a community and I think it can be great to brainstorm ways to handle maybe work overloads even through paid assessments for example.

I don't think it's worth to answer either your comments about special treatment, as no one has asked for it apart of speeding the process which is not special treatment but respect for users and community, or about how special we feel we are, etc.

I am not a member of the government, I consider myself member of an open global IT community, including but not limited to mozilla, that shares same values of respect and mutual help. I find your answer a bit aggressive but, anyway, maybe I was wrong about something that made you answer the way you did... That was not my intention.

I hope that you guys can give us a list of major corrections or verifications to do within a certain limited time to give us the opportunity to get our CA approved without restarting the whole process.
I hope this is not considered as special treatment as maybe I don't know what kind of support you provide in such cases.

At the end, I would reiterate that I shared personal opinions and I am not member of the government as this is a public open discussion and I don't want that my opinion impacts negaively the decision taking.

Best,

Taher.

[Tim Hollebeek]

My reaction was primarily based on the following suggestion:

"Generally speaking I would insist on the fact that for country CAs, some
kind
of fast tracks should be established because the impact of time losing at
country level is highly expensive."

The answer is, and must be, no.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of
> taher.mestiri--- via dev-security-policy
> Sent: Monday, March 12, 2018 10:54 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: TunRootCA2 root inclusion request
>

> 01Two7VeY=?d=_v7KIjMsihDpLSiLJBAouCL3n_o9AK9VmyEb8nG9Z6gdhNh7JeR
> > > jHh4qQ-
> > > OkZhRzqc_LUyI5vA9nghhhxTQxpmNGZCpSdBDmXod6aFvNzmG8ktYaF2q-
> > >
> Qmwfb_hdD5G7WxIEEJYkOVWJtCVGnyYl4DYpItqhBt0_Spz4X3UrDsaE6fDsXoe
> > > WpIrAn2qtCxIGVYGc88xGz0AavDxY-Kk0dOryc8KT6eeUumJHpgi--
> > > TH7yOuC30DzNBDRR0DQ4OkLgLblPHsYqV9AyzTt51I8fipD7X-_VDXq-
> > > pBCO9ThUQKAy3HofPSZWmSYwzlT-okF7gL-83V1pdtjN1Zv-
> > > eJjBDGaUiulNrIXzrrD_zsO2mpWSnZw_cXUFHx-
> dEMC9hteXMj9MuVDQR8xNV-
> > >

> b9wLkiki2ABTG5srScX9qnFYdkQyEJ2uAIgg8l5p6LenynXdVYGqZPbQORbkf&u=h
> > > ttps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/nHUh-
> lJOoYzWmqArkcREwWBrZWYyOaVA2s97XrxQ1Lo=?d=_Ksp3jzfb-
> qUGldFwHnLI7Gh8laYfWJbW3s2plErXxLPJ9nMjTEi_kxgcMXrPIGXR7eUhmEcB3
> VF23swsr6Lt0xMBGsucjBTi-
> rNU1bxJUqtaOox_xJ_42vODF8APtnbCkxgwyRZcH2atGzyp-
> zxYQ7Duaj2weCMW1-
> YcNH6ZJmWEnKCahuj5deFEFYHlfdKAwoUDO4wR6Le4a3KmukqzSmcPwdLMc_
> 7nVnAtkvJZrT5pT4YWIOvOZHzr1KnHh6sHwiCtxxnFIwTg4yb3Yk8U7I-
> PASipEWxymCoZqMT0jN2JTqLcQZLsr0ccPpCuHVTSIJEi3bIptROALcR33xjSmCPY
> JvUyGfUIg7af42Xz5EtjMwxx9ZGVTzv_JM0MhEF8AoIy9TTDt1cNOharymreT58
> Wg4aasxlyOdfVbnEo2IJW7fpcTXo2G2HmXL2j19xMMPnW_AEg54V7w%3D%3
> D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Ryan Sleevi]

On Mon, Mar 12, 2018 at 10:53 PM, taher.mestiri--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I asked about fast tracks because it's taking long time to get things
> processed related to the fact that all this is running by a community and I
> think it can be great to brainstorm ways to handle maybe work overloads
> even through paid assessments for example.
>

I think very few members of this community would see the time it takes to
get a publicly trusted CA included as a problem. Indeed, it's actually
rather quite the opposite - the time to get a CA included is likely not
long enough, the time to get a CA removed is likely not fast enough, and
the time for certificates to expire is not short enough.

> I hope that you guys can give us a list of major corrections or
> verifications to do within a certain limited time to give us the
> opportunity to get our CA approved without restarting the whole process.
> I hope this is not considered as special treatment as maybe I don't know
> what kind of support you provide in such cases.
>

I shared a number of recommendations, based on the specific incidents
highlighted, and the risks they posed. Restarting the whole process is
something that has been requested of other CAs with similar deficiencies,
because in a large part, this whole ecosystem is based on trust. For a CA
to request inclusion, but not demonstrate sufficient technical
understanding on how to manage that trust, is reasonable grounds to not
trust them. Trust is not automatically granted and then slowly removed -
rather, it's slowly earned, based on the quality of character and continued
display of trustworthiness. In the case of this inclusion request, both the
practices and the policies demonstrated significant gaps from what would be
expected.

An alternative answer might be to deny inclusion for 2 or more years, since
that is often how long it can take to build an organization with both the
technical expertise and the implementation to support it, as even the
'best' CAs can attest. However, I tried to offer a more targeted set of
suggestions, based on the specific deficiencies that caused trust to be
undermined here. While these are only my suggestions, it highlights the
problematic patterns on display.

In the end, I'm not sure why the Tunisian Government feels it should run a
publicly trusted CA, so I don't know if there are other alternatives to
suggest that might offer a more expedient, more secure, more reliable basis
for trust. If that was to be shared, perhaps there are other solutions that
may work. In the absence of that, the failures at the basic and core
competencies of being a publicly trusted CA should be concerning.

[syri...@gmail.com]

Dear Wayne,
Based on the long discussion regarding our request, I would appreciate having your opinion on the following:
Move to a new root based on EJBCA (Enterprise License) and conduct a new audit with a new auditor as required by Mozilla and the BR.
We are ready and we do commit to do these steps in 6 months. As we hope that you would accept to resume the inclusion process from this point.
We are looking forward to hearing from you.

Syrine.

[okaphone.e...@gmail.com]

Do consider that it only makes sense to start with a new root (and do the required audits etc.) when you are sure that all problems have been fixed, in such a way that they (and others like them) will not happen again.

Because if that isn't the case, the new root will soon be as useless as trust-anchor as the old one. The fastest way forward is probably to not try to do it quickly.

CU Hans

[Wayne Thayer]

I think this discussion has made it clear that the request for inclusion of
the TunRootCA2 root should be denied.

CAs inherently must be trusted, and trust must be earned. A CA can't simply
fix one problem after another as we find them during the inclusion process
and expect to be rewarded for their reactive efforts, nor can they ignore
program requirements until the time comes to get their inclusion request
approved. Recurrences of the same issue that the CA claimed to have fixed
are especially damaging.

As Ryan mentioned, section 7.1 of the Root Store Policy states that "We

will determine which CA certificates are included in Mozilla's root program
based on the benefits and risks of such inclusion to typical users of our

products." While I believe the decision to deny this request is fully
supported by that policy statement, I would be interested to know if anyone
thinks there are ways we could make our expectations clearer in this regard.

Regarding next steps, the Tunisian Government is welcome to submit a new
root (using a newly generated key pair) for inclusion. The current bug may
be reopened and used for the new request, but it will still need to go
through the entire process. The only real "shortcut" in the inclusion
process - as has been demonstrated by a few CAs recently who completed the
process in 9-18 months) - is to have all the requirements fully met before
the request is reviewed. Tests that are performed during the information
verification process are documented [1], and every previous inclusion
request is publicly accessible in Bugzilla and archives of this list, so
this really shouldn't be as difficult as it seems to be.

I agree with the comments Hans made on the desire to rapidly move through
the process with the new request. Establishing confidence in a CA takes
time, and attempts to move too quickly to regain trust can be extremely
counterproductive (e.g. StartCom).

Regarding the choice of auditor, Mozilla has not disqualified LSTI and so
will not require a different auditor to be selected if/when a new root is
submitted. However, given the concerns that have been raised with the
current audits, choosing a different auditor may help to gain the
confidence of the community in the new root and in the Tunisian Government
CA.

- Wayne

[1] https://wiki.mozilla.org/CA:TestErrors

On Thu, Mar 15, 2018 at 5:44 AM, okaphone.elektronika--- via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com wrote:

> Do consider that it only makes sense to start with a new root (and do the
> required audits etc.) when you are sure that all problems have been fixed,
> in such a way that they (and others like them) will not happen again.
>
> Because if that isn't the case, the new root will soon be as useless as
> trust-anchor as the old one. The fastest way forward is probably to not try
> to do it quickly.
>
> CU Hans

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>