Re: Any drafts for IMAP4/TLS and/or POP3/TLS

A handful of comments ... as well as a "thank you for writing this!"

First, I'd like an explicit statement that when the TLS connection
ends, so does the IMAP4 or POP3 connection.  You don't now have a
STOPTLS command, which would be necessary to do that securely; and
I think it's fine (and desirable!) that there be no such command.


Second, fine language on the ciphers and export issues.


Third, I think some language is necessary with respect to X.509
certificate profiling.  Probably these five things would suffice:

   - A reference to the PKIX Part-1 (05) work ... overdue to
     publish, but almost "ready" last I heard.  They seem to
     have finished changing the OID to use with DSS, for one
     very significant point!!

   - A requirement that the signature on DSS certificates (by
     the CAs) MUST be DSS signatures.  (It's not sufficient
     just to have the certified keys be DSS, with the signature
     being some unspecified RSA signature variant !!)

   - A requirement that any IMAP4/POP3 server's use of TLS client
     authentication MUST support the "dss_sign" certificate type,
     which should be summarized to mean that it's a DSS key with
     a DSS signature on the key's certificate.

   - And something analagous to the way HTTPS now manages the
     binding between the host name and the certificate.  Maybe
     even the same thing:  "CN=" holds the fully qualified DNS
     name for the IMAP4/POP3/... server.  This is needed so that
     at least some level of policy checking can be automated; I
     see no particular reason to preclude using the same cert
     for HTTP, IMAP4, POP3, etc.

   - There should be a statement, pro or con, re any requirement
     for additional X.509v3 certificate attributes in support of
     a server's ability to offer IMAP4 or POP3 service.  Ideally,
     "con" -- clients MUST NOT reject a server certificate which
     is part of a currently valid certificate chain, and meets
     the above two requirements.

     But if "pro", it should describe the specific X.509v3 cert
     extension (ASN.1 and OID) which MUST be a critical extension
     enabling clients to accept this as an IMAP4 or POP3 server.
     Similarly, even if this is a non-critical extension.

One could argue that TLS or PKIX should address this fourth set
of issues, but I'd say otherwise.  All of them are cert policy
issues which affect interop for this application, but perhaps
not for others.

For example I exchanged E-Mail earlier this week with a CA vendor
on that aspect of the "pure DSS cert" issue; the CA cert they use
will be DSS, signed with their existing RSA root key.  So many
folk wouldn't be able to verify that "DSS root"; not really an
issue, but if that were also true of customer DSS certs, whoops!

Similarly, the "CN=" convention (for HTTPS) is currently documented
only on a Netscape website, and would be needed in an HTTPS profile.
It's not bad or burdensome, it's just not yet in an RFC.

What's worrisome is that I've seen a bunch of X.509 extensions that
seem to relate to HTTPS and SSL capabilities ... I shudder to think
of the interop problems if anyone starts enforcing them.  Hence my
desire to head off that disaster for mailbox protocols!


Finally, I wonder where one would want to put a conventional set
of Diffie-Hellman parameters (modulus, exponent) that "MAY" be used
by TLS servers implementing this spec.  The virtue of having such a
set which "MAY" be used is that to the extent they're widely used,
clients can precompute their private keys, producing better TLS
session setup times (one less prime search, one less modExp).
Of course the idea is not to mandaate ("MUST") such parameters.
There are both security and performance implications to the modulus
(specifically, its size) being used.

Arguably such a set of parameters should be in the TLS spec.
But, it's not there now, and not looking to be.  Perhaps it'd
be approprate as a separate informational RFC, rather than as
part of either the IETF's TLS or {IMAP4,POP3}/TLS specs.

- Dave