The thing this highlights is the way that CA certificates are all-or-nothing. You can't say "This is a CA, but they should only be trusted for certificates where the CN matches this pattern".

Separate CAs were always a bogus idea. They should have just issued certificates in parallel with domain names - so if I registered "google.com", I also got a certificate from the domain registrar which allowed me to sign certificates for "<anything>.google.com".

I've pretty much always felt that there should be no central authority. I don't know much about the actual protocols in use, but it's my understanding that they're single-signer.

What I would prefer is a multiple-signer system. Each resource can have a list of signatures indicating entities that trust the resource. Each entity can have a list of other entities they trust. Then to verify a resource, you search the web of trust until you hit max_separation while looking for a path from you (source) to the resource (sink).

So to sign my payment processor, I'd self-sign and have visa sign. I'd get a personal signature from the .com authority. You trust visa if you're interested in payment, and you trust the .com authority if you're interested in identity. There would be no difference between authentication and authorization by default, but that would be easy to patch in via specialized authorities.

If some entity turns out to be overly trusting, it would be trivial to replace, since all trust is directed. Just add a new, trustworthy, intermediary. The downside is that much more computation would be required to find the links, but I'm confident that would remain manageable because of the human element; we wouldn't include more trustworthy entities than bureaucracy allows.

There are holes in this scheme, sure. It might even be a subset of the current technology. But I'm fairly certain it'd be a superset of the current practise.

... and if the owner of somerandomdomain.net lets his domain expire, you're faced with the choice of (a) put his SSL key (along with a couple thousand others) on the global CRL, which then grows to monstruous proportions or (b) let the old somerandomdomain owner play man-in-the-middle games with the new somerandomdomain customers?

Also, would that mean that VeriSign (.com registrar) would be your only option for a .com SSL certificate?

(I'm not saying it's a bad idea to limit CA authority to a certain top-level or second-level domain, it's just that I see certain problems with doing it wholesale and in parallel).

It would only have to go onto the CRL until it expired. The CRL would become large, but it would still be a couple of orders of magnitude smaller than the global DNS itself, and we manage to deal with that OK.

The idea would be that the certificate comes with the domain name, as the whole ball of wax. Verisign aren't the only _registrar_ though - GoDaddy, MelbourneIT etc. are all registrars - VeriSign's claim to fame is that they manage the .com _registry_.

Oddly enough, GTE Cybertrust doesn't actually seem to be the same Cybertrust that Verizon Business bought in 2007 (as information on "GTE Cybertrust" predates the incorporation of "Cybertrust" by a good ten years).

It looks like GTE Cybertrust was part of GTE Internetworking, which would have been absorbed into the Bell Atlantic-GTE merger which created Verizon.

That seems odd.

You don't have to delete certificate, you can mark it as "Never Trust".

On OS X, it is possible to disable just Etisalat's Comtrust certificate. Click the lock icon to view that certificate, drag the large certificate icon to your desktop, then drag it into Keychain Access (i.e. into your login keychain). At that point, you can set the trust settings on that certificate to Never Trust.

Neat! I'm surprised and happy this works; I presumed the Apple SSL framework would only check the trust setting on the root.

Unfortunately, you can't (as far as I can tell) do this with Firefox; import the Comtrust certificate and turn off "use to validate websites", restart Safari, and it'll still accept the Etisalat site.

What does work is to take the CER file, pop it open in a hex editor, whack 1 byte of it, and import that; the result is a mismatched certificate error on sites signed by Etisalat/Comtrust.

...go to http://j.mp/a11K0t [Etisalat site]

> This site requires Internet Explorer !

If you were looking for more reasons to dislike these guys I guess...

In OS X Opera, you can go to Preferences -> Advanced -> Security -> Manage Certificates -> Authorities. Select the GTE CyberTrust one and either Delete it, or disable it from the "View..." screen.

"This will probably break a bunch of other random sites validation. Oh well."

Fun fact! Among said sites, PayPal. Or more specifically, paypalobjects.com which hosts their CSS.

They signed a CA=YES cert for Akamai. Lovely.