EV Guideline Violations
Patrick Tate
'SSLObservatory' has shown that two of the CAs allowed to issue EV
certificates from have violated the EV guidelines and issued non-
compliant certificates.
In one case, the certificate violates Mozilla's own non-EV guidelines
of issuing low-strength (512 bit key) certificates.
The CAs are GlobalSign and CyberTrust.
Cybertrust:
EV with 512 bit key, expiry Not After : Sep 3 18:12:45 2012 GMT
-----BEGIN CERTIFICATE-----
MIID0TCCArmgAwIBAgILAQAAAAABKtjj8HUwDQYJKoZIhvcNAQEFBQAwPzEXMBUG
A1UEChMOQ3liZXJ0cnVzdCBJbmMxJDAiBgNVBAMTG0N5YmVydHJ1c3QgU3VyZVNl
cnZlciBFViBDQTAeFw0xMDA5MDMxODEyNDVaFw0xMjA5MDMxODEyNDVaMIHIMQsw
CQYDVQQGEwJVUzELMAkGA1UECBMCVE4xEDAOBgNVBAcTB01lbXBoaXMxEzARBgsr
BgEEAYI3PAIBAxMCVVMxEzARBgsrBgEEAYI3PAIBAhMCVE4xIzAhBgNVBAoMGlRo
b21hcyAmIEJldHRzIENvcnBvcmF0aW9uMRswGQYDVQQPExJWMS4wLCBDbGF1c2Ug
NS4oYikxEjAQBgNVBAUTCTAwMDMwNzcyMzEaMBgGA1UEAxMRc3VwcGxpZXJzLnRu
Yi5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAv9Mzj6ovXaSjmecArlT4uVPq
YJBKM8SZNT4nY0By4gntYVT2DtSmSRTZ3dEWBGJ16azMM392ApOvDa5H0L1VyQID
AQABo4IBCjCCAQYwHwYDVR0jBBgwFoAUm3tY6z0D5IfI5IzqRnySVOk2u54wOQYD
VR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5vbW5pcm9vdC5jb20vU3VyZVNlcnZl
ckVWLmNybDAdBgNVHQ4EFgQUX1iFu12NHr2lrIRnT9tQA6cuDCwwCQYDVR0TBAIw
ADAOBgNVHQ8BAf8EBAMCBaAwUAYDVR0gBEkwRzBFBgorBgEEAbE+AWQBMDcwNQYI
KwYBBQUHAgEWKWh0dHA6Ly9jeWJlcnRydXN0Lm9tbmlyb290LmNvbS9yZXBvc2l0
b3J5MBwGA1UdEQQVMBOCEXN1cHBsaWVycy50bmIuY29tMA0GCSqGSIb3DQEBBQUA
A4IBAQAFsvw1kRZv+1/SPrswbC0isKME9vI0Uqo6wxFbbeeTqkl5Ff6UxEljmTWk
3kX2G1sgZGfCPBCuPOGUrSH//W3nkHPVwIbtdivJvBEZSuKnE3NqlbW8Q9TU5HrF
TzEcsy1RICsDsAHC4FLzZosT75ygaHxi96KLap1aInlbrs/fI62Kd2En34eOJ4ek
+KMXtJdCQd/2mKloTYfDLwjEuTYaqHQeYWH8+VixhUSlNG7AzVpUAN/s6jS/XO73
E4PaP2rx9YCzcDXPYiH6wlOOwdadBmdrp8b3DCF0EqTYbwz3B5lShbjWXEv/iXZF
bRoc4cFr6uAkb630cxfUHCPXB7F0
-----END CERTIFICATE-----
GlobalSign EV with private (RFC1918) IP addresses and single-server
names in the Subject Alt Name
-----BEGIN CERTIFICATE-----
MIIHBTCCBe2gAwIBAgILAQAAAAABH5SdTx8wDQYJKoZIhvcNAQEFBQAwYjEfMB0G
A1UECxMWRXh0ZW5kZWQgVmFsaWRhdGlvbiBDQTETMBEGA1UEChMKR2xvYmFsU2ln
bjEqMCgGA1UEAxMhR2xvYmFsU2lnbiBFeHRlbmRlZCBWYWxpZGF0aW9uIENBMB4X
DTA5MDIyMDE1NTYyNFoXDTExMDIyMTE1NTYxN1owgfkxGzAZBgNVBA8MElYxLjAs
IENsYXVzZSA1LihiKTERMA8GA1UEBRMINDk0Nzk1MjIxEzARBgsrBgEEAYI3PAIB
AxMCVVMxGTAXBgsrBgEEAYI3PAIBAhMISWxsaW5vaXMxCzAJBgNVBAYTAlVTMREw
DwYDVQQIEwhJbGxpbm9pczETMBEGA1UEBxMKTmFwZXJ2aWxsZTEYMBYGA1UECRMP
MTgwNyBXIERpZWhsIFJkMQswCQYDVQQLEwJDUzEhMB8GA1UEChMYSUNVTCBTZXJ2
aWNlIENvcnBvcmF0aW9uMRgwFgYDVQQDEw93d3cuaWxjdXN5cy5jb20wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMbbsLv7iiuMx7RmAze4J8+zPaQpZi
3KQAeYv23gzTkcw7x4Lj7USEzrp/Y20Cy0sS3PCaqgUoELSLkMdBYrOy2AJhzfEK
2jX7l/VXniAulCSImcZdmWX+RfbOA8mIwKG/G62vBxd9gI4Tn6UiFCLgDq536rg4
lxvJQCIM1BjurFezltywYc+ECKYU4najZ9RAAzr+K6PpVmxqBp4reUXhG7YZ+HfO
980gzTjbFEqGKBF88b697W+mxQRA7Bgm7eIP/E5HmTGjAaG4rPwnG9fUJ0hsTneU
ChcZaNee7qCZmvI5gWDGkfRiJ16NdEyCTHvDIAPzHeczfsv/kGvbYs0xAgMBAAGj
ggMiMIIDHjAfBgNVHSMEGDAWgBQ0sfnJjGs1RMwIaQru46O5XL8W4DBOBggrBgEF
BQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5u
ZXQvY2FjZXJ0L2V4dGVuZHZhbDEuY3J0MDkGA1UdHwQyMDAwLqAsoCqGKGh0dHA6
Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvRXh0ZW5kVmFsMS5jcmwwHQYDVR0OBBYEFCsg
EL3Qglq9evS4UzoicJ5kMmNwMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgTwMDQG
A1UdJQQtMCsGCCsGAQUFBwMBBggrBgEFBQcDAgYKKwYBBAGCNwoDAwYJYIZIAYb4
QgQBMEsGA1UdIAREMEIwQAYJKwYBBAGgMgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6
Ly93d3cuZ2xvYmFsc2lnbi5uZXQvcmVwb3NpdG9yeS8wEQYJYIZIAYb4QgEBBAQD
AgbAMIIBngYDVR0RBIIBlTCCAZGCEHd3dy5teWN1Y2FyZC5jb22CGGF1dGhlbnRp
Y2F0ZS5pbGN1c3lzLmNvbYIIbHlueGdhdGWHBMCoChiCDTE5Mi4xNjguMTAuMjSC
E3JlcG9ydHMuaWxjdXN5cy5jb22CEG1haWwuaWxjdXN5cy5jb22CC2luZmluaXRp
MmszhwTAqMgOgg4xOTIuMTY4LjIwMC4xNIIHcmVwb3J0c4cEwKgKAoIMMTkyLjE2
OC4xMC4yhwTAqAodgg0xOTIuMTY4LjEwLjI5hwTAqAoJggwxOTIuMTY4LjEwLjmC
FGdpZnRjYXJkLmlsY3VzeXMuY29tgghpY3VsYXBwNYIPd3d3LmlsY3VzeXMuY29t
ggtpbGN1c3lzLmNvbYIYYXV0b2Rpc2NvdmVyLmlsY3VzeXMuY29tghZzZWN1cmVt
YWlsLmlsY3VzeXMuY29thwTAqG4Bgg0xOTIuMTY4LjExMC4xhwTAqAoDggwxOTIu
MTY4LjEwLjOHBMCoCgeCDDE5Mi4xNjguMTAuN4IHYW9zc3J2MTANBgkqhkiG9w0B
AQUFAAOCAQEAR979OkjaWLAyoH09SQbV4RauKlZn6RfgC741YJHMQcjIPPMlFdcm
bzuxF3t/MRS+7oNDjPoG8EYxXa1AJE/Wkwu+vyzTHannKfZ/p6L4l8Z/58RUpuxM
gSS+78csxg5J9+AGaBqXgErQjks54nliCZ+FvAwPHo9a6Abt1hGScTr3F6DsNdRY
W/zXAnqtHmfNzYFkn2kKScq29+265qY+fhjRsMwhuaWlM9cpolzY3v6vkh/19umy
0fJKrtnvynhM0Vrrp3b4aSD1xEnsCKXrfn+vjswWENilgu7FrxefUt2zy76gj/Ka
68T3xsJDFxg7RWraJGXvjXfPYdOuVxk5xQ==
-----END CERTIFICATE-----
CyberTrust EV for a wildcard (CN in Subject is
'*.amos.hosting.accenture.com)
-----BEGIN CERTIFICATE-----
MIIExTCCA62gAwIBAgILAQAAAAABKyD1HsEwDQYJKoZIhvcNAQEFBQAwPzEXMBUG
A1UEChMOQ3liZXJ0cnVzdCBJbmMxJDAiBgNVBAMTG0N5YmVydHJ1c3QgU3VyZVNl
cnZlciBFViBDQTAeFw0xMDA5MTcxNzMyMDFaFw0xMjA5MTcxNzMyMDFaMIHpMQsw
CQYDVQQGEwJVUzELMAkGA1UECBMCSUwxEDAOBgNVBAcTB0NoaWNhZ28xFzAVBgNV
BAkTDjE2MSBOIENsYXJrIFN0MRMwEQYLKwYBBAGCNzwCAQMTAlVTMRMwEQYLKwYB
BAGCNzwCAQITAklMMRYwFAYDVQQKEw1BY2NlbnR1cmUgTExQMRswGQYDVQQPExJW
MS4wLCBDbGF1c2UgNS4oYikxDDAKBgNVBAsTA1NVUzEOMAwGA1UEBRMFMDA2MjIx
JTAjBgNVBAMMHCouYW1vcy5ob3N0aW5nLmFjY2VudHVyZS5jb20wggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDEmm+7j7gczKcH6FL/u4tE28m9FRsUF+55
bGLKFe2gnLxKl0k4PGDw/YFrjUomcsyHsD14Txg9xEZy6SnIy3QO1l39R1gjifPV
BLGUMXGqpj0hWihwRKZ8fdtoTEknEtE0MKz5hoQlEjUdBt2vdWUWlh89wAU86dZ1
hPHKPaWvol1OxIZnRNQsR5t8AnNXmlvXchk9p+Muf8M7YOQSJn5Q06EJScrssTzi
UK8gup7eFo55rePZ5qdHf3DTi4qdusfUJd/S5IGBnrym5MrihGDgLuXuRjmaQp1Q
ntdZBpz1rJtrYHm9LXz+9hjR/u+8+fy53if8ifvl94TieTl2sZY3AgMBAAGjggEV
MIIBETAfBgNVHSMEGDAWgBSbe1jrPQPkh8jkjOpGfJJU6Ta7njA5BgNVHR8EMjAw
MC6gLKAqhihodHRwOi8vY3JsLm9tbmlyb290LmNvbS9TdXJlU2VydmVyRVYuY3Js
MB0GA1UdDgQWBBQKc2BMGSmdqWMstaXG4atzjq1GzjAJBgNVHRMEAjAAMA4GA1Ud
DwEB/wQEAwIFoDBQBgNVHSAESTBHMEUGCisGAQQBsT4BZAEwNzA1BggrBgEFBQcC
ARYpaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRvcnkwJwYD
VR0RBCAwHoIcKi5hbW9zLmhvc3RpbmcuYWNjZW50dXJlLmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEAtnyBKU6CKr3Rmw8Mx08uEwRfwlnfOlaNLS+MZQMY2uglxy8bO16c
S9xArgiUWcxIJz67Go20dP7dhHdVtYfMJZhG37tQzyoWD6A5su4FZSBY2Mh81xA/
yk/NWpzoz2QDP+UpqyijUGCGgy+EZlBxQ8QfkPEWow9/PpiA/9N4A86EHih5VPRY
uQ/DwDwcOLC8RwwJnG9dJFd7VXc2/AbHTkqwQ/8aVcuDtU811AYWybeQDRK8HfvT
KlygjWAGtmHq9Fj76ZW4TC3Fn6STLcyUIYxD1YIt3SqKMNWRvsmq0H3l3Gu/xLvL
5AH/PQ1ZbJUVAPoPlx1NKUUy8aKpeJjTHA==
-----END CERTIFICATE-----
What are the consequences of these actions, and the blatant violation
of the EV guidelines?
Will Mozilla pull the EV-enablement of these EV root CAs?
Peter Gutmann
>What are the consequences of these actions, and the blatant violation of the
>EV guidelines?
The usual: A few people make tut-tutting noises, the CAs promise it'll never
happen again (until the next time it does), and then it's back to business as
usual.
Peter.
Jean-Marc Desperrier
Peter, can you include the context when you forward a message from
another list ?
Peter Gutmann
>Peter, can you include the context when you forward a message from another
>list ?
Uh, it was a reply to a message on this list, the original was:
Message-ID: <1b8fbfb8-af92-48e7...@d8g2000yqf.googlegroups.com>
Peter.
Kathleen Wilson
>
Try this link:
http://groups.google.com/group/mozilla.dev.security.policy/topics?pli=1
For some reason a few postings showed up in Google Groups, but not in
the Thunderbird news reader.
Kathleen
Kathleen Wilson
you please send me the following information?
1) slide #43: 13 Issuers signed 127 valid, EV certs with 1024 bit RSA
keys that expire after Dec 31, 2010
I would like the list of 13 Issuers (and if possible, the roots that
they chain up to).
2) Slide #45: EV certs for unqualified names
Still observe EV certs for:
”webmail”, ”zinc”,
”localhost”1
Major Class 3 EV CAs like Verisign
1(revoked after DEFCON)
I'm not sure what this slide means -- Were all such certs revoked? Or
just the localhost ones? If any are still not revoked, I would like to
know which roots they chain up to (or their issuers).
Thanks,
Kathleen
Jean-Marc Desperrier
Thank you, as your message was cross-posted, I thought the original one
was coming from the second list you were posting too and not there had
been a problem with the mozilla NNTP server.
According to what I read in bug 597046, the cause of the problem seems
to be the base64 content in the message (the certificates) against which
Giganews has a very strong filtering policy.
Unfortunately, in addition to that propagation problem between google
groups and the NNTP server, the message id is unusable since that
message has a different id on google group, as can be seen here with
this link :
http://groups.google.com/group/mozilla.dev.security.policy/msg/e9af0098934443a7?dmode=source
That's a second serious problem in my opinion.
Peter Gutmann
>If any of you have downloaded the 4GB EFF SSL Observatory data, could you
>please send me the following information?
Unless there's any objections to this (and I can't see why there would be
since it's all public information), what about posting the details to the
list? It'd be interesting to get some discussion/analysis of the data.
Peter.
Eddy Nigg
> Unless there's any objections to this (and I can't see why there would be
> since it's all public information), what about posting the details to the
> list? It'd be interesting to get some discussion/analysis of the data.
Please go ahead, I'm curious to see the list of those offending
certificates. Unfortunately I don't have the time right now to find them
(is there such a list already somewhere)?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Johan Sys
essence customer certificates with a potential weakness until the relevant
parties have a change to fix those ?
Johan
-----Original Message-----
From: dev-security-policy-bounces+johan.sys=globals...@lists.mozilla.org
[mailto:dev-security-policy-bounces+johan.sys=globals...@lists.mozilla.o
rg] On Behalf Of Eddy Nigg
Sent: Wednesday, January 05, 2011 6:32 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: EV Guideline Violations
On 01/05/2011 08:42 AM, From Peter Gutmann:
> Unless there's any objections to this (and I can't see why there would
> be since it's all public information), what about posting the details
> to the list? It'd be interesting to get some discussion/analysis of the
data.
Please go ahead, I'm curious to see the list of those offending
certificates. Unfortunately I don't have the time right now to find them (is
there such a list already somewhere)?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Peter Gutmann
>This is a public list. Would it be too much to ask not to post what are in
>essence customer certificates with a potential weakness until the relevant
>parties have a change to fix those ?
What's the weakness? There's a lack of compliance with EV requirements, but
no exploitable weakness that I can see. In any case the information is public
already, it's only the individual certs that haven't been enumerated because
of the sheer size of the data set involved.
(Anyone want to put it on a publicly-accessible MySQL server, set up as read-
only, with TLS security enabled and an on-request access password? That
should be enough to allow it to be perused while not making yourself a target
for attacks).
Peter.
Eddy Nigg
> "Johan Sys"<joha...@globalsign.com> writes:
>> This is a public list. Would it be too much to ask not to post what are in
>> essence customer certificates with a potential weakness until the relevant
>> parties have a change to fix those ?
> What's the weakness? There's a lack of compliance with EV requirements, but
> no exploitable weakness that I can see. In any case the information is public
> already, it's only the individual certs that haven't been enumerated because
> of the sheer size of the data set involved.
Agreed, I believe the information is already public. BTW, is somebody
from EFF on this list? Maybe they can help with that much faster.
Johan Sys
difficult. There is a difference between a compressed 4gig SQL dump and
just conveniently listing 'bad certificates' in a handy post : what if there
are 512bit or weak-key debian certs? What about new 'bad' certs discovered
? You can justifiable bash the CA all you want in that case, but opening up
the user's website to script kiddies should not be the goal.
This list is supposedly all about protecting those users.
Johan
-----Original Message-----
From: dev-security-policy-bounces+johan.sys=globals...@lists.mozilla.org
[mailto:dev-security-policy-bounces+johan.sys=globals...@lists.mozilla.o
rg] On Behalf Of Eddy Nigg
Sent: Wednesday, January 05, 2011 7:49 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: EV Guideline Violations
On 01/05/2011 12:34 PM, From Peter Gutmann:
> "Johan Sys"<joha...@globalsign.com> writes:
>> This is a public list. Would it be too much to ask not to post what
>> are in essence customer certificates with a potential weakness until
>> the relevant parties have a change to fix those ?
> What's the weakness? There's a lack of compliance with EV
> requirements, but no exploitable weakness that I can see. In any case
> the information is public already, it's only the individual certs that
> haven't been enumerated because of the sheer size of the data set
involved.
Agreed, I believe the information is already public. BTW, is somebody from
EFF on this list? Maybe they can help with that much faster.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
_______________________________________________
Peter Gutmann
>The mozilla code is also public, but finding critical bugs is a bit more
>difficult. There is a difference between a compressed 4gig SQL dump and
>just conveniently listing 'bad certificates' in a handy post : what if there
>are 512bit or weak-key debian certs? What about new 'bad' certs discovered ?
>You can justifiable bash the CA all you want in that case, but opening up the
>user's website to script kiddies should not be the goal.
Well, perhaps you could publish a recommended list of problem certs not to
publicise... at the moment I can't see, from a scan of the EFF slides,
anything that would allow a script-kiddie attack (unless you want to include
any remaining Debian certs, although even then the info has been public since
Defcon in August and nothing has happened, indicating that it's not an
exploited attack vector).
In order to justify suppressing publication, you'd have to demonstrate a clear
and present danger from doing so. I can't see any. Embarrassment to CAs, yes
:-), but I can't see anything that'd enable, or cause, a script-kiddie attack.
Now that we've finally got a large dataset available, we need more discussion
and analysis, not less.
Peter.
johan sys
But I fail to see the added value for this list in publishing certificates
with customer details in them versus just listing CA's and serial numbers of
offending certificates.
The latter allows this group to amend policies and embarrass the CA's. The
former in the least embarrass customers and potentially open them up to
attacks: where is this stated in the goals of this group ?
Johan
aero...@gmail.com
Many people don't have the time (or possibly even the knowledge how) to look at and mine the dataset themselves. Many people don't have the time (or possibly even the knowledge how) to retrieve data from the database to be able to look at the certificates directly.
And, it's fair to say that it's almost certain that some members of the list have different and more useful ways of mining and presenting the information.
You are essentially attempting to enforce security-by-obscurity, by suppressing (limiting the distribution of) information that the members of this list need to do their volunteer (and sometimes paid) tasks. Even if "[s]uppressing information is not the goal", you're advocating it as a means to an end.
You're employed by GlobalSign, so I consider you automatically suspect: are you afraid of what the dataset will reveal about your company's operations?
-Kyle H
Eddy Nigg
On 01/05/2011 12:56 PM, From Johan Sys:
> The mozilla code is also public, but finding critical bugs is a bit more
> difficult.
I assume that's the case. But it's open for everybody to see...
> There is a difference between a compressed 4gig SQL dump and
> just conveniently listing 'bad certificates' in a handy post : what if there
> are 512bit or weak-key debian certs?
I don't see a difference between a 512 bit weak Debian key and a 2048
bit weak Debian key. They are compromised in the same way and the size
doesn't make a big difference in this case.
> What about new 'bad' certs discovered?
So we ought to know about it?
> You can justifiable bash the CA all you want in that case...
Ohhom, so I would bash ourselves maybe too, no? Who said that StartCom
isn't one of those CAs on the list?
(Well probably not, perhaps because we haven't issued certificates based
on 1K keys for a while - there is apparently a protective advantage
today for that move. We probably also lost some business to our
competition sometimes, but there is a price for everything :-) ).
> This list is supposedly all about protecting those users.
What couldn't protect them better than knowing about those certificates?
Not sure, but weakness with those certificates is relative, I'm not
sure if there is an immediate threat. Anyway, Kathleen appears to be
more interested in those details than I am at the moment and I don't
have time for it right now either.
johan sys
With 'But I fail to see the added value for this list in publishing
certificates
with customer details in them versus just listing CA's and serial numbers of
offending certificates.' I just suggested to take out customer names before
posting on this list (just list for example the cert serial number but not
the DN).
Not that the certs should not be posted on this list. Sorry I was not more
clear.
Johan
>>> >The mozilla code is also public, but finding critical bugs is a bit more
>>> >difficult. There is a difference between a compressed 4gig SQL dump
>>> and
>>> >just conveniently listing 'bad certificates' in a handy post : what if
>>> there
>>> >are 512bit or weak-key debian certs? What about new 'bad' certs
>>> discovered ?
John Wilander
to know about this, or not wanting those customers to ask GlobalSign tough
questions.
In my opinion that *is* the embarrassment and hardship the CAs now have to
face.
A bunch of security geeks on this list (sorry) will not chance things to the
better. Bad CAs losing business will.
I might be wrong in my interpretation though.
Regards, John
2011/1/5 johan sys <joha...@globalsign.com>
Peter Gutmann
>The former in the least embarrass customers and potentially open them up to
>attacks: where is this stated in the goals of this group ?
You keep repeating this as some sort of article of faith. How will the
publication of (say) an EV wildcard cert (that's already available to anyone
who wants to find it) open anyone up to attack? Unless you can provide a
convincing supporting argument, your claims have no basis, therefore there's
no reason not to publish the certs.
Arguing in favour of publication, it'll certainly be useful to have them
readily available as test vectors for things that cert-processing code
shouldn't allow. So arguably, not publishing will actually reduce security,
and there's certainly no evidence that it'll increase it.
Peter.
George Macon
> 1) slide #43: 13 Issuers signed 127 valid, EV certs with 1024 bit RSA
> keys that expire after Dec 31, 2010
>
> I would like the list of 13 Issuers (and if possible, the roots that
> they chain up to).
>
Here's a partial answer.
SELECT DISTINCT `Issuer` FROM `valid_certs` WHERE `extended_validation`
= 1 AND `RSA_Modulus_Bits` < 2048 AND `Validity:Not After datetime` >
'2010-12-31 23:59:59';
C=US, O=SecureTrust Corporation, CN=SecureTrust CA
C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE
CyberTrust Global Root
C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at
https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended
Validation SSL SGC CA
C=US, O=GeoTrust Inc, OU=See www.geotrust.com/resources/cps (c)06,
CN=GeoTrust Extended Validation SSL CA
C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at
https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended
Validation SSL CA
C=NL, O=DigiNotar, CN=DigiNotar Extended Validation
CA/emailAddress=in...@diginotar.nl
O=Cybertrust, Inc, CN=Cybertrust Global Root
C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is incorporated by
reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority
- L1E
C=US, O=thawte, Inc., OU=Terms of use at https://www.thawte.com/cps
(c)06, CN=thawte Extended Validation SSL CA
C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities, CN=Wells
Fargo Public Primary Certificate Authority
O=Cybertrust Inc, CN=Cybertrust SureServer EV CA
C=JP, O=SECOM Trust Systems CO.,LTD., CN=SECOM Passport for Web EV CA
C=US, O=Entrust, Inc., OU=AND ADDITIONAL TERMS GOVERNING USE AND
RELIANCE, OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND
LIABILITY, OU=www.entrust.net/CPS is incorporated by reference, OU=(c)
2006 Entrust, Inc., CN=Entrust Certification Authority - L1A
OU=Extended Validation CA, O=GlobalSign, CN=GlobalSign Extended
Validation CA
C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance
EV CA-1
Rob Stradling
I just came up with the same list using the query below, which includes several EV Policy OIDs that I'm aware of but which the EFF guys' slides didn't mention.
Here's the list of Issuers together with the number of affected certs for each one:
| 63 | C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA
| 32 | C=US, O=SecureTrust Corporation, CN=SecureTrust CA
| 20 | C=NL, O=DigiNotar, CN=DigiNotar Extended Validation CA/emailAddress=in...@diginotar.nl
| 17 | C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL CA
| 14 | O=Cybertrust Inc, CN=Cybertrust SureServer EV CA
| 11 | C=US, O=thawte, Inc., OU=Terms of use at https://www.thawte.com/cps (c)06, CN=thawte Extended Validation SSL CA
| 8 | C=US, O=GeoTrust Inc, OU=See www.geotrust.com/resources/cps (c)06, CN=GeoTrust Extended Validation SSL CA
| 4 | C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is incorporated by reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority - L1E
| 3 | C=JP, O=SECOM Trust Systems CO.,LTD., CN=SECOM Passport for Web EV CA
| 1 | C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
| 1 | C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities, CN=Wells Fargo Public Primary Certificate Authority
| 1 | OU=Extended Validation CA, O=GlobalSign, CN=GlobalSign Extended Validation CA
| 1 | O=Cybertrust, Inc, CN=Cybertrust Global Root |
| 1 | C=US, O=Entrust, Inc., OU=AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE, OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY,
OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Certification Authority - L1A |
| 1 | C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance EV CA-1
That's 178 certificates in total, from 15 Issuers. I guess the slides were prepared before the EFF guys did their most recent scan.
Here's my query:
SELECT COUNT(*), valid_certs.Issuer
FROM valid_certs
WHERE valid_certs.RSA_Modulus_Bits < '2048'
AND valid_certs.enddate >= '2011-01-01'
AND (NOT LOCATE ('ext:X509v3 extensions:ext:X509v3 Basic Constraints:CA', "TRUE"))
AND (
LOCATE("1.2.276.0.44.1.1.1.4:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.2.392.200091.100.721.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.2.616.1.113527.2.5.1.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.2.840.113549.5.6.2:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.14370.1.6:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.14777.6.1.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.14777.6.1.2:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.22234.2.5.2.3.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.23223.1.1.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.23223.2:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.29836.1.10:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.34697.2.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.34697.2.2:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.34697.2.3:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.34697.2.4:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.4146.1.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.4386.2.4.1.1.0:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.5237.1.1.6:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.6334.1.100.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.6334.1.200.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.6449.1.2.1.5.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.782.1.2.1.8.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("1.3.6.1.4.1.8024.0.2.100.1.2:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.528.1.1001.1.1.1.1.5.2.6.4:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.528.1.1001.1.1.1.12.6.1.1.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.578.1.26.1.3.3:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.756.1.89.1.2.1.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.113733.1.7.23.6:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.113733.1.7.48.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.114028.10.1.2:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.114171.500.9:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.114404.1.1.2.4.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.114412.2.1:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.114413.1.7.23.3:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.114414.1.7.23.3:", `ext:X509v3 Certificate Policies:Policy`)
OR LOCATE("2.16.840.1.114414.1.7.24.2:", `ext:X509v3 Certificate Policies:Policy`)
)
GROUP BY valid_certs.Issuer
ORDER BY COUNT(*) DESC;
On Wednesday 05 January 2011 15:59:59 George Macon wrote:
> On 1/3/11 5:31 PM, Kathleen Wilson wrote:
> > 1) slide #43: 13 Issuers signed 127 valid, EV certs with 1024 bit RSA
> > keys that expire after Dec 31, 2010
> >
> > I would like the list of 13 Issuers (and if possible, the roots that
> > they chain up to).
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Rob Stradling
Here's my query:
> > 1) slide #43: 13 Issuers signed 127 valid, EV certs with 1024 bit RSA
> > keys that expire after Dec 31, 2010
> >
> > I would like the list of 13 Issuers (and if possible, the roots that
> > they chain up to).
>
David E. Ross
Past discussions elsewhere about publicizing security vulnerabilities
have not been conclusive. However, I feel that they should indeed be
publicized after sufficient time has elapsed to allow the responsible
parties to take effective corrective action.
I would remind everyone of the case of Michael Lynn, who reported a
vulnerability in Cisco's routers at a Black Hat conference. This public
disclosure occurred only some time after Lynn privately notified Cisco
of the problem. Cisco responded to the publicity by suing Lynn, who
lacked sufficient resources to defend the suit and thus settled. It
remains widely believed that Cisco -- claiming that its suit was to
protect its intellectual property -- was really motivated by wanting to
protect its reputation. All this happened in 2005.
Apparently, this problem was known last July. It is now time for full
disclosure. Reputations of CAs be damned. Protection of Mozilla users
should have highest priority.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Paul Tiemann
WHERE valid_certs.RSA_Modulus_Bits <= '1024'
Paul Tiemann
CTO, DigiCert, Inc.
>>> 1) slide #43: 13 Issuers signed 127 valid, EV certs with 1024 bit RSA
>>> keys that expire after Dec 31, 2010
>>>
>>> I would like the list of 13 Issuers (and if possible, the roots that
>>> they chain up to).
>>
Paul Tiemann
WHERE valid_certs.RSA_Modulus_Bits <= '1024'
>>> 1) slide #43: 13 Issuers signed 127 valid, EV certs with 1024 bit RSA
>>> keys that expire after Dec 31, 2010
>>>
>>> I would like the list of 13 Issuers (and if possible, the roots that
>>> they chain up to).
>>
Rob Stradling
slides.
A 2047-bit keyed EV certificate that expires after 31-DEC-2010 violates the EV
Guidelines.
Kathleen Wilson
> George, you just beat me to it. ;-)
>
> I just came up with the same list using the query below, which includes several EV Policy OIDs that I'm aware of but which the EFF guys' slides didn't mention.
>
> Here's the list of Issuers together with the number of affected certs for each one:
> | 63 | C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL SGC CA
> | 32 | C=US, O=SecureTrust Corporation, CN=SecureTrust CA
> | 20 | C=NL, O=DigiNotar, CN=DigiNotar Extended Validation CA/emailAddress=in...@diginotar.nl
> | 17 | C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended Validation SSL CA
> | 14 | O=Cybertrust Inc, CN=Cybertrust SureServer EV CA
> | 11 | C=US, O=thawte, Inc., OU=Terms of use at https://www.thawte.com/cps (c)06, CN=thawte Extended Validation SSL CA
> | 8 | C=US, O=GeoTrust Inc, OU=See www.geotrust.com/resources/cps (c)06, CN=GeoTrust Extended Validation SSL CA
> | 4 | C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is incorporated by reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority - L1E
> | 3 | C=JP, O=SECOM Trust Systems CO.,LTD., CN=SECOM Passport for Web EV CA
> | 1 | C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root
> | 1 | C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities, CN=Wells Fargo Public Primary Certificate Authority
> | 1 | OU=Extended Validation CA, O=GlobalSign, CN=GlobalSign Extended Validation CA
> | 1 | O=Cybertrust, Inc, CN=Cybertrust Global Root |
> | 1 | C=US, O=Entrust, Inc., OU=AND ADDITIONAL TERMS GOVERNING USE AND RELIANCE, OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND LIABILITY,
> OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Certification Authority - L1A |
> | 1 | C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance EV CA-1
>
> That's 178 certificates in total, from 15 Issuers. I guess the slides were prepared before the EFF guys did their most recent scan.
>
Thank you George and Rob.
I've added the representatives of the corresponding CAs to the bug, and
have requested that they follow up with their progress directly in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=622589
Thanks,
Kathleen
Paul Tiemann
> The "added value for this list" is that every member of the list will be able to have a rational, informed debate about the situation.
<humor>Perhaps not every member of this list is capable of having a rational, informed debate about the topic, regardless of the added value of cold hard data. ;)
> Many people don't have the time (or possibly even the knowledge how) to look at and mine the dataset themselves. Many people don't have the time (or possibly even the knowledge how) to retrieve data from the database to be able to look at the certificates directly.
Yet some of those "many people" do have the time to pretend that every CA mistake is a blatant, repeated, and fully intentional violation, which constitutes a very serious threat, undermining online security in the worst possible way.
Take for an example the existence of some 1024 bit EV certificates. Some people on this list were recently pointing out that it is silly to require an early retirement of 1024 bit RSA keys in SSL certificates because it adds extremely little to actual security to require 2048 bit certificates across the board, when there are dozens of other more effective ways to make the internet safer. Now the same people admit that a 1024 bit RSA key is not a security vulnerability, but they seem to want to publicize the list for no other reason than the fun of hunting witches. <see Monty Python and the Holy Grail skit>
Besides Kathleen kindly opening a bug, nowhere in the discussion has any rational interest been shown in the fact that Mozilla itself could have avoided the embarrassment of showing green EV indicators to certificates that failed to meet the technical requirements of EV certs.
Goal: Keep pants up.
Belt: EV SSL certificate from an EV-enabled CA
Suspenders: Browser checks against the certificate (EV OID present, Key size adequate, no-wildcards, etc)
In ~150 of 33,000 cases we have an inadequate 'belt'. And in 33,000 of 33,000 cases we have inadequate suspenders. Both sides can be fixed. In fact, if Firefox had refused to give EV treatment to those certificates after Dec 31, 2010, then a lot of them would likely have been replaced as soon as the cert holders discovered their certificates were no longer showing the EV UI indicators.
The internet is full of 1024 bit RSA keys which are as secure today as they were last week and nobody is demanding they all be replaced because there are still lots of better ways for people to spend their time securing their little corner of the internet. EV guidelines say to use 2048 bits for certs expiring after the deadline last New Years Eve, so yes there's a technical reason to complain even if there is not a practical security problem.
Maybe someone can tell me in a rational way why this discussion does not resemble "Security Theater." :)
Cheers,
Paul Tiemann
CTO, DigiCert Inc.
Jean-Marc Desperrier
> DigiCert appears in your query because we have 1 certificate with
> 2047 bits. I think your numbers will match their slide more closely if you
> change the where statement to:
>
> WHERE valid_certs.RSA_Modulus_Bits<= '1024'
It's true that cryptographically a 2047 key is equivalent to a 2048 one,
and it's nothing evil if the key sizes are sprayed a few bits around
2048. But the requirement is still 2048 and not 1024, so I would not
think a 1536 bits key is OK.
I myself would consider the best/simplest is to accept as a "2048" bits
keys all keys that are at least 2041 bits long (in other words, accept
all keys that are at least 256 bytes long, reject those that are 255
byte or less long. I believe there could be implementations that test
the size in byte and not in bits, and that within that gap it's more
knee-jerk than reasonable to declare the key invalid).
So, I'd write the request as :
WHERE valid_certs.RSA_Modulus_Bits<= '2040'.
It would be great if EFF was making an interface available to run
read-only sql requests on the data. Or allowed exports based on an sql
select statement.
Jean-Marc Desperrier
> On Jan 5, 2011, at 5:29 AM, aero...@gmail.com wrote:
> <humor>Perhaps not every member of this list is capable of having a
> rational, informed debate about the topic, regardless of the added value
> of cold hard data. ;)
That it's also available as a usenet newgroup and a web forum makes that
statement 100% sure to be true. At least at the moment it's a lot more
civil than the CNNIC discussion.
> Some people on this list were recently pointing out that it is silly
> to require an early retirement of 1024 bit RSA keys in SSL
> certificates [...]. Now the
> same people admit that a 1024 bit RSA key is not a security
> vulnerability, but they seem to want to publicize the list for no
> other reason than the fun of hunting witches.[...]
I do find a bit surprising that two messages above the same conclusion,
"do not publish", was reached using the exact opposite argumentation
("as this certificate are a real security risk, do not make it easier
for pirates to find them").
> [...]
> Goal: Keep pants up. Belt: EV SSL certificate from an EV-enabled CA
> Suspenders: Browser checks against the certificate (EV OID present,
> Key size adequate, no-wildcards, etc)
Still, the trouble is that the suspender can do the easy, fully
automatizable job, but can't do anything against the n�1 concern,
invalid identity verification. And IIRC Firefox *does* warn against
really unambiguously dangerous case, like 512 bits certificates.
> certificates after Dec 31, 2010, then a lot of them would likely have
> been replaced as soon as the cert holders discovered their
> certificates were no longer showing the EV UI indicators.
> [...]
I think that would just have made the base problem more hidden.
> Maybe someone can tell me in a rational way why this discussion does
> not resemble "Security Theater." :)
Maybe it is in part, but in my opinion, the thing we're actually worried
about is "do CAs do a proper job at applying the security policy they
promise to apply ?" and "Are they afraid enough of what will happen if
they fail that they spend the time and money needed to do it properly ?"
So those failures are not so much interesting by themselves, but more as
a proxy to evaluate how good CAs are at that. If they can't check the
size of the key, or allow wildcards where they should be strictly
forbidden, both of which are so easy to do that that it could be fully
automatized inside Firefox, then how good can we expect they are at
checking if the copy of an ID is a bad photoshop ?
You know that they are people who *very* seriously think of getting rid
of CAs all-together and just using secure DNS to link domain names to IPs ?
This being said I do not forget that recently the main threat has been
stolen private keys, and *not* CA being abused into delivering a
certificate to the bad person.
Peter Gutmann
[CC'd explicitly to the people who've posted results here, the tracker for the
cert data seems to be down at the moment so its not possible to get a copy to
extract the certs in question]
Is there any chance you could post the actual certs, as well as the others
mentioned in the EFF slides (the wildcard ones, the 512-bit ones, etc) to
allow people to play with them? It'd be good to have a pile of non-EV EV
certs to use as test data for cert-processing code.
As soon as the tracker's up again and if various other things work out, I'll
grab and post the certs myself, but I dont know when that'll be. Since none
of the people who've objected to the posting have been able to identify any
actual security threat posed by doing so, I don't see that there's any problem
with this. However, to put my money here my mouth is, if posting the certs
results in the collapse of civilisation, I promise to buy the
GlobalSign/Cybertrust/whatever person dinner at the restaurant of his choice,
assuming any survive the projected apocalypse, if in exchange he promises to
buy me dinner if absolutely nothing happens (I'll have it at Laurel's Cuban
Restaurant the evening after the RSA conference, you can go ahead and make the
reservations now).
Peter.
Peter Gutmann
>A 2047-bit keyed EV certificate that expires after 31-DEC-2010 violates the
>EV Guidelines.
You're running into a problem of blindly following the letter vs. the intent
of the requirements. It's inevitable that when you multiply a 1024-bit p with
a 1024-bit q you'll sometimes get an n one or two bits shorter. In theory you
could keep generating p/q values until you get exactly 2048 bits for n, but
this is really slow and seems pretty pointless. In my code I treat anything
within 8 bits of a given key size as equivalent to that key size for this
reason. I think it would make more sense to check for <= 2040 rather than
exactly 2048.
Peter.
Rob Stradling
(slide 50) all failed in different ways to correctly distinguish between end-
entity certs and CA certs.
The query below is more accurate. I'll update Bug 622589 shortly with the
revised per-Issuer counts.
SELECT COUNT(*), valid_certs.Issuer
FROM valid_certs
WHERE valid_certs.RSA_Modulus_Bits < '2048'
AND valid_certs.enddate >= '2011-01-01'
AND (NOT COALESCE(LOCATE("TRUE", `ext:X509v3 Basic Constraints:CA`), 0))
> > C=US, O=SecureTrust Corporation, CN=SecureTrust CA
> > C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE
> >
> > CyberTrust Global Root
> >
> > C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at
> >
> > https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended
> > Validation SSL SGC CA
> >
> > C=US, O=GeoTrust Inc, OU=See www.geotrust.com/resources/cps (c)06,
> >
> > CN=GeoTrust Extended Validation SSL CA
> >
> > C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at
> >
> > https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended
> > Validation SSL CA
> >
> > C=NL, O=DigiNotar, CN=DigiNotar Extended Validation
> >
> > CA/emailAddress=in...@diginotar.nl
> >
> > O=Cybertrust, Inc, CN=Cybertrust Global Root
> > C=US, O=Entrust, Inc., OU=www.entrust.net/rpa is incorporated by
> >
> > reference, OU=(c) 2009 Entrust, Inc., CN=Entrust Certification Authority
> > - L1E
> >
> > C=US, O=thawte, Inc., OU=Terms of use at https://www.thawte.com/cps
> >
> > (c)06, CN=thawte Extended Validation SSL CA
> >
> > C=US, O=Wells Fargo, OU=Wells Fargo Certificate Authorities, CN=Wells
> >
> > Fargo Public Primary Certificate Authority
> >
> > O=Cybertrust Inc, CN=Cybertrust SureServer EV CA
> > C=JP, O=SECOM Trust Systems CO.,LTD., CN=SECOM Passport for Web EV CA
> > C=US, O=Entrust, Inc., OU=AND ADDITIONAL TERMS GOVERNING USE AND
> >
> > RELIANCE, OU=CPS CONTAINS IMPORTANT LIMITATIONS OF WARRANTIES AND
> > LIABILITY, OU=www.entrust.net/CPS is incorporated by reference, OU=(c)
> > 2006 Entrust, Inc., CN=Entrust Certification Authority - L1A
> >
> > OU=Extended Validation CA, O=GlobalSign, CN=GlobalSign Extended
> >
> > Validation CA
> >
> > C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance
> >
> > EV CA-1
> >
Rob Stradling
Peter, if there was universal agreement on what the "intent" was, I would have
no problem agreeing with your suggestion. However, at least one browser
blindly follows the letter of the 2048-bit minimum requirement.
Try visiting the following 2 URLs in a recent version of Opera:
https://montpelierus.oneshield.com/oneshield/dragon/skins/mont/banners/company_logo.gif
https://www.digicert.com
The first of those URLs is where that 2047-bit EV cert issued by DigiCert is
currently live. Opera does *not* show it as an EV site.
The second URL uses a 2048-bit EV cert issued by DigiCert. Opera *does* show
it as an EV site.
I doubt that Montpelier US actively want their EV cert to be shown as non-EV,
so therefore I suggest that blindly following the letter is the safer option
for CAs.
Eddy Nigg
> The internet is full of 1024 bit RSA keys which are as secure today as they were last week and nobody is demanding they all be replaced because there are still lots of better ways for people to spend their time securing their little corner of the internet. EV guidelines say to use 2048 bits for certs expiring after the deadline last New Years Eve, so yes there's a technical reason to complain even if there is not a practical security problem.
>
> Maybe someone can tell me in a rational way why this discussion does not resemble "Security Theater." :)
Sorry to disagree with you a bit this time around. I believe that either
we have guidelines to which CAs have to adhere to (whatever they are) or
not. Something basic like a cut-off date of the key sizes (and other
smaller issues that were found) leaves room for questions about what
else might be wrong (about which the facts are less easy to obtain).
For example were all EV certificates validated and verified according to
the guidelines or were also some of the requirements rounded up or down
to the convenience of the CA and their subscribers? And that would raise
other concerns and questions about CAs adhering and others that don't -
even if no certificates has been "wrongfully" issued, e.g. the details
may be correct, the verification procedure not.
And if were are speaking about the key sizes, why haven't those CAs
simply issued certificates that were valid until the cut-off date and
not beyond? What were they thinking about how they could be in
compliance thereafter?
And the correct action about your observation from above would have been
to modify the EV guidelines - which I believe was discussed and rejected
at some point.
George Macon
> 2) Slide #45: EV certs for unqualified names
> Still observe EV certs for:
> ”webmail”, ”zinc”,
> ”localhost”1
> Major Class 3 EV CAs like Verisign
> 1(revoked after DEFCON)
>
> I'm not sure what this slide means -- Were all such certs revoked? Or
> just the localhost ones? If any are still not revoked, I would like to
> know which roots they chain up to (or their issuers).
>
Here are the highlights:
There are 27 certificates that were valid when the scan was done, that
are EV end-entity certificates (using Rob Stradling's OID list), and
have either common names or SANs that look like host names, but aren't
part of TLD's from the IANA TLD list
<http://data.iana.org/TLD/tlds-alpha-by-domain.txt>. This includes
unqualified names (like `anita') and also internal names (like
`anita.lesdom.local'). (This example has been revoked.)
Of those 27, 10 were still valid, 7 have since expired, 6 have been
revoked, and 4 couldn't be validated due to missing intermediate
certificates (these are probably 'transvalid' certificates, but I didn't
check for that).
The localhost cert that met all of the criteria was revoked.
The remaining definitely valid certs chain up to only two roots,
Verisign and QuoVadis.
See code and complete output at
<http://www.prism.gatech.edu/~gmacon3/ssl-observatory/>.
Stephen Davidson
> Verisign and QuoVadis.
The two noncompliant EV SSL issued by QuoVadis have been revoked.
Our SSL registration system has filters that block noncompliant
domains and key sizes from being used for EV.
The noncompliant certificates were issued to "related entities" to
QuoVadis and their issuance was allowed by a misconfigured account
setting.
We are now undertaking a special internal audit of both our valid EV
certificates as well as of our SSL registration system account
settings to help ensure this issue does not occur again.
George Macon
validity. This caused it to recognize all of the EV certs, adding
another CA to the set of those with improper certificates: Comodo.
QuoVadis has revoked their improper certs.
The updated script also recognizes RFC 1918 private IP addresses. There
was only one cert with RFC 1918 addresses that didn't also have
unqualified or local host names. It's been revoked.
I've also posted a summary over all certificates listing number of
improper certificates by issuer. There are 34770 certificates with at
least one improper name.
http://www.prism.gatech.edu/~gmacon3/ssl-observatory/
budd...@gmail.com
> The recent data presented at the 27th CCC as part of the EFF's
> 'SSLObservatory' has shown that two of the CAs allowed to issue EV
> certificates from have violated the EV guidelines and issued non-
> compliant certificates.
> In one case, the certificate violates Mozilla's own non-EV guidelines
> of issuing low-strength (512 bit key) certificates.
> The CAs are GlobalSign and CyberTrust.
>
> Cybertrust:
> EV with 512 bit key, expiry Not After : Sep 3 18:12:45 2012 GMT
> -----BEGIN CERTIFICATE-----
> MIID0TCCArmgAwIBAgILAQAAAAABKtjj8HUwDQYJKoZIhvcNAQEFBQAwPzEXMBUG
> A1UEChMOQ3liZXJ0cnVzdCBJbmMxJDAiBgNVBAMTG0N5YmVydHJ1c3QgU3VyZVNl
> cnZlciBFViBDQTAeFw0xMDA5MDMxODEyNDVaFw0xMjA5MDMxODEyNDVaMIHIMQsw
> CQYDVQQGEwJVUzELMAkGA1UECBMCVE4xEDAOBgNVBAcTB01lbXBoaXMxEzARBgsr
> BgEEAYI3PAIBAxMCVVMxEzARBgsrBgEEAYI3PAIBAhMCVE4xIzAhBgNVBAoMGlRo
> b21hcyAmIEJldHRzIENvcnBvcmF0aW9uMRswGQYDVQQPExJWMS4wLCBDbGF1c2Ug
> NS4oYikxEjAQBgNVBAUTCTAwMDMwNzcyMzEaMBgGA1UEAxMRc3VwcGxpZXJzLnRu
> Yi5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAv9Mzj6ovXaSjmecArlT4uVPq
> YJBKM8SZNT4nY0By4gntYVT2DtSmSRTZ3dEWBGJ16azMM392ApOvDa5H0L1VyQID
> AQABo4IBCjCCAQYwHwYDVR0jBBgwFoAUm3tY6z0D5IfI5IzqRnySVOk2u54wOQYD
> VR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5vbW5pcm9vdC5jb20vU3VyZVNlcnZl
> ckVWLmNybDAdBgNVHQ4EFgQUX1iFu12NHr2lrIRnT9tQA6cuDCwwCQYDVR0TBAIw
> ADAOBgNVHQ8BAf8EBAMCBaAwUAYDVR0gBEkwRzBFBgorBgEEAbE+AWQBMDcwNQYI
> KwYBBQUHAgEWKWh0dHA6Ly9jeWJlcnRydXN0Lm9tbmlyb290LmNvbS9yZXBvc2l0
> b3J5MBwGA1UdEQQVMBOCEXN1cHBsaWVycy50bmIuY29tMA0GCSqGSIb3DQEBBQUA
> A4IBAQAFsvw1kRZv+1/SPrswbC0isKME9vI0Uqo6wxFbbeeTqkl5Ff6UxEljmTWk
> 3kX2G1sgZGfCPBCuPOGUrSH//W3nkHPVwIbtdivJvBEZSuKnE3NqlbW8Q9TU5HrF
> TzEcsy1RICsDsAHC4FLzZosT75ygaHxi96KLap1aInlbrs/fI62Kd2En34eOJ4ek
> +KMXtJdCQd/2mKloTYfDLwjEuTYaqHQeYWH8+VixhUSlNG7AzVpUAN/s6jS/XO73
> E4PaP2rx9YCzcDXPYiH6wlOOwdadBmdrp8b3DCF0EqTYbwz3B5lShbjWXEv/iXZF
> bRoc4cFr6uAkb630cxfUHCPXB7F0
> -----END CERTIFICATE-----
>
>
> GlobalSign EV with private (RFC1918) IP addresses and single-server
> names in the Subject Alt Name
> -----BEGIN CERTIFICATE-----
> MIIHBTCCBe2gAwIBAgILAQAAAAABH5SdTx8wDQYJKoZIhvcNAQEFBQAwYjEfMB0G
> A1UECxMWRXh0ZW5kZWQgVmFsaWRhdGlvbiBDQTETMBEGA1UEChMKR2xvYmFsU2ln
> bjEqMCgGA1UEAxMhR2xvYmFsU2lnbiBFeHRlbmRlZCBWYWxpZGF0aW9uIENBMB4X
> DTA5MDIyMDE1NTYyNFoXDTExMDIyMTE1NTYxN1owgfkxGzAZBgNVBA8MElYxLjAs
> IENsYXVzZSA1LihiKTERMA8GA1UEBRMINDk0Nzk1MjIxEzARBgsrBgEEAYI3PAIB
> AxMCVVMxGTAXBgsrBgEEAYI3PAIBAhMISWxsaW5vaXMxCzAJBgNVBAYTAlVTMREw
> DwYDVQQIEwhJbGxpbm9pczETMBEGA1UEBxMKTmFwZXJ2aWxsZTEYMBYGA1UECRMP
> MTgwNyBXIERpZWhsIFJkMQswCQYDVQQLEwJDUzEhMB8GA1UEChMYSUNVTCBTZXJ2
> aWNlIENvcnBvcmF0aW9uMRgwFgYDVQQDEw93d3cuaWxjdXN5cy5jb20wggEiMA0G
> CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMbbsLv7iiuMx7RmAze4J8+zPaQpZi
> 3KQAeYv23gzTkcw7x4Lj7USEzrp/Y20Cy0sS3PCaqgUoELSLkMdBYrOy2AJhzfEK
> 2jX7l/VXniAulCSImcZdmWX+RfbOA8mIwKG/G62vBxd9gI4Tn6UiFCLgDq536rg4
> lxvJQCIM1BjurFezltywYc+ECKYU4najZ9RAAzr+K6PpVmxqBp4reUXhG7YZ+HfO
> 980gzTjbFEqGKBF88b697W+mxQRA7Bgm7eIP/E5HmTGjAaG4rPwnG9fUJ0hsTneU
> ChcZaNee7qCZmvI5gWDGkfRiJ16NdEyCTHvDIAPzHeczfsv/kGvbYs0xAgMBAAGj
> ggMiMIIDHjAfBgNVHSMEGDAWgBQ0sfnJjGs1RMwIaQru46O5XL8W4DBOBggrBgEF
> BQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5u
> ZXQvY2FjZXJ0L2V4dGVuZHZhbDEuY3J0MDkGA1UdHwQyMDAwLqAsoCqGKGh0dHA6
> Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvRXh0ZW5kVmFsMS5jcmwwHQYDVR0OBBYEFCsg
> EL3Qglq9evS4UzoicJ5kMmNwMAkGA1UdEwQCMAAwDgYDVR0PAQH/BAQDAgTwMDQG
> A1UdJQQtMCsGCCsGAQUFBwMBBggrBgEFBQcDAgYKKwYBBAGCNwoDAwYJYIZIAYb4
> QgQBMEsGA1UdIAREMEIwQAYJKwYBBAGgMgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6
> Ly93d3cuZ2xvYmFsc2lnbi5uZXQvcmVwb3NpdG9yeS8wEQYJYIZIAYb4QgEBBAQD
> AgbAMIIBngYDVR0RBIIBlTCCAZGCEHd3dy5teWN1Y2FyZC5jb22CGGF1dGhlbnRp
> Y2F0ZS5pbGN1c3lzLmNvbYIIbHlueGdhdGWHBMCoChiCDTE5Mi4xNjguMTAuMjSC
> E3JlcG9ydHMuaWxjdXN5cy5jb22CEG1haWwuaWxjdXN5cy5jb22CC2luZmluaXRp
> MmszhwTAqMgOgg4xOTIuMTY4LjIwMC4xNIIHcmVwb3J0c4cEwKgKAoIMMTkyLjE2
> OC4xMC4yhwTAqAodgg0xOTIuMTY4LjEwLjI5hwTAqAoJggwxOTIuMTY4LjEwLjmC
> FGdpZnRjYXJkLmlsY3VzeXMuY29tgghpY3VsYXBwNYIPd3d3LmlsY3VzeXMuY29t
> ggtpbGN1c3lzLmNvbYIYYXV0b2Rpc2NvdmVyLmlsY3VzeXMuY29tghZzZWN1cmVt
> YWlsLmlsY3VzeXMuY29thwTAqG4Bgg0xOTIuMTY4LjExMC4xhwTAqAoDggwxOTIu
> MTY4LjEwLjOHBMCoCgeCDDE5Mi4xNjguMTAuN4IHYW9zc3J2MTANBgkqhkiG9w0B
> AQUFAAOCAQEAR979OkjaWLAyoH09SQbV4RauKlZn6RfgC741YJHMQcjIPPMlFdcm
> bzuxF3t/MRS+7oNDjPoG8EYxXa1AJE/Wkwu+vyzTHannKfZ/p6L4l8Z/58RUpuxM
> gSS+78csxg5J9+AGaBqXgErQjks54nliCZ+FvAwPHo9a6Abt1hGScTr3F6DsNdRY
> W/zXAnqtHmfNzYFkn2kKScq29+265qY+fhjRsMwhuaWlM9cpolzY3v6vkh/19umy
> 0fJKrtnvynhM0Vrrp3b4aSD1xEnsCKXrfn+vjswWENilgu7FrxefUt2zy76gj/Ka
> 68T3xsJDFxg7RWraJGXvjXfPYdOuVxk5xQ==
> -----END CERTIFICATE-----
>
>
> CyberTrust EV for a wildcard (CN in Subject is
> '*.amos.hosting.accenture.com)
> -----BEGIN CERTIFICATE-----
> MIIExTCCA62gAwIBAgILAQAAAAABKyD1HsEwDQYJKoZIhvcNAQEFBQAwPzEXMBUG
> A1UEChMOQ3liZXJ0cnVzdCBJbmMxJDAiBgNVBAMTG0N5YmVydHJ1c3QgU3VyZVNl
> cnZlciBFViBDQTAeFw0xMDA5MTcxNzMyMDFaFw0xMjA5MTcxNzMyMDFaMIHpMQsw
> CQYDVQQGEwJVUzELMAkGA1UECBMCSUwxEDAOBgNVBAcTB0NoaWNhZ28xFzAVBgNV
> BAkTDjE2MSBOIENsYXJrIFN0MRMwEQYLKwYBBAGCNzwCAQMTAlVTMRMwEQYLKwYB
> BAGCNzwCAQITAklMMRYwFAYDVQQKEw1BY2NlbnR1cmUgTExQMRswGQYDVQQPExJW
> MS4wLCBDbGF1c2UgNS4oYikxDDAKBgNVBAsTA1NVUzEOMAwGA1UEBRMFMDA2MjIx
> JTAjBgNVBAMMHCouYW1vcy5ob3N0aW5nLmFjY2VudHVyZS5jb20wggEiMA0GCSqG
> SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDEmm+7j7gczKcH6FL/u4tE28m9FRsUF+55
> bGLKFe2gnLxKl0k4PGDw/YFrjUomcsyHsD14Txg9xEZy6SnIy3QO1l39R1gjifPV
> BLGUMXGqpj0hWihwRKZ8fdtoTEknEtE0MKz5hoQlEjUdBt2vdWUWlh89wAU86dZ1
> hPHKPaWvol1OxIZnRNQsR5t8AnNXmlvXchk9p+Muf8M7YOQSJn5Q06EJScrssTzi
> UK8gup7eFo55rePZ5qdHf3DTi4qdusfUJd/S5IGBnrym5MrihGDgLuXuRjmaQp1Q
> ntdZBpz1rJtrYHm9LXz+9hjR/u+8+fy53if8ifvl94TieTl2sZY3AgMBAAGjggEV
> MIIBETAfBgNVHSMEGDAWgBSbe1jrPQPkh8jkjOpGfJJU6Ta7njA5BgNVHR8EMjAw
> MC6gLKAqhihodHRwOi8vY3JsLm9tbmlyb290LmNvbS9TdXJlU2VydmVyRVYuY3Js
> MB0GA1UdDgQWBBQKc2BMGSmdqWMstaXG4atzjq1GzjAJBgNVHRMEAjAAMA4GA1Ud
> DwEB/wQEAwIFoDBQBgNVHSAESTBHMEUGCisGAQQBsT4BZAEwNzA1BggrBgEFBQcC
> ARYpaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRvcnkwJwYD
> VR0RBCAwHoIcKi5hbW9zLmhvc3RpbmcuYWNjZW50dXJlLmNvbTANBgkqhkiG9w0B
> AQUFAAOCAQEAtnyBKU6CKr3Rmw8Mx08uEwRfwlnfOlaNLS+MZQMY2uglxy8bO16c
> S9xArgiUWcxIJz67Go20dP7dhHdVtYfMJZhG37tQzyoWD6A5su4FZSBY2Mh81xA/
> yk/NWpzoz2QDP+UpqyijUGCGgy+EZlBxQ8QfkPEWow9/PpiA/9N4A86EHih5VPRY
> uQ/DwDwcOLC8RwwJnG9dJFd7VXc2/AbHTkqwQ/8aVcuDtU811AYWybeQDRK8HfvT
> KlygjWAGtmHq9Fj76ZW4TC3Fn6STLcyUIYxD1YIt3SqKMNWRvsmq0H3l3Gu/xLvL
> 5AH/PQ1ZbJUVAPoPlx1NKUUy8aKpeJjTHA==
> -----END CERTIFICATE-----
>
>
> What are the consequences of these actions, and the blatant violation
> of the EV guidelines?
> Will Mozilla pull the EV-enablement of these EV root CAs?
budd...@gmail.com
Varga Viktor
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customer Service Executive
Netlock Kft.
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________