[8095] in cryptography@c2.net mail archive
Re: Public Key Infrastructure: An Artifact...
daemon@ATHENA.MIT.EDU (Ben Laurie)
Sun Nov 19 12:16:21 2000
Message-ID: <3A17CF98.CA58D9B6@algroup.co.uk>
Date: Sun, 19 Nov 2000 13:03:20 +0000
From: Ben Laurie <ben@algroup.co.uk>
MIME-Version: 1.0
To: Lynn.Wheeler@firstdata.com
Cc: Bram Cohen <bram@gawth.com>, obfuscation@beta.freedom.net,
rah@shipwright.com, cryptography@c2.net, cypherpunks@cyberpass.net,
dbs@philodox.com, dcsb@ai.mit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lynn.Wheeler@firstdata.com wrote:
>
> actually ... not really ... this was discussed early this summer as to what they
> actually check ... and how trivial it is to fabricate necessary details to pass
> such checking
>
> random ref:
>
> http://www.garlic.com/~lynn/aadsmore.htm#client3
>
> in general it is sufficient to have registered any DBA name & have a d&b entry
> plus some misc. other stuff ... all relatively easy to establish. Since the DBA
> name & d&b entry aren't cross-checked as part of the SSL certificate validation
> ... just the domain name in the certificate against the domain name used ... you
> could be really surprised at what comes up for DBA names.
>
> I've had credit card statements that listed the DBA names which had absolutely
> no relationship to the name of the store I had been to ... which i eventually
> had to call both the credit card company/bank and the store to figure out what
> was going on.
This is not a comment on the crapness of PKI, it is a comment on the
crapness of Verisign. The two are far from synonymous.
Don't get me wrong - I don't think PKI is a perfect solution by any
means - however, it gets us nowhere to attribute the faults of others to
PKI.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
