Trusting Google to certify the world's systems hardly seems wise. What _does_ seem wise would be for each certificate to certify multiple independent chains of

Trusting Google to certify the world's systems hardly seems wise. What _does_ seem wise would be for each certificate to certify multiple independent chains of identity: each certificate should certify hostname, IP address and national identity at a minimum, and possibly also things like BBB status, trade association status &c. How could this work? Imagine the case of HTTPS at 74.125.227.241 (of of the IPs www.google.com resolves to). My browser would have public keys from the IANA and from the US federal government (and possibly others); it would trust IANA to vouch for IP addresses and DNS, and would trust the US to trust for national identity. The IANA would sign a certificate stating that ARIN are permitted to assign their various blocks of addresses; ARIN would sign a certificate for the block 74.125.227.241 is in themselves, or a middleman if there is one. Google would sign a certificate for the machines behind 74.125.227.241, stating that they are permitted to use that IP address (wildcards could be used in the probably case that one machine actually responds to more than one IP address). My computer, talking to 74.125.227.241, would receive this certificate chain and can see IANA->ARIN->(middleman)->Google->...->machine, and can verify that there is no spoofing. I think that some of this is theoretically possible with IPsec, but I don't know if it's used anywhere. Meanwhile, IANA would also have signed certificates stating that Verisign are allowed to vouch for holders of .com names. Verisign could sign a certificate stating that Google are allowed to vouch for holders of google.com names, and Google could sign certificates stating that various subunits are permitted to sign certificates for various subdomains of google.com. This is similar to the current CA structure, only with the addition of delegation and subdomains, which is really, really key. Because of this, there would be no way for, e.g., INRegistry to vouch for google.com, or any .com, because they only have the right for *.in. Even more important, the holder of each certificate could further subdelegate the authority he received, either in whole (in order hold a secure, ultimately-trusted offline key), or to grant limited privileges to different units. Thus apps.google.com might be delegated to one group and www.google.com to another. Some of this is done via DNSSEC currently. The US federal government would sign a certificate granting the state of Delaware the ability to vouch for corporations under its jurisdiction; Delaware would sign a certificate stating that 'GOOGLE INC' is indeed a Delaware corporation. The US federal government could _also_ sign a certificate for Google, vouching for their tax identification and whatever. The BBB could do the same thing, indicating that the Delaware corporation 'GOOGLE INC' holds a particular level of recognition. MasterCard could issue a certificate indicating that Google is permitted to charge credit cards for amounts up to whatever. So, the browser trusts IANA to certify DNS names & IP address; it trusts the US government (and possibly others) to certify corporate identities; it trusts the BBB to say nice things about companies; it trusts MasterCard (and others) to say that Google are permitted to receive my credit card info. So the browser bar might show green, because DNS & IP addresses are good; it might show the flags of the US & Delaware, because GOOGLE INC is a Delaware corporation (a foreign subsidiary of Google might show its local nation's flag as well); it might show a C- for Google's BBB rating; it might show a MasterCard logo, or just a '$' or local currency sign. The browser might outright refuse to display a page where IP & DNS authorisations did not exist, and might display warnings on pages with IP & DNS authorisations but lacking legal identities. Of course, in reality each of these entities would probably have an offline key which is what was vouched for; that offline key would then be used on, say, an annual or monthly to certify online secure keys, which might then be used on an hourly basis to certify endpoint keys. You what's really cool? All of the work required to efficiently represent & calculate on (e.g sign & verify not just a single certificate, but an entire chain) the certificates need to do this has already been done, almost 15 years ago. It was a standard called SPKI, and it knocks the current X.509-based XPKI dead. An efficient binary representation; easily-parsed human-readable certificates; trust calculus; it was all there. A lot of folks say that SPKI died because it eliminated the need for CAs, but if you look at all the above there are more, not less authorities; there'd clearly be a space to market certificate services, to offer insurance &c. Granted, I don't see a lot of room for the current model where a company pays someone to vouch for them, and I trust that voucher, despite there being no relationship of trust between mee and the vouching entity.