By my read, Jonathan isn't referring to the client to server interaction
here; he's referring to the two proxy servers in the SIP trapezoid model:
SIP Proxy A <--TLS--> SIP Proxy B
/ \
/ \
Client A Client B
In this model, clients talk to their home server (analogous to a
submission server), which would use its certificate to authenticate
itself to the destination server. Depending on trust and deployment
scenarios, Client A may also use TLS to communicate with SIP Proxy A,
but it's an independent decision, so the client-server mismatch isn't
really an issue. Of course, SIP also has provisions for encrypting of
its message bodies (using S/MIME) for end-to-end security.
This all works for SIP, because, among other things, it does not have
the problem of transparent forwarders, of greeting card companies, or
the legacy of years of deployed systems, so its approach to the problem
can be a little cleaner.
-Edwin
Tony Finch wrote:
On Thu, 15 Jul 2004, Dave Crocker wrote:
no said that public-key based client authentication was not possible.
they said that it has not established any significant track record of use.
There are also significant interoperability problems if the server asks
the client for a certificate and the client doesn't have one.
Tony.