ietf
[Top] [All Lists]

UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)

2015-12-01 08:35:12
If I understand this draft correctly, I object.

It says:


   2.  When using email service discovery procedure specified in
       [RFC6186] the client MUST also use the right hand side of the
       email address as another "reference identifier" to compare
       against SRV-ID identifier in the server certificate.


If I understand RFC 6186 correctly, a (possibly large scale) IMAP email
service provider that wishes to serve a new domain "example org"
according to RFC 6186 must do two things:

- Update internal tables of its servers with inforamation about that domain.
- Populate the DNS of the domain served with an _imap record.

If I understand this draft correctly, the server will have to do one
more thing:

- Change its certificate to include a complete list of all the domains
it is serving, and have its CA sign off on that certificate.

The reason it cannot provide one certificate per served domain is that
neither this specification nor any other specification I have found says
that the client MUST include any distinguishing information (such as a
Server Name Indication) that says what name it is expecting the server
to provide service for.

Given the popularity of multi-domain mail servers (my own tiny little
mail servers has 9 domains it calls its own, some of which I do not wish
to advertise), I see this as a problem.

If I have misunderstood the issue, I apologize.

Harald Alvestrand


Den 20. nov. 2015 15:29, skrev The IESG:

The IESG has received a request from the Using TLS in Applications WG
(uta) to consider the following document:
- 'Updated TLS Server Identity Check Procedure for Email Related
   Protocols'
  <draft-ietf-uta-email-tls-certs-05.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2015-12-04. Exceptionally, comments 
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document describes TLS server identity verification procedure
   for SMTP Submission, IMAP, POP and ManageSieve clients.  It replaces
   Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates
   Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-uta-email-tls-certs/ballot/


No IPR declarations have been submitted directly on this I-D.