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. [EMAIL PROTECTED] (use pgp keyid 0x3AD5C11D) http://www.pdscc.com (604) 739-3709 (voice/fax) (604) 686-2253 (pager)
