On Sat, 10 Sep 2011 19:50:57 +0700, JT S said: > It doesn't matter who signed it because I only look for whether or not > I signed it or if my favorite notary signed it. You missed the point. You care you signed it - but how do you know you signed a valid cert that actually belonged to Google, and you didn't sign a fake Googlle cert? And if you only trust it because "my favorite notary" signed it, how is it different from the *current* CA model, where you trust a cert only because a CA you trust signed it? > I would imagine that a digital notary would have their own key and goog could > walk in and get their cert signed the same way we do documents. If that > notary > get's breached I can stop trusting their signature but still trust goog unless > they get breached too. Umm.. we do that *now* - it's called a CA. And we know how well that works. This "notary" called DigiNotar got breached recently, and everybody is installing patches to not trust their signature. Except that without some valid signature on it *that you trust*, you have no reason to trust the Google cert after the CA gets breached. Think this through: You're trusting the Google cert because the CA/notary/whatever told you it was Google. Now if you discover the registrar is bad, you should *not* trust the Google cert anymore *either*. Consider the recent DigiNotar mess - they actually issued (among many other things) a signed invalid cert for *.google.com. Everybody who revoked DigiNotar is then protected against that invalid cert. But if you had signed/ flagged it trusted/whatever because DigiNotar said it was OK, and then revoked DigiNotar but then continued to trust that cert because you signed it - *you are still vulnerable to that bad cert*. > So essentially each person would have the ability to issue their own cert and > get it notarized. If the signatures of the notaries match on my cert and > someone else's cert, I know they are who they say they are to the limit > possible with notaries(e.g. you could still use a fake ID). I suppose it could > be scaled by issuing an RFC which lays out the method of notarization and have > all the notaries sign each other's keys etc. Congratulations. You've re-invented *exactly* how CA's work now, (right down to the 'issue their own cert and get it notarized - the PKCS standards call this a "certificate signing request" - see PKCS#10 or RFC2986) except for three details: 1) It isn't "the signatures match" - the check made is "the cert was signed by the same key that I have a trusted copy of the public key to verify the signature with" (the actual signatures will *never* match unless somebody manages to force a signature collision, which is generally a Really Bad Thing ;) 2) the part about notaries signing each other's keys, which doesn't actually buy you much except for being able to establish a trust for a totally new notary. But currently everybody seems to be OK with "I have no reason to trust these 600 CAs other than their certs came with my browser", so we'll probably just wait for your vendor to send you an update with 601 CA keys in it rather than trying to deploy a cross-signature scheme. 3) It doesn't address the two biggest validation weaknesses in the CA scheme - (a) that somebody uses faked credentials to get the CA to sign the cert (see the CERT advisory from 2001 about Verisign accidentally signing a bogus Microsoft cert), and (b) somebody can steal the digital equivalent of the notary's stamp (I'm looking at you, DigiNotar.. ;) And yes, there *is* a standard (set of them, actually) for all this: https://secure.wikimedia.org/wikipedia/en/wiki/PKCS So we don't need any new RFCs. ;)
Attachment:
pgpyHI1Zoq8hP.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/