Re: [Full-disclosure] Western Union Certificate Error

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

Consider the recent DigiNotar mess - they actually issued (among many other
things) a signed invalid cert for * 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

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:

So we don't need any new RFCs. ;)

Attachment: pgp4MyBJgQfym.pgp
Description: PGP signature

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -