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

["RL 'Bob' Morgan" <rlmorgan@xxxxxxxxxxxxxx>]

> > > 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.

Thinking about this some more, I think the best technical approach is to
put the change into TLS itself.  The client hello message is specifically
stated to be extensible.  This may be not be the quickest way to get it
into practice, though.

> > 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").
> 
> Sounds reasonable. RFC2487 as of now explicitely defines STARTTLS to have
> no parameters, so extending the syntax would be no problem. If no "domain"
> is given, send back a standard server certificate, otherwise send the one
> requested.
> What should be sent back in case the requested certificate is not available?
> This case would need to be defined:
> - 5xx Cannot serve required domain (no certificate available)
> - Just start the TLS negotiation and send back the standard certificate.
> I would think, that the first alternative is better, because it would allow
> the client to react flexible and ask for another "domain" if it suites the
> client.

I prefer the latter approach (regardless of whether this happens in SMTP
or in the TLS client hello); ie, treating the service-name sent by the
client as a hint rather than a must-have.  This gives the client the
option of figuring out whether to accept whatever the server sends, or to
abort the TLS negotiation and start over again with another service-name.  
In any case the field in the client message should be able to be
multi-valued.

 - RL "Bob"