Tony Finch wrote:
The point of the certificate is to authenticate the name that the user
typed in. If you don't authenticate the right thing then you will fail to
detect attacks, for example, if an attack on the DNS produces a bogus name
-> IP addres translation and the attacker has a valid certificate for
that IP address.
I don't know why some certificate bear the IP _instead_ of the FQDN;
could do both.
The same problem applies to the MX mail domain -> hostname mapping, where
TLS is insecure because authenticates the target not the source.
Do you mean the server requiring the client to STARTTLS?
If not, I think most server software can easily be modified so as to
accept client certificates, if it doesn't accept them already. They
are usually not _required_ to avoid handshake failures (e.g. the MDA
software in turn asking the users which certificate they want to upload.)
Alternatively, after some sort of forwarding agreement has been
established between two servers, in a TLS session it is possible to
use rfc 4954 to say something like
MAIL FROM:<original-envelope(_at_)example> AUTH=distinguished-relay
The distinguished name of the relay should help the spam filter in
either case. After authentication, it makes little difference if it
comes from the certificate or from a command parameter.