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

Hi,

I did examine some other drafts in the mean time and looked around several
mailing list archives.

On Fri, Jan 28, 2000 at 09:23:02AM -0800, RL 'Bob' Morgan wrote:
...
> 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.
After looking around a bit, this might be a very longish approach. I have
not seen any other discussion proposal in this regard, so I doubt that we
can get this feature.

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

I think comparing our problem with that of HTTP/TLS is appropriate, since we
have to face "mass hosting" with one host serving many domains.
Let's check into draft-ietf-tls-http-upgrade-05.txt. There they allow
one argument for selecting the virtual host. Their problem is however easier,
since the expected answer is for one _specific_host_, not for a _domain_
as is often the case for emails.
Therefore we might have a problem with authentication, since e.g. for HTTPS
(draft-ietf-tls-https-04.txt) the bevaviour should be:
   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. ...
   If more than one identity of a given type is present in the certifi-
   cate (e.g. more than one dNSName name, a match in any one of the set
   is considered acceptable.) ... [wildcards are possible]
So should we use dNSNames to match recipient _domains_, too??? We might run
into trouble when continuing when following draft-ietf-tls-https-04.txt and
thinking of the MTA->MTA case (interactive clients can always ask the user)
and non-matching certificates:
   ... Automated
   clients MUST log the error to an appropriate audit log (if available)
   and SHOULD terminate the connection (with a bad certificate error).
   Automated clients MAY provide a configuration setting that disables
   this check, but MUST provide a setting which enables it.
So the standard case for a client MTA having trouble with the server MTA's
certificate would be to _not_ continue the delivery...

I have also checked into RFC2459 (Internet X.509 Public Key Infrastructure;
Certificate and CRL Profile) and RFC2247 (Using Domains in LDAP/X.500
Distinguished Names), but it didn't give me a good hint on how to continue.

Coming back from the dNSName problem..
In any case I did not find a note on how the server should react if it
cannot offer a certificate suitable to the host-name requested, so I assume
it might just send back "some certificate" and then the client must decide
what to do, as you already preferred.

Best regards,
	Lutz
-- 
Lutz Jaenicke                             [email protected]
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153