[Classpath-inetlib] imap and ssl, again

[Ruben Malchow]

hello,

i've read the thread from the last days. and i really have to agree with 
daniel. imap-over-ssl is basically nothing but a tunnel (i could run a 
ssh tunnel and would be effectively the same thing) and changes nothing 
whatsoever in the protocol - apart from maybe the fact that you might be 
less concerned about the security of the authentication mechanism, 
because of the transport layer being encrypted, and possibly trusted 
client- and server certificates might be required, this is a 
configuration- and not a basic design issue.

however, i could live with that, although it limits interoperability and 
would really appreciate the possibility to do everything from the first 
HELO to the last QUIT encrypted.

i cannot live with these lines from the inetlib 1.0 source, however:

// We don't require strong validation of the server certificate
TrustManager[] trust = new TrustManager[1];

if we didn't need it, we wouldnt use it. but apparently chris has fixed 
this in the cvs (didnt check out yet). the gnumail providers now honour 
the mail.trustmanager property. i would suggest the default trustmanager 
(if the property is not set) should be most resrictive.

now, the next problem arises, and it might be one that might be a little 
off-topic here, because it actually is in parts a gnu mail thing:

i have different users on the same app, each with their own keystore 
.... it's supposed to become a webmail app when it's ready, and there 
are potentially multiple instances of this (web)app in the same vm (i've 
given up using singletons all over the place years ago), so knowing the 
username and the classname of the trustmanager doesn't get the job done. 
i need to know more: i need to give the trustmanager information not 
only on what trustmanager to use, but for what user on what instance of 
the webmail app. basically, the webmail session is the only place where 
i know the right parameters for the keystore.

of course, this is a very specific problem, but not an uncommon one from 
what i googled.

so. my last approach was to use the properties mail.keystore (a path to 
a keystore) and mail.keystorePassword (the corresponding, and optional 
password to use) to instatiate a keystore and a trustmanager using this 
keystore. chris convinced me it's much better to go for the trustmanager 
directly, because it can provide a lot of other things you might want to 
use in this context (such as collecting untrusted certificates you want 
to present to the user later to let him do the decision). but: it still 
needs to know what keys to use and where to get them from.

the current property is mail.trustmanager which is set to a classname 
implementing a trustmanager. in this naming scheme, we might want to use 
mail.trustmanager.XXX properties, or does anyone else have an idea for a 
different approach to solving this problem?

and (sorry to bring that up again): wouldnt it be nice to have a 
constructor for FOOConnection that takes an optional SSLContext 
parameter? yes, this would be a first step towards giving all 
connections the ability to tunnel themselves over ssl.


thanks for reading

.rm