News for hackers. Stuff that matters.
Re:EFF to Verizon: Etisalat Certificate Authority Threatens ... by caf on Saturday August 14, 2010 @01:55AM (#1603003)
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".

Re:EFF to Verizon: Etisalat Certificate Authority Threatens ... by sesqu on Saturday August 14, 2010 @02:40PM (#1603789)
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.

Re:EFF to Verizon: Etisalat Certificate Authority Threatens ... by sqrt17 on Saturday August 14, 2010 @11:13AM (#1603397)
... 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).

Re:EFF to Verizon: Etisalat Certificate Authority Threatens ... by caf on Monday August 16, 2010 @09:11PM (#1609885)
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_.