specifically with respect to SSL server certificates ... their primary objective
was supposedly to overcome shortcomings in the domain name infrastructure
integrity (and as stated, most of the SSL server certificate issuing entities
actually also have dependencies on that integrity). Fixes for the integrity of
the domain name infrastructure ... eliminates the domain name infrastructure as
a business case/justification for the existance of those certificates.
Specifically with respect to SSL server certificate, the remaining issue is
possibly merchant/server trust (not trust with respect to internet operational
integrity ... but fusiness/fraud trust with respect to the business operation of
the merchant/server). Establishing that trust goes beyond just having the
comfort that if you are defrauded that you might be able to identify the guilty
party. That can be addressed with an online BBB &/or consumer report type of
service providing real-time information.
Eliminating both justifications for SSL server certificates ... then makes the
vast majority of the existing SSL server certificates redundant and superfulous
(and I believe would severely impact the business case justification for setting
up an operation to provide such a service).
Now this is applicable to the current existing dominant PKI deployment in the
world today (possibly accounting for 99.999999999% of instances where there is a
certificate transmitted and a client checks the contents of that certificate).
It possibly is not applicable to any other hypothetical PKI implementation which
may or may not currently exist.
Ben Laurie <[EMAIL PROTECTED]> on 11/19/2000 05:03:20 AM
To: Lynn Wheeler/CA/FDMS/FDC@FDC
cc: Bram Cohen <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Public Key Infrastructure: An Artifact...
[EMAIL PROTECTED] 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
