we've had some of this discussion related to X9.59, namely that SSL verifies
that the URL used and the certificate DNS info somewhat correspond. one problem
is that many people don't necessarily arrive at a web site by actually typing
the URL ... so provided URLs are one method of attack. The other is that
certificate DNS information is typically verified by the certification authority
contacting the DNS authority. Issues with DNS hijacking (i do dns hijack of
xyz.com and then apply for certificate for xyz.com) and other exploits can be
addressed with DNS public-key (aka reliable DNS infrastructure) which could make
SSL certificates superfulous and redundant (i.e. one explaination is that SSL
certificates exist because DNS is unreliable ... but since the certification is
dependent on reliable DNS ... and a reliable DNS can be achieved with addition
of public keys to the DNS information ... then it becames possible ot obtain
public keys directly from the reliable DNS authority at the same time the other
DNS information is obtained).
the other part, is X9.59 requires that electronic payments transactions are
electronically signed .... so only a specific payment might be subverted
(supplying the wrong "pay-to" value) ... but additional payments could not be
done with the information. Note however, the wrong "pay-to" value still needs
to be a valid merchant identifiier in the payment infrastructure.
The issue then becomes that the URL was supplied to the browser by a trusted
method & a reliable DNS is available with some sort of public key authentication
(whether with public key directly from reliable DNS .... or circuitous route via
a certificate which came from a certification authority which verified with a
reliable DNS).
misc. URLs:
http://www.garlic.com/~lynn/aepay4.htm
http://www.garlic.com/~lynn/
there are still some misc.; issues where the wrong "pay-to" field is supplied
for a signed payment transaction (say a hacked web site).
pieces for this opportunity include are at the international/iso level for a
global merchant identifier (effectively a "pay-to" value). A trade-group could
be setup that provided a merchant-id/publickey binding.
Even simpler yet, since a reliable DNS is already a requirement, it would be
possible to register both a public key (to address issues like DNS hijacking)
and a merchant-id. The DNS information, merchant public key, and optional
merchant-id (i.e. "pay-to" in a payment transaction) could then be provided as
part of a standard DNS operation (further illustrating certificates as being
superfulous and redundant in AADS-like public key environments).
There are still some open issues regarding trusted path for supplying URL
information and trusted browsers. Obviously trusted browswer can include things
like does the transaction the user "sees" being the same as the transaction the
user authorizes/signs .... but then even simple aspects of existing SSL are also
dependent on trusted browser (i.e. the browser actually checks for valid
binding, sets up a private SSL session, etc).
To be fair, the sort of attack I described could work against SSL too.
Certificates can confirm that www.example.com is who you are
contacting, but certificates can't stop them from making their web site
look just like www.example.net's and duping people into giving payment
information to the wrong people. I think it would work especially well
against a videoconferencing system though, because there is a certain
trust inherent in face-to-face communications.
