On Sat, 10 Sep 2011 09:39:37 +0700, JT S said: > It wouldn't be that hard to set up an SVN repo with the public key of > someone like google. I could then check it out, take the copy over to > some notary or the company themselves, verify it, sign it, check it > back in. And before you sign it, you and the notary verify that it's actually Google's public key and not an imposter, how, exactly? And more importantly, does your scheme still work if you and the notary discover that, in fact, nobody's bothered to check the public key for "Billy Bob's Bait, Tackle, and App Store" so you can't rely on "Wow, 3,495,435 people signed it, it *must* be right"? This is a problem that a CA usually solves by doing whatever verification of the request (consider the difference between a regular CA-signed SSL cedrtificate and an :"Extended Validation" certificate), and PGP solves with key-signing parties that involve checking of driver's licenses and the like. And are you really willing to pay out of *your* pocket to do the checking that an Extended Validation cert requires? How many times will you do that? It really doesn't scale well anyhow - how many times do you think Google wants to answer the phone and say "Yes, *yawn* key 3,494,342 is really us" (and more importantly - how did you verify that it was Google answering the phone?). At this point, your scheme them becomes "the first guy who bothers to check the key becomes a CA" - and you trust that guy, *why*, exactly? Does your scheme continue to work in a world where I have 12 signatures on my PGP key, and I've blacklisted 6 keys because I *know* they signed my key without doing any proper validation? tl;dr: The hardest part of crypto is always key management.
Attachment:
pgpEOQLjzUpVJ.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/