[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJzM1SsN1Sf2r4TUqiH49cj3kLZP8=f48hON00d1Pxyg=AKdBw@mail.gmail.com>
Date: Sat, 10 Sep 2011 19:50:57 +0700
From: JT S <whytehorse@...il.com>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Western Union Certificate Error
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. 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. 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.
On Sat, Sep 10, 2011 at 7:30 PM, <Valdis.Kletnieks@...edu> wrote:
> 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.
>
--
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