Date: Sun, 11 Sep 2011 09:04:53 +0700
From: JT S <whytehorse@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Western Union Certificate Error

I think the key difference is that the certs are still valid even
after a breach. Maybe my browser would pop up and say "This
certificate is still the one you trusted but the notary signature has
been revoked because they got hacked, do you want to continue to trust
this notary?" so if you answer no then your browser will stop
accepting certs signed by that notary and you have to go find a new
notary, but the certs you already trusted keep working fine. A good
feature to have would be for the browser to check the date of the hack
and remove trust for all certs issued after the hack. With multiple
notaries signing one cert it would go on functioning fine even if only
one got hacked. Sort of like your key which has 6 bad signatures and 8
good ones.

In the present system, if a CA get's hacked we have to remove them
from the trusted chain which revokes all their keys and everyone has
to reissue their keys with a different CA. We also lack the ability to
issue and sign our own keys that we generate later. Given the price of
certs these days it makes sense to try to reduce it down to the same
price as a notarization(thus ending the race to the bottom).... I
think the whole browser SSL CA model is fundamentally flawed and we
should be using the GPG with public notaries model instead. The only
obstacle I can see is getting notaries to use computers and identify
when they've been breached. Perhaps some kind of liveCD with Ubuntu
Notary Edition? hehe. Then just have audits of the notaries performed
daily by an automated check. The same physical security requirements
would automatically apply to the computer used to notarize as would
apply to their book of signatures they normally are required to keep
safe. In the case where an entire system of notaries is corrupt you
can revoke their entire region by postal code, province, or even
country. I can imagine fake notaries popping up all over China,
bribing the officials to certify them, etc. For people doing business
in China and who are required by law to have some Chinese
notarization, they can go to Wang's house of certs. If they want to do
business with me they need to go to one of the embassies I trust and
get their ID verified and their cert notarized/signed. Since it's a
crime to knowingly provide false info to one of these embassies I now
have some recourse in the event that I am defrauded by the owner of
the key.

Perhaps the real difference is I have a choice? I suppose I have a
choice right now to remove all the CA certs but I don't really have a
choice of who I ask to verify a certificate. It might be better to
have lots of little sticks rather than one big stick.

On Sun, Sep 11, 2011 at 12:26 AM,  <Valdis.Kletnieks@...edu> wrote:
> 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. ;)
>



-- 
James Snodgrass
(303) 736-9452

CONFIDENTIALITY NOTICE This E-Mail transmission (and/or the documents
accompanying it) is for the sole use of the intended recipient(s) and
may contain information protected by the attorney-client privilege,
the attorney-work-product doctrine or other applicable privileges or
confidentiality laws or regulations. If you are not an intended
recipient, you may not review, use, copy, disclose or distribute this
message or any of the information contained in this message to anyone.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy all copies of this message and any
attachments.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists