Propose Removal of E-Guven root

[Kathleen Wilson]

All,

I propose removing the following root cert from NSS, due to inadequate
audit statements.

Issuer:
CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
O = Elektronik Bilgi Guvenligi A.S.
C = TR

SHA-1 Fingerprint:
DD:E1:D2:A9:01:80:2E:1D:87:5E:84:B3:80:7E:4B:B1:FD:99:41:34


https://bugzilla.mozilla.org/show_bug.cgi?id=476428#c41
==
I see the following problems with the attached audit statement:

1) It says: "The last supervision of E-Guven was held by ICTA between
21st and 25th of October, 2013."
Mozilla policy requires an annual audit, so this doesn't meet Mozilla's
requirement.

2) The criteria listed are: "ETSI TS 101 456" and "ETSI TS 102 023".
The websites trust bit is enabled for this root, so Mozilla requires an
audit according to one of the following criteria:
-- ETSI TS 102 042 V2.3.1 or later version, Policy requirements for
certification authorities issuing public key certificates (as applicable
to the "EVCP" and "EVCP+" certificate policies, DVCP and OVCP
certificate policies for publicly trusted certificates - baseline
requirements, and any of the "NCP", "NCP+", or "LCP" certificate policies);
OR
-- WebTrust "Principles and Criteria for Certification Authorities 2.0"
or later and "SSL Baseline Requirements Audit Criteria V1.1" (as
applicable to SSL certificate issuance) in WebTrust Program for
Certification Authorities;

REFERENCE:
https://wiki.mozilla.org/CA:BaselineRequirements#ETSI_BR_Audit_Statement.2FCertificate
==

I have been communicating these problems to E-Guven for a few months,
and I have seen no progress in remediation.

Richard Barnes has verified that there's minimal compatibility impact to
removing this root certificate. Current telemetry shows that this root
has been responsible for 9.57k out of 9.4B validations, or about one in
a million.

I will greatly appreciate your constructive and thoughtful input
regarding this proposed root removal.

Kathleen

[Daniel Micay]

On 18/03/15 03:40 PM, Kathleen Wilson wrote:
>
> Richard Barnes has verified that there's minimal compatibility impact to
> removing this root certificate. Current telemetry shows that this root
> has been responsible for 9.57k out of 9.4B validations, or about one in
> a million.

The trust store policy could be changed to maintain a different level of
accountability based on prevalence of certificates signed with the root
certificate, but that's not the case right now. I don't think it should
be taken into account in these decisions. Doing otherwise would be a
concession that large CAs aren't going to be held accountable, and
taking away that risk also removes that incentive to follow the rules.

[David E. Ross]

The overriding issue is trust. If a certification authority (CA) cannot
comply with Mozilla's basic requirements -- which are intended to create
trust -- I cannot trust that CA's root. Remove it.

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.

[Matt Palmer]

On Wed, Mar 18, 2015 at 12:40:11PM -0700, Kathleen Wilson wrote:
> I propose removing the following root cert from NSS, due to inadequate audit
> statements.

If they can't follow the rules, they need to go.

- Matt

[Kurt Roeckx]

On 2015-03-18 20:40, Kathleen Wilson wrote:
> I propose removing the following root cert from NSS, due to inadequate
> audit statements.

Yes, they should get removed.


Kurt

[Gervase Markham]

On 18/03/15 20:20, Daniel Micay wrote:
> The trust store policy could be changed to maintain a different level of
> accountability based on prevalence of certificates signed with the root
> certificate, but that's not the case right now. I don't think it should
> be taken into account in these decisions. Doing otherwise would be a
> concession that large CAs aren't going to be held accountable, and
> taking away that risk also removes that incentive to follow the rules.

It would be simply wrong to write that we don't care about
compatibility, because we do. That doesn't mean we won't take action,
but it might mean we took different action. For example, in this sort of
case, if this root was popular, we might make extra engineering effort
to write a date-based cutoff into the code, preventing them from issuing
new certs but keeping existing ones working. But that seems unnecessary
given the data supplied by Richard.

Anyway... I agree with the immediate removal. I am sure Kathleen has
been more than patient with them.

Gerv

[Kathleen Wilson]

On 3/18/15 12:40 PM, Kathleen Wilson wrote:
> All,
>
> I propose removing the following root cert from NSS, due to inadequate
> audit statements.
>
> Issuer:
> CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
> O = Elektronik Bilgi Guvenligi A.S.
> C = TR
>
> SHA-1 Fingerprint:
> DD:E1:D2:A9:01:80:2E:1D:87:5E:84:B3:80:7E:4B:B1:FD:99:41:34
>

I have filed the bug for the corresponding code changes:
https://bugzilla.mozilla.org/show_bug.cgi?id=1145270

Thanks,
Kathleen

[Peter Kurrasch]

Would it be an option to remove the trust bits on the root first and then later on remove it from the store entirely? 

While I agree that action is warranted my concern is that the consequence of any action taken will be borne out by the customers of this CA and their users. We are essentially saying any of those web sites will, at best, get a cert warning. Some users of course will be able to add an exception. If the site happened to use HSTS, though, there ‎is no recourse and so Mozilla will have created a DoS situation against those sites. 


Along these lines, does Mozilla have any resources at its disposal to help get the word out that this action is in the works? I'm sure web site owners would appreciate having a chance to acquire new certs before their sites go black.


  Original Message  
From: Kathleen Wilson
Sent: Thursday, March 19, 2015 1:31 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Propose Removal of E-Guven root

On 3/18/15 12:40 PM, Kathleen Wilson wrote:

> All,
>
> I propose removing the following root cert from NSS, due to inadequate
> audit statements.
>
> Issuer:
> CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
> O = Elektronik Bilgi Guvenligi A.S.
> C = TR
>
> SHA-1 Fingerprint:
> DD:E1:D2:A9:01:80:2E:1D:87:5E:84:B3:80:7E:4B:B1:FD:99:41:34
>

I have filed the bug for the corresponding code changes:
https://bugzilla.mozilla.org/show_bug.cgi?id=1145270

Thanks,
Kathleen

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Kathleen Wilson]

On 3/19/15 11:51 AM, Peter Kurrasch wrote:
> Would it be an option to remove the trust bits on the root first and then later on remove it from the store entirely?
>

I don't see how removing the trust bits instead of removing the root
helps. In both cases the user will see the over-rideable "This
Connection is Untrusted" error with (Error code: sec_error_unknown_issuer)

Kathleen

[Peter Bowen]

On Wed, Mar 18, 2015 at 12:40 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> I propose removing the following root cert from NSS, due to inadequate audit
> statements.
>
> Issuer:
> CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
> O = Elektronik Bilgi Guvenligi A.S.
> C = TR

In the Pilot CT log, which includes every certificate that the Google
crawler has seen, I found 19 unexpired certificates issued by this CA.
Their subjects are as follows (using the default OpenSSL DN to string
method):

Subject: C=AU, ST=Some-State, O=Tejarat Bank, CN=*.tejaratbank.net
Subject: CN=mail.iksv.org, OU=IT, O=ISTANBUL KULTUR VE SANAT VAKFI,
L=ISTANBUL, ST=SISHANE, C=TR
Subject: CN=mail.immib.org.tr, OU=B\xC4\xB0LG\xC4\xB0
\xC4\xB0\xC5\x9ELEM, O=\xC4\xB0STANBUL MADEN VE METALLER \xC4\xB0HR.
B\xC4\xB0RL\xC4\xB0\xC4\x9E\xC4\xB0 GENEL
SEKRETERL\xC4\xB0\xC4\x9E\xC4\xB0, L=\xC4\xB0STANBUL /
YEN\xC4\xB0BOSNA, ST=BEH\xC3\x87EL\xC4\xB0EVLER, C=TR
Subject: C=TR, O=EBI, OU=TrustCenter, CN=ragknesi2.e-guven.com
Subject: C=TR, O=E-G\xC3\xBCven Elektronik Bilgi
G\xC3\xBCvenli\xC4\x9Fi A.\xC5\x9E., OU=IT & Security,
CN=*.e-guven.com
Subject: C=TR, ST=BAGCILAR, L=ISTANBUL, O=ICDAS Celik Enerji ve
Tersane Ulasim San AS, OU=ICDAS AS, CN=*.icdas.com.tr
Subject: C=TR, ST=Bakirkoy, L=Istanbul, O=Minopolis, OU=IT,
CN=www.minopolis.com.tr
Subject: C=TR, ST=CANKAYA, L=IZMIR, O=IT, OU=Egebimtes Bilgi
\xC4\xB0\xC5\x9Flem Makinalar\xC4\xB1 Teknik Servis San. ve Tic. Ltd.
\xC5\x9Eti., CN=ttgoldguide.com
Subject: C=TR, ST=Dazk\xC4\xB1r\xC4\xB1, L=Afyon,
O=Dazk\xC4\xB1r\xC4\xB1, OU=Dazk\xC4\xB1r\xC4\xB1 Belediyesi,
CN=online.dazkiri.bel.tr
Subject: C=TR, ST=Istanbul, L=Istanbul, O=Tegsoft Yonetim ve Bilisim
Hiz. Ltd. Sti., OU=IT Department,
CN=*.tegsoft.com/emailAddress=in...@tegsoft.com
Subject: C=TR, ST=KADIKOY, L=ISTANBUL, O=Tekno A Teknoloji
\xC3\x9Cr\xC3\xBCnleri ve Dan\xC4\xB1\xC5\x9Fmanl\xC4\xB1k Tic. Ltd.
\xC5\x9Eti., OU=Development, CN=*.teknoa.com.tr
Subject: C=TR, ST=KKTC, L=Magusa, O=Eastern Mediterranean University,
OU=DAU, CN=*.emu.edu.tr
Subject: C=TR, ST=., L=\xC4\xB0stanbul, O=EG\xC3\xBCven,
OU=Eg\xC3\xBCven, CN=www.imzalagonder.com
Subject: C=TR, ST=R\xC4\xB0ZE, L=R\xC4\xB0ZE, O=ogr.rize.edu.tr,
OU=\xC3\x96\xC4\x9ERENC\xC4\xB0 \xC4\xB0\xC5\x9ELER\xC4\xB0
DA\xC4\xB0RE BA\xC5\x9EKANLI\xC4\x9EI, CN=ogr.rize.edu.tr
Subject: C=TR, ST=SOGUTOZU, L=ANKARA, O=TURKIYE NOTERLER BIRLIGI,
OU=BILGI ISLEM, CN=*.tnb.org.tr/emailAddress=bim_gu...@tnb.org.tr
Subject: C=TR, ST=S\xC3\x9CLEYMANPA\xC5\x9EA,
L=TEK\xC4\xB0RDA\xC4\x9E, O=TEK\xC4\xB0RDA\xC4\x9E SERBEST
MUHASEBEC\xC4\xB0 MAL\xC4\xB0 M\xC3\x9C\xC5\x9EAV\xC4\xB0RLER ODASI,
OU=TSMMMO, CN=secure.tekirdagsmmmo.org.tr
Subject: C=TR, ST=TR, L=Istanbul, O=Elektronik Bilgi
G\xC3\xBCvenli\xC4\x9Fi A.\xC5\x9E., OU=E-Guven, CN=*.e-guven.com
Subject: C=TR, ST=T\xC3\xBCrkiye, L=Istanbul, O=*.arel.edu.tr,
OU=Bilgi i\xC5\x9Flem daire ba\xC5\x9Fkanl\xC4\xB1\xC4\x9F\xC4\xB1,
CN=*.arel.edu.tr
Subject: L=istanbul, CN=www.mellatbank.com, ST=N/A, O=Bank Mellat,
C=TR/emailAddress=f.k...@mellatbank.com

Of these 19, at least seven have subjects that appear to not be BR compliant.

Given this ratio, I find it very hard to believe that they would be
able to receive an audit report without qualifications that Mozilla
would deem unacceptable.

Thanks,
Peter

[Matt Palmer]

On Thu, Mar 19, 2015 at 01:01:32PM -0700, Peter Bowen wrote:
> On Wed, Mar 18, 2015 at 12:40 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> > I propose removing the following root cert from NSS, due to inadequate audit
> > statements.
> >
> > Issuer:
> > CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
> > O = Elektronik Bilgi Guvenligi A.S.
> > C = TR
>
> In the Pilot CT log, which includes every certificate that the Google
> crawler has seen, I found 19 unexpired certificates issued by this CA.
> Their subjects are as follows (using the default OpenSSL DN to string
> method):
>
> Subject: C=AU, ST=Some-State, O=Tejarat Bank, CN=*.tejaratbank.net

What is that... I don't even...

- Matt

[Peter Kurrasch]

There are 2 differences. First, in the event HSTS was activated on the site there will be no chance to override. Second, a user in that region may want to or need to activate that root because he or she relies on the impacted websites. Another concern is that the case by case override might still result in marginally usable sites because the embedded requests (css, js, images, iframes) could fail ("unknown issuer") without any chance to add exceptions for them. Being able to manually re-enable trust would serve as a useful remedy for them while still protecting the rest of the Internet populace.

In looking at that list of unexpired certs that chain to this root ‎it looks like there could be a lot of people who will be surprised or upset when they can't use Firefox anymore to get to those sites. It seems pretty clear that this CA should not be trusted but I'd hate for that to turn into a situation where people in Turkey stop using Mozilla products.

As a sort of tanget, but not really, I was also thinking about ‎the impacts to other products/projects that rely on this trust store. For this specific root it's hard for me to see a case where a problem might arise ("my embedded product stopped working!") it's probably worth keeping in mind anyway.

Thanks.

From: Kathleen Wilson Sent: Thursday, March 19, 2015 2:51 PM To: mozilla-dev-s...@lists.mozilla.org Subject: Re: Propose Removal of E-Guven root

On 3/19/15 11:51 AM, Peter Kurrasch wrote:

> Would it be an option to remove the trust bits on the root first and then later on remove it from the store entirely?
>

I don't see how removing the trust bits instead of removing the root
helps. In both cases the user will see the over-rideable "This
Connection is Untrusted" error with (Error code: sec_error_unknown_issuer)

[David Keeler]

On 03/19/2015 01:01 PM, Peter Bowen wrote:
> On Wed, Mar 18, 2015 at 12:40 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>> I propose removing the following root cert from NSS, due to inadequate audit
>> statements.
>>
>> Issuer:
>> CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
>> O = Elektronik Bilgi Guvenligi A.S.
>> C = TR
>
> In the Pilot CT log, which includes every certificate that the Google
> crawler has seen, I found 19 unexpired certificates issued by this CA.
> Their subjects are as follows (using the default OpenSSL DN to string
> method):

...

> Subject: C=TR, ST=Dazk\xC4\xB1r\xC4\xB1, L=Afyon,
> O=Dazk\xC4\xB1r\xC4\xB1, OU=Dazk\xC4\xB1r\xC4\xB1 Belediyesi,
> CN=online.dazkiri.bel.tr

More on this certificate (reproduced as PEM following the rest of this
message):

* it has no subject alternative name extension
* the OCSP responder returns "unknown" as its status
* it has a 1024-bit RSA key

Looking at another certificate (Subject: C=TR, ST=Istanbul, L=Istanbul,
O=Eczacibasi Bilisim San. ve Tic. A.S., OU=Altyapi ve Teknoloji
Hizmetleri, CN=*.ebi.com.tr/emailAddress=in...@ebi.com.tr):

* it also has no subject alternative name extension
* the OCSP responder also returns "unknown" as its status
* it was signed with sha1WithRSAEncryption despite expiring after 1
January 2017

...

> Given this ratio, I find it very hard to believe that they would be
> able to receive an audit report without qualifications that Mozilla
> would deem unacceptable.

Maybe I'm misinterpreting what you're saying, but did you mean
"acceptable" here?

Cheers,
David


PEM for CN=online.dazkiri.bel.tr:

-----BEGIN CERTIFICATE-----
MIIETDCCAzSgAwIBAgIRAI+EB2HpuvSdeuy5EvlUiDMwDQYJKoZIhvcNAQEFBQAw
dTELMAkGA1UEBhMCVFIxKDAmBgNVBAoTH0VsZWt0cm9uaWsgQmlsZ2kgR3V2ZW5s
aWdpIEEuUy4xPDA6BgNVBAMTM2UtR3V2ZW4gS29rIEVsZWt0cm9uaWsgU2VydGlm
aWthIEhpem1ldCBTYWdsYXlpY2lzaTAeFw0xNDExMTgxMDU5MDZaFw0xNTExMTgx
MDU5MDZaMIGEMQswCQYDVQQGEwJUUjESMBAGA1UECAwJRGF6a8SxcsSxMQ4wDAYD
VQQHEwVBZnlvbjESMBAGA1UECgwJRGF6a8SxcsSxMR0wGwYDVQQLDBREYXprxLFy
xLEgQmVsZWRpeWVzaTEeMBwGA1UEAxMVb25saW5lLmRhemtpcmkuYmVsLnRyMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2rFTFdnka6opmFqtW/GbqP9oWS9Ki
nmDPfh31eOr7niG1Eowzi96JUgACSNLpN85+2P+2Tqn36rW6+udcjKZL42K5ZD6G
SqGb5dBlhCb6uf+iGTl3y5Tl6TRhgWltQ6o+rJZpgm9gL0tKyYinB8exg4H7vapN
2rlzCJxOsvBSGQIDAQABo4IBSTCCAUUwdQYIKwYBBQUHAQEEaTBnMC4GCCsGAQUF
BzABhiJodHRwOi8vb2NzcDIuZS1ndXZlbi5jb20vb2NzcC54dWRhMDUGCCsGAQUF
BzAChilodHRwOi8vd3d3LmUtZ3V2ZW4uY29tL2RvY3VtZW50cy9LT0syLmNydDAT
BgNVHSUEDDAKBggrBgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAwEQYJYIZIAYb4QgEB
BAQDAgbAMB8GA1UdIwQYMBaAFJ/uRLOU1fqRTy7ZVZoEVtstxNulMFQGA1UdHwRN
MEswSaBHoEWGQ2h0dHA6Ly9zaWwuZS1ndXZlbi5jb20vRWxla3Ryb25pa0JpbGdp
R3V2ZW5saWdpQVNSb290L0xhdGVzdENSTC5jcmwwHQYDVR0OBBYEFJNe50spvhUt
HUbMbqMFGDfF0qTyMA0GCSqGSIb3DQEBBQUAA4IBAQBeXAvJIwskIjCI+rP0QK7P
9PwmckqNs+D8SgCpyS/Q9G37iD6E4KjaW/VTdoorkITs8kjnZrynymRBRcmqVcyp
lRzOpVVkT2av6Brg0Z+iB/VMjNiG98QIHSo8N+n1dt7vAAiqZaLlywZngum/U6Xj
IOz/22nWrqMxsx9VPUkXsLiroir29P7061FlffEBMCsSI0Yjh8KiU+RVEZt2lZ0F
MHhtRvL4fnC68B7N5P31bIQGcX5Wwz59FBRieVZuiZkQ4YdBfJgb84DP/JSJg184
QKMPHacmlrLVcyJuvOboep2PRTpdmrP/O4Rsw/nI63ZhvEksq04up2BBA6gAqW1z
-----END CERTIFICATE-----

PEM for CN=*.ebi.com.tr:

-----BEGIN CERTIFICATE-----
MIIFDjCCA/agAwIBAgIQTjVOvxHxokEvhXt2QlK3YTANBgkqhkiG9w0BAQUFADB1
MQswCQYDVQQGEwJUUjEoMCYGA1UEChMfRWxla3Ryb25payBCaWxnaSBHdXZlbmxp
Z2kgQS5TLjE8MDoGA1UEAxMzZS1HdXZlbiBLb2sgRWxla3Ryb25payBTZXJ0aWZp
a2EgSGl6bWV0IFNhZ2xheWljaXNpMB4XDTE1MDMxMjEzMzIwM1oXDTE3MDMxMjEz
MzIwM1owgcMxCzAJBgNVBAYTAlRSMREwDwYDVQQIEwhJc3RhbmJ1bDERMA8GA1UE
BxMISXN0YW5idWwxLTArBgNVBAoTJEVjemFjaWJhc2kgQmlsaXNpbSBTYW4uIHZl
IFRpYy4gQS5TLjEoMCYGA1UECxMfQWx0eWFwaSB2ZSBUZWtub2xvamkgSGl6bWV0
bGVyaTEVMBMGA1UEAxMMKi5lYmkuY29tLnRyMR4wHAYJKoZIhvcNAQkBFg9pbmZv
QGViaS5jb20udHIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCy1Avc
JkCv3XCSB3XVs1EZ79ZByBfwSOMl4Uh/gSpgmIp/lW095zPHuAHBfDtre5BmRe3N
92wrCa+vq7j97mgwf+G32GzUs2XzNLJPxgdOgeAa5j+sJa/m+udgJ3X7WpArFoYG
5Kotnw/ZzGFFz4uByPgIA+m+4v3m7BuOgVgpxz/jxmw8e/d3svj/t55D8faHxYG9
tMbkR/FGAfZ9jczz3meq+7wtEY3mEBwmuy82x7I2bjyleE+n/yM+FQpeaoKwFdrc
6VWJu1RXtcYACuC6fk6vTL8GiSoUhkjoGmBmN/pljNtoceU7XXKKCAL9SdaQCBfC
encyJJetXUZ+1JsNAgMBAAGjggFJMIIBRTB1BggrBgEFBQcBAQRpMGcwLgYIKwYB
BQUHMAGGImh0dHA6Ly9vY3NwMi5lLWd1dmVuLmNvbS9vY3NwLnh1ZGEwNQYIKwYB
BQUHMAKGKWh0dHA6Ly93d3cuZS1ndXZlbi5jb20vZG9jdW1lbnRzL0tPSzIuY3J0
MBMGA1UdJQQMMAoGCCsGAQUFBwMBMA4GA1UdDwEB/wQEAwIFoDARBglghkgBhvhC
AQEEBAMCBsAwHwYDVR0jBBgwFoAUn+5Es5TV+pFPLtlVmgRW2y3E26UwVAYDVR0f
BE0wSzBJoEegRYZDaHR0cDovL3NpbC5lLWd1dmVuLmNvbS9FbGVrdHJvbmlrQmls
Z2lHdXZlbmxpZ2lBU1Jvb3QvTGF0ZXN0Q1JMLmNybDAdBgNVHQ4EFgQUMS6OF6ng
nRVKM/AS9npoz6NahIswDQYJKoZIhvcNAQEFBQADggEBAICzA+K2Qne6px4/Fxhy
AI0aCQDf2Z75hFNc0Agi0QdYzYnZYU98+3WmTbnpExVxCq/mX9MVvatZ9AOyRTm+
zrUKFjAz8FSzTK6HA//o21rUONQk57pYTqy7qB5PHkN7NIthmXcC4gDoGl4D293A
w2CNdZlPmiAUYpUPwiQ1OwrfNa0YajRwlD1biBJZWGrymLVVLAxRjV33a5ecuxJM
c7eCJEJj0GDssHbmI96qqXgMRbNkVLiPJxNEIkEoMS1vvv6GPgNRasaDOlffoljM
7VQKW+xuI18hJQKbLu97dWLfVU5PprlHbZ5HL0woIj9ppxoDi0BsbY4OO9DBHmH4
KBo=
-----END CERTIFICATE-----

[Peter Bowen]

On Thu, Mar 19, 2015 at 4:39 PM, David Keeler <dke...@mozilla.com> wrote:
> On 03/19/2015 01:01 PM, Peter Bowen wrote:
>> Given this ratio, I find it very hard to believe that they would be
>> able to receive an audit report without qualifications that Mozilla
>> would deem unacceptable.
>
> Maybe I'm misinterpreting what you're saying, but did you mean
> "acceptable" here?

No, I meant acceptable.

I am confident that E-Guven could get an audit report, but the auditor
would list a number of "qualifications" (e.g. exceptions). Mozilla
has indicated in the past that certain qualifications/exceptions are
acceptable. In this case, I highly doubt that Mozilla would find the
qualifications/exceptions listed in the report to be acceptable.

For example, based on what you reported and what I saw, the audit
report should at a minimum say:
E-Guven complies with the Baseline Requirements with the following
qualifications:
- Some certificates issued do not conform to 9.2.1
- Some certificates issued do not conform to 9.2.4(d)
- Some certificates issued do not conform to 9.2.5
- Some certificates issued do not conform to Appendix A

Do you think these qualifications are acceptable?

Thanks,
Peter

[Ryan Sleevi]

On Thu, March 19, 2015 4:49 pm, Peter Bowen wrote:
> For example, based on what you reported and what I saw, the audit
> report should at a minimum say:
> E-Guven complies with the Baseline Requirements with the following
> qualifications:
> - Some certificates issued do not conform to 9.2.1
> - Some certificates issued do not conform to 9.2.4(d)
> - Some certificates issued do not conform to 9.2.5
> - Some certificates issued do not conform to Appendix A
>
> Do you think these qualifications are acceptable?
>
> Thanks,
> Peter

To be fair (and exceedingly cynical but depressingly realistic), the auditor
- May not find these certificates during the sampling audit
- May not use the certificates found as evidence of further misissuance
and thus not examine further
- May not even check the technical accuracy of these certificates
- For the certificates they find, require that they simply be revoked

All of which would allow the auditor to indicate a statement that the CA
fully conformed with all applicable policies during the period of time the
audit covers.

The most egregious issue is that last bit - a CA can (in practice, though
not desired) quietly sweep all such misissuance under the rug by allowing
time to remediate the auditor's qualified findings, such that the auditor
issues a glowing report consistent with the manager's assertion that the
CA was fully on the up and up.

The mitigation for such a depressing state of affairs is to require
transparency reporting during disclosure. That is, to require that
auditors list all the issues found (as you did), how many such issues were
found, and what steps the CA took to remediate the issues, all as part of
the public, annual audit report.

It's been talked about before, certainly, but how to best accomplish such
a wording change is unclear, and to get it incorporated into (WebTrust,
ETSI) is another matter.

[Peter Gutmann]

Matt Palmer <mpa...@hezmatt.org> writes:
>On Thu, Mar 19, 2015 at 01:01:32PM -0700, Peter Bowen wrote:

>> In the Pilot CT log, which includes every certificate that the Google
>> crawler has seen, I found 19 unexpired certificates issued by this CA.
>> Their subjects are as follows (using the default OpenSSL DN to string
>> method):
>>

>> Subject: C=AU, ST=Some-State, O=Tejarat Bank, CN=*.tejaratbank.net
>
>What is that... I don't even...

They're using the OpenSSL dummy-cert template to issue their certs (or
accepting requests from the dummy-cert template and signing them into
certs without checking them). Wow.

Peter.

[Rob Stradling]

On 19/03/15 20:01, Peter Bowen wrote:
> On Wed, Mar 18, 2015 at 12:40 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>> I propose removing the following root cert from NSS, due to inadequate audit
>> statements.
>>
>> Issuer:
>> CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
>> O = Elektronik Bilgi Guvenligi A.S.
>> C = TR
>

> In the Pilot CT log, which includes every certificate that the Google
> crawler has seen, I found 19 unexpired certificates issued by this CA.

IINM, all of these certs were issued _directly by the root_, almost
certainly contravening section 12 of the Baseline Requirements.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Ryan Sleevi]

On Thu, March 19, 2015 3:53 pm, Peter Kurrasch wrote:
> There are 2 differences. First, in
> the event HSTS was activated on the site there will be no chance to
> override. Second, a user in that region may want to or need to activate
> that root because he or she relies on the impacted websites. Another
> concern is that the case by case override might still result in marginally
> usable sites because the embedded requests (css, js, images, iframes)
> could fail ("unknown issuer") without any chance to add exceptions for
> them. Being able to manually re-enable trust would serve as a useful
> remedy for them while still protecting the rest of the Internet
> populace.

Peter,

While I do appreciate your efforts to think of the users here, I do think
it does a disservice to them to suggest that enabling trust in this
certificate is something desirable. That is, in a matter of opinionated
design, if the Mozilla Root Program has decided that the Certificate
Authority is not operating in the interests of Mozilla's users and
security at large, it does seem counter-productive to suggest that users
should be able to trivially re-enable support.

If it helps, think about how the SSL warnings themselves behave and used
to behave; it used to be a single click could bypass the error and
permanently save it. Increasingly, browsers have explored designs to make
it more difficult to bypass the error - with corresponding studies showing
that user understanding is increasing, and click through rate is
decreasing. Sometimes, making things a little bit harder can make a lot
more people secure.

On the matter of HSTS, this is working by design with HSTS. The mere act
of distrusting will prevent an override. Leaving the root in
doesn't/shouldn't affect this.

So I'm strongly supportive of removing both the certificate AND the trust
records. For users who do have a critical need to trust this root, and are
willing to accept the attendant risks that Mozilla is (rightfully) not,
then they can get that root from the CA and install it in the trust store,
same as they would do a self-signed root or other roots that have not been
audited/are not auditable.

[Richard Barnes]

I'm in the same place as Ryan here. In many security decisions we make, we
have to balance breakage for some people vs. risks for everyone else.

When we turned off SSLv3 in Firefox, it was still required by something
like 0.3% of websites -- several orders of magnitude more than will be
broken by removing e-Guven. We decided to do it because supporting that
small fraction of sites would impose a downgrade risk for every other site
on the web.

The situation is analogous here. The benefit of supporting the very small
number of sites that use e-Guven (thanks, Peter B!) does not balance the
risk posed to every other web site by having a non-compliant CA still
accepted.

--Richard

[Peter Kurrasch]

That's fine. I don't necessarily disagree with removing the root entirely but I do think it's a more heavy-handed remedy than is necessary. I view it as the difference between a punch in the chest vs a strenuous poke.

This action is a little more elective on Mozilla's part than other cases we've come across. It's warranted and justifiable, certainly, but not ‎critical like SSLv3 and such. It's very much possible there will be no fallout from this action, but still it's better to be prepared in advance.

I do still think it would be a good idea to "get the word out" so that concerned admins can fix their sites before things suddenly stop working.

Thanks.

From: Richard Barnes Sent: Friday, March 20, 2015 10:44 AM To: ryan-mozde...@sleevi.com Cc: Peter Kurrasch; mozilla-dev-s...@lists.mozilla.org; Kathleen Wilson Subject: Re: Propose Removal of E-Guven root

[Anne van Kesteren]

On Fri, Mar 20, 2015 at 11:48 PM, Peter Kurrasch <fhw...@gmail.com> wrote:
> I do still think it would be a good idea to "get the word out" so that concerned admins can fix their sites before things suddenly stop working.

If they use the developer edition of Firefox they'll discover this in
time. I believe we also typically blog about this before the commit
hits stable. Perhaps there's a market for a TLS advisory service that
tells you when your site is about to be impacted by changes to
browsers' TLS infrastructure.


--
https://annevankesteren.nl/

[yuhong...@hotmail.com]

FYI, the cert for ttgoldguide.com was just renewed, at first with a 1024-bit DSA cert that was probably a mistake:
-----BEGIN CERTIFICATE-----
MIIFTDCCBDSgAwIBAgIRAOi1tWEVFDLl0zeix5BhZdMwDQYJKoZIhvcNAQEFBQAw
dTELMAkGA1UEBhMCVFIxKDAmBgNVBAoTH0VsZWt0cm9uaWsgQmlsZ2kgR3V2ZW5s
aWdpIEEuUy4xPDA6BgNVBAMTM2UtR3V2ZW4gS29rIEVsZWt0cm9uaWsgU2VydGlm
aWthIEhpem1ldCBTYWdsYXlpY2lzaTAeFw0xNTA0MTMxMDQyNDdaFw0xNjA0MTMx
MDQyNDdaMG0xCzAJBgNVBAYTAlRSMRIwEAYDVQQIEwlQSU5BUkJBU0kxDjAMBgNV
BAcTBUlaTUlSMQ8wDQYDVQQKEwZUVUJPUkcxDzANBgNVBAsTBlRVQk9SRzEYMBYG
A1UEAxMPdHRnb2xkZ3VpZGUuY29tMIIBtjCCASsGByqGSM44BAEwggEeAoGBAJJz
dX0QiFfiMh+QGiuNGj1pC93tLmysQqAtqbXZIDBWQQFVAGvNfgK1RuzB7Bg5xTVN
aXQyZVWwYukttU72XgKDHYx7dzxkLNzH2Egl4cltf0LIY754lSORRwoqid4hXvDY
B+XNjh7oBluvou49ZDMGDIt8GayR3QlkKo/kau+XAhUAwTwJKJd96uhAOo6BGH8x
m2mjsaUCgYAzFo1sfmzREW41wLE4+NS01yZmZPvhKNBZVGa2xV+hfcBLLW3KEETi
HoAaaAzC57Hqtpt17LnwJzY25m+1ihUN0uZBRRoe+RWpTT0Yiic3iSHFi5MMcUaD
a+SrDhi7gjiVBFlJ3xu4UQhDpY8lF/CjFVOKff17Bhz28QTc8Z7cWAOBhAACgYA0
YHx+IyHM0VI4qgdygB6yNuQdYFVf4N22y0h+hZxrtiBV9WkuhcNr2SOuMTMPJTTC
jwGcwABxf/o0uYaEJ8onJE+mheIDEponoXlS7kUy6bMTUw2BcH9KPmP+9V/W3l4n
wDBKCswTOxQj+NAjqZQ2oBPtM38yugqLXW9AvHT62qOCAUkwggFFMHUGCCsGAQUF
BwEBBGkwZzAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmUtZ3V2ZW4uY29tL29j
c3AueHVkYTA1BggrBgEFBQcwAoYpaHR0cDovL3d3dy5lLWd1dmVuLmNvbS9kb2N1
bWVudHMvS09LMi5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDgYDVR0PAQH/BAQD
AgWgMBEGCWCGSAGG+EIBAQQEAwIGwDAfBgNVHSMEGDAWgBSf7kSzlNX6kU8u2VWa
BFbbLcTbpTBUBgNVHR8ETTBLMEmgR6BFhkNodHRwOi8vc2lsLmUtZ3V2ZW4uY29t
L0VsZWt0cm9uaWtCaWxnaUd1dmVubGlnaUFTUm9vdC9MYXRlc3RDUkwuY3JsMB0G
A1UdDgQWBBQJRN6fBc1j9o4llO3ONSgZohjAzzANBgkqhkiG9w0BAQUFAAOCAQEA
mj3fZOAHoPUXPrDhh8n7mGs5abcYqfL2D3K2ZoXJWDIyDHBWoND3JACjZHwqiTwN
ItGl2Y1+u3rT8N0SuiVk7DU3/LaMPQsTWtLvZbgjlUEGBUlpass3oiTDVC5CoxJR
S0UrSPXuDKSoBm5ch5cU7jijcBnDRxOPS7SRnzV+DYXwcEMFmpuvdNnJrK9H4u03
LIgC19kRKvoNHRO6ShwziySUX4Ot8dSLl+tTjFK0/sH+92AmUooUpRptjWqagFqd
c7knz+G0mrdwTtsA1AtfzS08QP5Gm5zcu0dVazvopIS9JJ1NPQal4HKpKzIAN/7f
Kl54l5+U9GPqQ7K06Tj2aQ==
-----END CERTIFICATE-----
Of course it has been replaced with a 1024-bit RSA certificate:
-----BEGIN CERTIFICATE-----
MIIEcTCCA1mgAwIBAgIQT41iMUm3wFt1IPGEv8K0bjANBgkqhkiG9w0BAQUFADB1
MQswCQYDVQQGEwJUUjEoMCYGA1UEChMfRWxla3Ryb25payBCaWxnaSBHdXZlbmxp
Z2kgQS5TLjE8MDoGA1UEAxMzZS1HdXZlbiBLb2sgRWxla3Ryb25payBTZXJ0aWZp
a2EgSGl6bWV0IFNhZ2xheWljaXNpMB4XDTE1MDQxNDA3MjQyOVoXDTE2MDQxNDA3
MjQzMFowgaoxCzAJBgNVBAYTAlRSMRAwDgYDVQQIEwdDQU5LQVlBMQ4wDAYDVQQH
EwVJWk1JUjFSMFAGA1UECgxJRWdlYmltdGVzIEJpbGdpIMSwxZ9sZW0gTWFraW5h
bGFyxLEgVGVrbmlrIFNlcnZpcyBTYW4uIHZlIFRpYy4gTHRkLiDFnnRpLjELMAkG
A1UECxMCSVQxGDAWBgNVBAMTD3R0Z29sZGd1aWRlLmNvbTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA6JRt8H74qlFRsb0W1IbTJKFomoRDlkEjjtXxzXTCZzXL
t/GE7zC8q8BoLioaCvGqwB1MXxM8KlVxYI0NSNOKrjmwlXWJ0vT6YeqJN9T9KC/f
hmtNmcQxK1OSkRLKICaFVLgL/qtHGNLOVV6uH897CAwfVfJYGiP4q9Xn2haq2CkC
AwEAAaOCAUkwggFFMHUGCCsGAQUFBwEBBGkwZzAuBggrBgEFBQcwAYYiaHR0cDov
L29jc3AyLmUtZ3V2ZW4uY29tL29jc3AueHVkYTA1BggrBgEFBQcwAoYpaHR0cDov
L3d3dy5lLWd1dmVuLmNvbS9kb2N1bWVudHMvS09LMi5jcnQwEwYDVR0lBAwwCgYI
KwYBBQUHAwEwDgYDVR0PAQH/BAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIGwDAfBgNV
HSMEGDAWgBSf7kSzlNX6kU8u2VWaBFbbLcTbpTBUBgNVHR8ETTBLMEmgR6BFhkNo
dHRwOi8vc2lsLmUtZ3V2ZW4uY29tL0VsZWt0cm9uaWtCaWxnaUd1dmVubGlnaUFT
Um9vdC9MYXRlc3RDUkwuY3JsMB0GA1UdDgQWBBSxuM8LaqkMblZg9vHK/VvvPPo6
fzANBgkqhkiG9w0BAQUFAAOCAQEANMdWtjsAd9axfyxlrO5rMiVN+sVnoUDdfeKj
JJ33TvZAIUTnw1IL9J0caFR6wzEOcXb1JkXU+TS+pjil6V4TuyxtTqD0il/7/RXN
0jKkmpMFmi3CCs2kDvbD9pc7LK/Tx/Vs6que2D3i3F5acTpWgMDgejU6JxrOijMz
8gJaOBbunsrhrYlMIUs7hsqWbPblUOIJBBXfTq5Z4IH8+boVAGZMGKjex8bDtgjn
UvH+i0t19MCcSccZT26Fg2EhETtuT5PYWneeNGL1llM74He5oncxMUA3mKk+ymzk
FemJP5iFuB20Xq5kpjcKPz3DqJZFW+eOUDGOxFTFn8scJt+FnQ==
-----END CERTIFICATE-----

[Kathleen Wilson]

On 4/14/15 8:50 AM, yuhong...@hotmail.com wrote:
> On Thursday, March 19, 2015 at 1:02:06 PM UTC-7, Peter Bowen wrote:
>> On Wed, Mar 18, 2015 at 12:40 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
>>> I propose removing the following root cert from NSS, due to inadequate audit
>>> statements.
>>>
>>> Issuer:
>>> CN = e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
>>> O = Elektronik Bilgi Guvenligi A.S.
>>> C = TR
>>
>> In the Pilot CT log, which includes every certificate that the Google
>> crawler has seen, I found 19 unexpired certificates issued by this CA.
>> Their subjects are as follows (using the default OpenSSL DN to string
>> method):

>> <snip>

>
> FYI, the cert for ttgoldguide.com was just renewed, at first with a 1024-bit DSA cert that was probably a mistake:

><snip>

> Of course it has been replaced with a 1024-bit RSA certificate

Thanks to all of you who participated in this discussion and provided
data about certificates this CA hierarchy.

We are proceeding with the removal of this root certificate in the
following bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1145270

This change is in NSS 3.18.1, which is expected to land in Firefox 38.

Thanks,
Kathleen

[Kathleen Wilson]

Security Blog posted about this:
https://blog.mozilla.org/security/2015/04/27/removing-e-guven-ca-certificate/

Thanks,
Kathleen