Re: Web Browsers and Comodo Announce A Successful Certificate Authority Attack, Perhaps From Iran

Peter Gutmann

unread,

Mar 28, 2011, 9:20:19 PM3/28/11

to eddy...@startcom.org, mozilla-dev-s...@lists.mozilla.org

Eddy Nigg <eddy...@startcom.org> writes:

>Some more: http://pastebin.com/X8znzPWH

For people who didn't follow the link, he's posted the private key
corresponding to one of the bogus certs. The public-key components are
identical, haven't verified that the private key matches yet, but I'm going to
guess it will.

So a global CA wasn't 0wned by a nation-state cyberwar agency but by a random
script kiddie having some fun. Oh the embarassment.

Peter.

Steve Schultze

unread,

Mar 28, 2011, 9:37:28 PM3/28/11

to mozilla-dev-s...@lists.mozilla.org

Robert Graham has described the process of verifying the key (which he
did), although probably most people here already knew how to do that:
http://erratasec.blogspot.com/

it is worth noting that although this essentially proves that the person
posting it was the hacker, it does not prove his claims about who he is
(ie, not the government of Iran)... although I find his claims
moderately credible.

Andy Isaacson

unread,

Mar 28, 2011, 9:39:34 PM3/28/11

to Peter Gutmann, eddy...@startcom.org, mozilla-dev-s...@lists.mozilla.org

On Tue, Mar 29, 2011 at 02:20:19PM +1300, Peter Gutmann wrote:
> Eddy Nigg <eddy...@startcom.org> writes:
> > Some more: http://pastebin.com/X8znzPWH
>
> For people who didn't follow the link, he's posted the private key
> corresponding to one of the bogus certs. The public-key components
> are identical, haven't verified that the private key matches yet, but
> I'm going to guess it will.

Yes, the private key from pastebin.com/X8znzPWH matches the certificate
posted to Mozilla bug 642395 attachment
https://bugzilla.mozilla.org/attachment.cgi?id=519863

% openssl x509 -noout -inform PEM -in a.cer -text | grep -A19 mod > a.mod
% openssl rsa -noout -inform PEM -in b.key -text | grep -A19 Mod > b.mod
% diff -b -u a.mod b.mod
--- a.mod 2011-03-28 18:37:22.000000000 -0700
+++ b.mod 2011-03-28 18:37:09.000000000 -0700
@@ -1,4 +1,4 @@
- Modulus (2048 bit):
+modulus:
00:ab:c6:6d:36:f3:15:73:78:83:73:ce:74:85:d5:
ae:ec:b2:f0:e0:24:1f:13:83:b8:20:ac:bb:9a:fe:
88:bb:ab:a1:1d:0b:1f:45:00:aa:49:b7:35:37:0c:

-andy

Peter Gutmann

unread,

Mar 28, 2011, 10:48:01 PM3/28/11

to mozilla-dev-s...@lists.mozilla.org

To paraphrase Crocodile Dundee, "you call that a successful CA attack? *This*
http://pastebin.com/CvGXyfiJ is a successful CA attack":

"Here is another proof: http://www.multiupload.com/TGDP99CJLH. I uploaded
JUST 1 table of their ENTIRE database which I own."

Looks like *every* Comodo cert-owner account should be regarded as
compromised. Time to pull the root from all the browsers?

Peter.

Gervase Markham

unread,

Mar 29, 2011, 5:59:27 AM3/29/11

to mozilla-dev-s...@lists.mozilla.org

Have you looked at the data provided?

It seems to be data about all the certificates issued by this particular
RA. It includes the CSRs and other personal data, but it does not
include the private keys, and the usernames and (salted, hashed)
passwords that the RA's customers might use to log in to the RA's
system, but of course it does not relate to any other Comodo RA.

I am not surprised the hacker has this data, and it doesn't seem to me
to open up any new avenues of attack relevant to us (of course, you
could do hash cracking and password reuse attacks on other systems owned
by the companies concerned). But I'm very open to being proved wrong.

Gerv

Peter Gutmann

unread,

Mar 29, 2011, 6:15:16 AM3/29/11

to ge...@mozilla.org, mozilla-dev-s...@lists.mozilla.org

Gervase Markham <ge...@mozilla.org> writes:

>It seems to be data about all the certificates issued by this particular RA.
>It includes the CSRs and other personal data, but it does not include the
>private keys,

There seemed to be an awful lot of Italian accounts in there, but it's hard to
tell whether that's just because it's an extract. Why are you so certain it's
their RA and not Comodo itself? (I have no real evidence either way, just
wondering why you think it's only the RA, at best the test implies it's
Comodo's database: "Also ask Comodo about my hack" before he explains how he
did it).

>and the usernames and (salted, hashed) passwords

and password hints to make it easy to guess the password. Note also the use
of repeated salts to point out which passwords are the same.

Peter.

Gervase Markham

unread,

Mar 29, 2011, 6:31:52 AM3/29/11

to mozilla-dev-s...@lists.mozilla.org

On 29/03/11 11:15, Peter Gutmann wrote:
> There seemed to be an awful lot of Italian accounts in there, but it's hard to
> tell whether that's just because it's an extract. Why are you so certain it's
> their RA and not Comodo itself? (I have no real evidence either way, just
> wondering why you think it's only the RA, at best the test implies it's
> Comodo's database: "Also ask Comodo about my hack" before he explains how he
> did it).

I think it's just the RA because both the explanation from the hacker
and the explanation from Comodo agree in what happened (he hacked the RA
and used the username and password to access Comodo's issuance site),
and this scenario does not indicate he got access to Comodo's internal
databases. The data presented is consistent with that view. (E.g. the
column names are in Italian, which would be unusual for a Comodo database.)

>> and the usernames and (salted, hashed) passwords
>
> and password hints to make it easy to guess the password. Note also the use
> of repeated salts to point out which passwords are the same.

Indeed; I am not holding up this RA as an example of good practice! I
was just noting that the passwords were salted and hashed, which is what
one is supposed to do.

I suspect the repeated salts and passwords are just examples of bad data
normalization.

Gerv

Patrick Tate

unread,

Mar 29, 2011, 3:59:57 AM3/29/11

to mozilla-dev-s...@lists.mozilla.org

On Mar 29, 3:48 am, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> To paraphrase Crocodile Dundee, "you call that a successful CA attack? *This*http://pastebin.com/CvGXyfiJis a successful CA attack":

>
> "Here is another proof:http://www.multiupload.com/TGDP99CJLH. I uploaded
> JUST 1 table of their ENTIRE database which I own."
>
> Looks like *every* Comodo cert-owner account should be regarded as
> compromised. Time to pull the root from all the browsers?
>
> Peter.

Peter - I think that's a list of customers from the compromised
partner. Nowhere near every Comodo cert-owner, I'm sure.

Pat

Peter Gutmann

unread,

Mar 29, 2011, 8:10:47 PM3/29/11

to eddy...@startcom.org, mozilla-dev-s...@lists.mozilla.org

Eddy Nigg <eddy...@startcom.org> writes:
>On 03/29/2011 10:28 PM, From Eddy Nigg:
>> On 03/29/2011 06:54 PM, From Robin Alden:
>>> Two further RA accounts have since been compromised and had RA
>>> privileges withdrawn. No further mis-issued certificates have
>>> resulted from those compromises.
>>
>> Thanks Robin for disclosing it.
>
>Well, apparently somebody else did that already earlier today:
>http://pastebin.com/kkPzzGKW

Isn't it lucky for us that the bad guys are thoughtfully notifying us of
everything they've done? As I've already asked fairly early on in this
discussion, how many unknown compromises could there still be in this house of
cards? [0].

Peter.

[0] By which I mean all CAs, not Comodo specifically.

Eddy Nigg

unread,

Mar 30, 2011, 6:27:46 AM3/30/11

to mozilla-dev-s...@lists.mozilla.org

On 03/30/2011 02:10 AM, From Peter Gutmann:

> [0] By which I mean all CAs, not Comodo specifically.

Thanks for leaving your signature, I was already doubting if I'm
communicating with the real Peter Gutmann. That doubt has been cleared
by now ;-)

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

scream

unread,

Mar 30, 2011, 9:39:04 AM3/30/11

to dev-secur...@lists.mozilla.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/30/2011 04:27 AM, Eddy Nigg wrote:
> On 03/30/2011 02:10 AM, From Peter Gutmann:

>> [0] By which I mean all CAs, not Comodo specifically.
>

> Thanks for leaving your signature, I was already doubting if I'm
> communicating with the real Peter Gutmann. That doubt has been cleared
> by now ;-)
>

The meaning here is lost to me.

Jon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2TMnQACgkQxlOuhm8Z7WOWZACfVqUdPhMYGEyOfLUe+EzVU+fb
z0EAn1f4IkE7T9/okGXg3QKxZ4Iau7LZ
=wb1T
-----END PGP SIGNATURE-----

Daniel Veditz

unread,

Mar 30, 2011, 9:41:16 PM3/30/11

to Gervase Markham

On 3/29/11 2:59 AM, Gervase Markham wrote:
> I am not surprised the hacker has this data, and it doesn't seem to
> me to open up any new avenues of attack relevant to us (of course,
> you could do hash cracking and password reuse attacks on other
> systems owned by the companies concerned).

If you could crack the passwords (bet a dictionary attack would be
fast and effective on several accounts), and if the RA were ever
reinstated, you might then be able to get additional certs issued
for the customer's domains.

Is the "revocation" of the RA by Comodo permanent?
Are any of the customer domains worth MITMing?

-Dan

Gervase Markham

unread,

Mar 31, 2011, 7:18:56 AM3/31/11

to mozilla-dev-s...@lists.mozilla.org

On 31/03/11 02:41, Daniel Veditz wrote:
> On 3/29/11 2:59 AM, Gervase Markham wrote:
>> I am not surprised the hacker has this data, and it doesn't seem to
>> me to open up any new avenues of attack relevant to us (of course,
>> you could do hash cracking and password reuse attacks on other
>> systems owned by the companies concerned).
>
> If you could crack the passwords (bet a dictionary attack would be
> fast and effective on several accounts), and if the RA were ever
> reinstated, you might then be able to get additional certs issued
> for the customer's domains.

Given that this information has been published, I strongly suspect (and
hope!) all the authentication information in it will be considered
compromised.

> Is the "revocation" of the RA by Comodo permanent?
> Are any of the customer domains worth MITMing?

I asked Comodo to:

> 2) Revoke the RA rights of the RA concerned.

And Robin replied:

"This has already been done."

Although I guess it's not entirely clear from that whether the
revocation is permanent, that was certainly our intent in the request.

Gerv

Michael Ströder

unread,

Apr 11, 2011, 12:12:32 PM4/11/11

to mozilla-dev-s...@lists.mozilla.org

Peter Gutmann wrote:
> As I've already asked fairly early on in this
> discussion, how many unknown compromises could there still be in this house of
> cards?

I mentioned something like this here two years ago. One of my customers has a
fully-trusted sub-CA and the root CA with its "trusted" root CA cert did not
even read the CPS I wrote. Not to speak of an audit. They can issue any cert
they want. => pay some bucks and you can do whatever you want.

Since there was no interest in punishing CAs for bad practices back then I
lost interest in reviewing policy documents here. Because if a CA fails
nothing happens. So the CP/CPS stuff doesn't matter at all.

Ciao, Michael.

Peter Gutmann

unread,

Apr 12, 2011, 10:17:56 AM4/12/11

to mic...@stroeder.com, mozilla-dev-s...@lists.mozilla.org

=?ISO-8859-1?Q?Michael_Str=F6der?= <mic...@stroeder.com> writes:

>I mentioned something like this here two years ago. One of my customers has a
>fully-trusted sub-CA and the root CA with its "trusted" root CA cert did not
>even read the CPS I wrote. Not to speak of an audit. They can issue any cert
>they want. => pay some bucks and you can do whatever you want.

This is pretty much the case for any non-public CA certified by a public CA
that I know of, the deal is basically "your payment has cleared, here's your
cert, we'll be in touch when the renewal fee is due". The security model is
pretty much "gosh, I hope nothing goes wrong at any point". This is why I'm
always careful to qualify my comments about public CAs with a rider about the
iceberg problem of non-visible private CAs that could be doing more or less
anything they want without anyone knowing about it (actually there have been
cases where private CAs have done some interesting things, in a non-malicious
manner, just to see what they can get away with. The amusing thing is that
since revocation doesn't work, once you've paid for your private-label CA
you've got it for the full year even if you decide to cancel your contract
after a week. So an interesting attack vector would be: buy a private-label
CA cert, cancel the contract almost immediately, "my wife didn't like the
colour of the dashboard", and get your money back, and then spend a year
issuing certs for anyone you like).

As I've said numerous times before, the public CA mess is only the tip of the
iceberg. Private-label CAs that are implicitly trusted because they've bought
their certs off public CAs are invisible, effectively unregulated, and
uncontrollable.

Speaking of CA spaghetti, I recently tried to track down a CA cert after I
followed a cert chain that seemed to bounce from one unrelated CA to another,
ending up with Comodo. It seems that Comodo, a US company, bought ScandTrust
out of Malmo in Sweden, who had in turn absorbed AddTrust from Stockholm,
Sweden, and at the same time bought UserTrust from Salt Lake City, Utah who
had certified Digi-Sign of Ireland (an SSL CA which is of interest primarily
because it doesn't use SSL itself to secure access to its web-based accounts)
later owned by the Dutch Getronics, and beyond that the spaghetti of sold, re-
sold, and crosslinked CAs and keys becomes more or less impenetrable. Can
anyone provide any more information on where these things both come from and
end up? I felt like a forensic accountant trying to unravel Enron's shell
companies when trying to untangle this mess.

Peter.

Eddy Nigg

unread,

Apr 12, 2011, 10:41:58 AM4/12/11

to mozilla-dev-s...@lists.mozilla.org

On 04/12/2011 05:17 PM, From Peter Gutmann:

> This is pretty much the case for any non-public CA certified by a public CA
> that I know of, the deal is basically "your payment has cleared, here's your
> cert, we'll be in touch when the renewal fee is due".

Just don't throw all CAs into the same basked, there are some who simply
take everything very serious they do. There might be failures there too,
but the attitude is entirely different.

> Speaking of CA spaghetti, I recently tried to track down a CA cert after I
> followed a cert chain that seemed to bounce from one unrelated CA to another,
> ending up with Comodo. It seems that Comodo, a US company, bought ScandTrust
> out of Malmo in Sweden, who had in turn absorbed AddTrust from Stockholm,
> Sweden, and at the same time bought UserTrust from Salt Lake City, Utah who
> had certified Digi-Sign of Ireland (an SSL CA which is of interest primarily
> because it doesn't use SSL itself to secure access to its web-based accounts)
> later owned by the Dutch Getronics, and beyond that the spaghetti of sold, re-
> sold, and crosslinked CAs and keys becomes more or less impenetrable. Can
> anyone provide any more information on where these things both come from and
> end up? I felt like a forensic accountant trying to unravel Enron's shell
> companies when trying to untangle this mess.

Conclusion?

Peter Gutmann

unread,

Apr 12, 2011, 10:19:28 PM4/12/11

to eddy...@startcom.org, mozilla-dev-s...@lists.mozilla.org

Eddy Nigg <eddy...@startcom.org> writes:

>Just don't throw all CAs into the same basked, there are some who simply take
>everything very serious they do. There might be failures there too, but the
>attitude is entirely different.

Sure, this was specifically for cases that I had direct experience with. The
problem is that even with careful, conscientious CAs, the overall security is
only as good as the most negligent, least conscientious CA of the lot (see my
comments during the Mozilla discussion last week on how to deal with this,
which includes both penalising negligent CAs and rewarding conscientious ones).

>Conclusion?

I was hoping somebody could help sort out the mess, or alternatively, if it
turns out that no-one can, that it was a good illustration of the lack of
overview of what's actually going on.

Peter.

Kyle Hamilton

unread,

Apr 12, 2011, 10:27:27 PM4/12/11

to Peter Gutmann, eddy...@startcom.org, mozilla-dev-s...@lists.mozilla.org

On Tue, Apr 12, 2011 at 7:19 PM, Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:
>
> I was hoping somebody could help sort out the mess, or alternatively, if it
> turns out that no-one can, that it was a good illustration of the lack of
> overview of what's actually going on.

By "the mess" do you mean "the current owners of Mozilla's trusted CAs' keys"?

-Kyle H

Peter Gutmann

unread,

Apr 12, 2011, 11:09:42 PM4/12/11

to aero...@gmail.com, pgu...@cs.auckland.ac.nz, eddy...@startcom.org, mozilla-dev-s...@lists.mozilla.org

"Kyle Hamilton" <aero...@gmail.com> writes:

>By "the mess" do you mean "the current owners of Mozilla's trusted CAs' keys"?

Yes. It seems to be more or less impossible to determine who holds the keys,
and what relationships they have with other key holders. Seeing a cert chain
that goes CA1 -> Totally unrelated different-named CA1 -> Totally unrelated
different-named CA2 -> EE (where each of the three CAs gives the impression of
being a trusted root CA and/or whose brand was a trusted root CA at one point)
rather makes you wonder what's going on.

Peter.

Gervase Markham

unread,

Apr 13, 2011, 6:25:36 AM4/13/11

to mozilla-dev-s...@lists.mozilla.org

On 13/04/11 04:09, Peter Gutmann wrote:
> "Kyle Hamilton"<aero...@gmail.com> writes:
>
>> By "the mess" do you mean "the current owners of Mozilla's trusted CAs' keys"?
>
> Yes. It seems to be more or less impossible to determine who holds the keys,
> and what relationships they have with other key holders.

This document:
https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
is supposed to sort out the ultimate owners of every root key we have.

My understanding is that Kathleen has a private extension to that
document with contact details for each CA.

Gerv

Eddy Nigg

unread,

Apr 13, 2011, 6:36:50 AM4/13/11

to mozilla-dev-s...@lists.mozilla.org

On 04/13/2011 05:19 AM, From Peter Gutmann:

> I was hoping somebody could help sort out the mess, or alternatively, if it
> turns out that no-one can, that it was a good illustration of the lack of
> overview of what's actually going on.

Considering that some browser vendors set a cap of 3 CA roots, but some
others have way more than that, perhaps some clean up work is necessary.

It’s hard to justify the case of AddTrust, UserTrust and others where
the company has died and the root has been bought simply to flog for
cross-signing purposes. A lot of the confusing tangle is related to
these “orphan” roots.

Rob Stradling

unread,

Apr 13, 2011, 7:04:02 AM4/13/11

to dev-secur...@lists.mozilla.org, Eddy Nigg

On Wednesday 13 Apr 2011 11:36:50 Eddy Nigg wrote:
> On 04/13/2011 05:19 AM, From Peter Gutmann:

> > I was hoping somebody could help sort out the mess, or alternatively, if
> > it turns out that no-one can, that it was a good illustration of the
> > lack of overview of what's actually going on.
>

> Considering that some browser vendors set a cap of 3 CA roots, but some
> others have way more than that, perhaps some clean up work is necessary.
>
> It’s hard to justify the case of AddTrust, UserTrust and others where
> the company has died and the root has been bought simply to flog for
> cross-signing purposes. A lot of the confusing tangle is related to
> these “orphan” roots.

Windows/IE and Opera have "dynamic root update" facilities. When a new root
certificate is approved, it is pushed to all existing users without them
having to do anything.
Firefox, and many other clients, don't have such a facility. New roots only
become available when users upgrade the browser itself.

If every browser had a "dynamic root update" facility, it would be feasible
for CAs to deprecate legacy "orphan" roots. Today, it is not feasible,
because customers of CAs care about whether or not their server certificates
will cause "CA not trusted" warnings in legacy browsers and in browsers that
don't have "dynamic root update" facilities.

Could NSS/PSM be "enhanced" to record/display details about who currently
owns/controls/operates each root?

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

Kyle Hamilton

unread,

Apr 13, 2011, 4:17:49 PM4/13/11

to Rob Stradling, Eddy Nigg, dev-secur...@lists.mozilla.org

On Wed, Apr 13, 2011 at 4:04 AM, Rob Stradling <rob.st...@comodo.com> wrote:
> On Wednesday 13 Apr 2011 11:36:50 Eddy Nigg wrote:
>> On 04/13/2011 05:19 AM, From Peter Gutmann:
>> > I was hoping somebody could help sort out the mess, or alternatively, if
>> > it turns out that no-one can, that it was a good illustration of the
>> > lack of overview of what's actually going on.
>>
>> Considering that some browser vendors set a cap of 3 CA roots, but some
>> others have way more than that, perhaps some clean up work is necessary.
>>
>> It’s hard to justify the case of AddTrust, UserTrust and others where
>> the company has died and the root has been bought simply to flog for
>> cross-signing purposes. A lot of the confusing tangle is related to
>> these “orphan” roots.
>

> If every browser had a "dynamic root update" facility, it would be feasible
> for CAs to deprecate legacy "orphan" roots. Today, it is not feasible,
> because customers of CAs care about whether or not their server certificates
> will cause "CA not trusted" warnings in legacy browsers and in browsers that
> don't have "dynamic root update" facilities.

This, too, is an example of "one credential is all you'll ever need (so it's all we'll give you to use)", forcing individual sites to immediately change their certs if a given root is disabled.

My proposed protocol allows multiple credential chains to be asserted. This would allow sites to use multiple CAs, and thus reduce the impact of any given root's suspension on their business recovery processes. (A site utilizing the protocol would use the symmetric cipher NULL for both the box and the envelope, as it would not have the user's public key. The asymmetric cipher used to bind the content to the envelope to the box can be any cipher trustworthy.)

Oh wait, I forgot, this isn't about the site, and it's not about the user -- it's about the gravy train the CAs currently enjoy.

> Could NSS/PSM be "enhanced" to record/display details about who currently
> owns/controls/operates each root?

As of the time the browser was built, probably -- but dynamic updating of that information would require the build-out of a whole new infrastructure, and would pose a severe privacy risk (akin to OCSP's privacy concerns).

-Kyle H

Peter Gutmann

unread,

Apr 13, 2011, 8:53:42 PM4/13/11

to ge...@mozilla.org, mozilla-dev-s...@lists.mozilla.org

Gervase Markham <ge...@mozilla.org> writes:

>This document:
>https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
>is supposed to sort out the ultimate owners of every root key we have.

Some interesting organisations in there:

Equifax Secure Inc. - MD5 Collisions Inc. (http://www.phreedom.org/md5)

Also, I'm not sure this is terribly useful, given entries like:

The USERTRUST Network - UTN-USERFirst-Network Applications
The USERTRUST Network - UTN - DATACorp SGC
The USERTRUST Network - UTN-USERFirst-Client Authentication and Email
The USERTRUST Network - UTN-USERFirst-Hardware
The USERTRUST Network - UTN-USERFirst-Object

which is actually Comodo (not wanting to pick on them, it was just one of the
examples I used of Cert A owned by Company B, there are many others). To be
honest this table isn't actually useful at all, it doesn't tell you anything
about who owns what, I could get the same data by extracting the fields from
the SSL Observatory.

What I'd like to see is who *really* owns what, and a graph of the
interconnections (see my previous message about the spaghetti of sold and re-
sold CAs along one particular cert chain). Does such a thing even exist?

Peter.

Gervase Markham

unread,

Apr 14, 2011, 10:00:05 AM4/14/11

to Kathleen Wilson

On 14/04/11 01:53, Peter Gutmann wrote:
> Gervase Markham<ge...@mozilla.org> writes:
>
>> This document:
>> https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
>> is supposed to sort out the ultimate owners of every root key we have.
>
> Some interesting organisations in there:
>
> Equifax Secure Inc. - MD5 Collisions Inc. (http://www.phreedom.org/md5)

Researching, it seems that this is in there because it's specifically
marked as untrusted:
http://mxr.mozilla.org/mozilla2.0/source/security/nss/lib/ckfw/builtins/certdata.txt#15475
(lines 15499 and following)

Phew :-)

> Also, I'm not sure this is terribly useful, given entries like:
>
> The USERTRUST Network - UTN-USERFirst-Network Applications
> The USERTRUST Network - UTN - DATACorp SGC
> The USERTRUST Network - UTN-USERFirst-Client Authentication and Email
> The USERTRUST Network - UTN-USERFirst-Hardware
> The USERTRUST Network - UTN-USERFirst-Object
>
> which is actually Comodo (not wanting to pick on them, it was just one of the
> examples I used of Cert A owned by Company B, there are many others). To be
> honest this table isn't actually useful at all, it doesn't tell you anything
> about who owns what, I could get the same data by extracting the fields from
> the SSL Observatory.
>
> What I'd like to see is who *really* owns what, and a graph of the
> interconnections (see my previous message about the spaghetti of sold and re-
> sold CAs along one particular cert chain). Does such a thing even exist?

Given that Kathleen has contact details for the owners of all these
certs (I think), she may be able to add a column giving the current
organizational owner of each. Kathleen: is that possible?

Gerv

Jean-Marc Desperrier

unread,

Apr 14, 2011, 10:03:28 AM4/14/11

to mozilla-dev-s...@lists.mozilla.org

Eddy Nigg wrote:
> Just don't throw all CAs into the same basked, there are some who simply
> take everything very serious they do. There might be failures there too,
> but the attitude is entirely different.

According to the attitude he's showing, I think this Iranian hacker
would have *loved* compromising an israelian CA rather than Comodo.
The fact you were not the victim shows you're doing something right.

Eddy Nigg

unread,

Apr 14, 2011, 2:32:36 PM4/14/11

to mozilla-dev-s...@lists.mozilla.org

On 04/14/2011 05:03 PM, From Jean-Marc Desperrier:

> According to the attitude he's showing, I think this Iranian hacker
> would have *loved* compromising an israelian CA rather than Comodo.
> The fact you were not the victim shows you're doing something right.

Well, I'm not claiming that a compromise can never happen, I think that
would be the wrong message. However there was a decision that we don't
want to support RAs in this manner and as a matter of fact don't use
them at all - due to the risks. I also warned about this problem with
such RAs and sub CAs here at this forum for years. The entries in the
problematic practices referring to RAs and sub CAs are a direct result
if those discussions and unfortunately I was probably right more than
once on this.

Kathleen Wilson

unread,

Apr 14, 2011, 4:28:01 PM4/14/11

to mozilla-dev-s...@lists.mozilla.org

The "Company Website" column shows the current owner.

Kathleen

Peter Gutmann

unread,

Apr 16, 2011, 1:52:16 AM4/16/11

to kathle...@yahoo.com, mozilla-dev-s...@lists.mozilla.org

Kathleen Wilson <kathle...@yahoo.com> writes:

>The "Company Website" column shows the current owner.

Not really, it only shows an arbitrary FQDN. For example according to the
"website" column Thawte isn't owned by Verisign, and Verisign is owned by
Symantec, so the Thawte owner is really Symantec, not what the "website"
column says.

The Valicert ones are particularly interesting, according to the "website"
column the first is owned by SecomTrust in Japan, the second by GoDaddy (but
covered by a StarField CPS), and the third by RSA, which is really EMC. This
just points out yet again what a complete mess this situation is.

Peter.