On 1 Oct 2008 at 10:37, Bill Cole wrote:
> I've heard so many conflicting stories about the X509/SSL/TLS capabilities
> of different mobile platforms that I don't know what to believe.
I've got direct experience with a bunch of the platforms, so I am not all
that concerned about that problem.
> I would expect that the Windows Mobile devices could use any cert you
> can construct,
It needs a specific format, der encoded IIRC, other than that it works fine.
> and I know that *some* Palm mailers can deal with self-signed server certs
> and so could *probably* deal with client certs, but even that's an iffy
Back in my Palm days, the mail client I was using did support client certs,
but that was a LONG time ago.
> proposition because so many Palm devices are carrier-customized in bad
> ways (particularly by Verizon.)
My biz partner has a Telus Treo 700p or 750p. All my devices are unlocked
phones so that's not a problem.
> I've seen enough stupid failure when asking for client certs that I
> wouldn't try it with any platform where the vendor does not clearly
> explain how to do it.
The vendor as in the cellular telco? Bah, I pretty much ignore what they have
to say. Or do you mean the OS vendor? There's plenty of info on the net
about that and I've rarely had problems.
> Dovecot does have to trust the signing cert for the clients (i.e. it can't
> just be looking at some default bundle of commercial CA's) but that's not
> really connected to its server cert.
Yes, I thought so and that is exactly the crux of my problem, how do I get
dovecot to trust both cert chains, GoDaddy and my self signed client certs
simultaneously? I can't seem to find anything on that specific issue.
> This can't just be about education.
With the 2 other people I'll be dealing with, it's enough, I continually beat
the security drum to them, they used to say I was just too paranoid, now when
I say, events have shown I wasn't paranoid enough, they nod sagely :-) Every
now and then I have to hit them with a clue stick, but they've come a long
way.
> The vast majority of users will not tolerate having to enter a
> worthwhile password every time they want to make a mail connection
> unless it is forced on them, particularly on a device with a tiny
> keyboard.
Woah, lets make the disctinction between technically inclided people who
understand the risks and regular users. The 2 folks in question are of the
former variety. I am well aquainted with the latter variety amongst my
clients. They'd rather shoot themselves in the foot so they can have ease of
use, I am quite familiar with dealing with them
> You partners may need to be told clearly that if they cannot or will
> not enforce frequent password entry on end-users in some fashion,
> client certs are literally worthless and any effort (or money) spent to
> make them work initially or support them in the future is wasted.
At this point that's a secondary issue, I just want to get it working for MY
use, once we get our colo equipment updated, then I can implement it for
them, knowing full well that they don't view security as seriously as I do,
hence the reason I'll probably always have my own gear under my control.
> An alternative approach that might be easier to implement on some
> platforms (certainly on Palm and iPhone) would be to force the device
> to lock on
Couldn't care less about the iPhone at this point since it doesn't offer much
of the business functionality I expect, maybe in 3-6 months, who know.
> extended idle, network disconnect, or reset, requiring a password to
> unlock it. That enforces a "something you know" on the whole device,
> rather than just on mail.
Makes sense, I already do that with devices under my control as a matter of
course.
--
Harondel J. Sibble
Sibble Computer Consulting
Creating solutions for the small business and home computer user.
help at pdscc.com (use pgp keyid 0x3AD5C11D) http://www.pdscc.com
(604) 739-3709 (voice/fax) (604) 686-2253 (pager)