Re: SMTP/TLS (RFC 2487) server authentication question

[tkuiper@xxxxxxxxx]

Hello,

> > Things would be easier, if I could explicitely _request_ a server
> > certificate by sending a "STARTTLS first.domain" and then the server
> > could send me an appropriate cert taken from the list, but this same
> > problem also applies to virtual hosting of TLS-enabled http
> > services...
>
> Excellent point.  I believe that the method defined in
> draft-ietf-tls-http-upgrade-05.txt specifically provides this
> functionality (for HTTP 1.1), via the Host: header.  But it seems to me
> that all the other foo-over-TLS specs (SMTP, IMAP/POP/ACAP, LDAP) are
> deficient in not providing this.  Ironically if it were there this would
> be a real operational win for the STARTTLS approach vs the separate port
> approach which has no opportunity for the client to express anything
> before the SSL/TLS handshake starts.

> So:  I submit that all these specs should be changed to add an optional
> parameter to the STARTTLS command in which the client would put the name
> of the service that it is intending to contact; to be used by the server
> (optionally) to select a cert to be supplied to the client.  It may still
> be possible to fix the LDAP doc.

I fully agree to this, it's even backword compatible. The smtp implementations
who support TLS I know of (postfix, qmail, and ours) send back
"501 Syntax error (no parameters allowed)", so detecting the "version" would
be easy in an implementation. At least with SMTP, IMAP and POP3
(first send "STARTTLS domain" if it doesn't work try "STARTTLS").

I don't know how LDAP could handle this. How do other servers react if you
send them STARTTLS with parameters?

Gruss/Regards,
Thomas


Thomas Kuiper        |   tkuiper@xxxxxxxxx   |  www.tobit.com     __
Core Development     |   TK3680-RIPE         |                   /__/\
Tobit Software GmbH  |   ICQ #8345483        |  ask your server. \__\/