On Thu, Mar 26, 2009 at 4:46 PM, Ian G <i...@iang.org> wrote: > On 25/3/09 01:06, Eddy Nigg wrote: >> >> On 03/25/2009 12:35 AM, Kyle Hamilton: > >> I don't understand how this is connected to the initial idea of finding >> some better ways to use client certificates for mail (was actually >> client certificate authentication IIRC). I think I lost you here... > > > The original idea was how to improve Thunderbird's existing abilities to > work with crypto and deliver security. If you read my proposal carefully > you will see I very carefully separated the crypto/secure email part from > the certificates part.
The overall idea I proposed was not really designed to prevent SSCs, it was designed to give users the ability to easily opt into the CA strategy at class 1 (email address receipt ability verification). Looking back on it, I see that I didn't make that as clear as I otherwise could have. > Which is to say, the original proposal was to improve email security. It was > not to improve the use of client certificates. The latter is both foolish > as an objective, and is also a limiting drain on security for email for > users, especially for Thunderbird's typical users, if taken as the only > objective. Having someone who represents a CA in the discussion will almost certainly entail discussion and promotion of products that the CA offers. > Having said that, because certificate providers and sellers of certificate > software *dominate this forum and Mozilla security thought* the proposal was > written to improve both security for the typical end-users of Mozilla, and > the use of certificates. Note these are two different things, so it has to > dance a careful path. In very brief summary: > > 1. accounts make key pairs and share public keys for encrypting of email. > > (Implementation detail: probably as self-signed certs because that's what > the code does.) > > 2. Once a substantial body of email is protected by the easy method of 1. > above, it makes sense to offer the upgrade path for users to allow them to > convert their public keys (SSCs) into CA-signed certificates. > > This will appeal to corps & govts but not to individual users. Corps and > govts will pay for this. Individuals will not. CAs can easily do Class 1 for free -- at least I know of at least two that do, even if the hoops to actually get them to do it are MUCH more difficult than I think they should be. > However, here's the link: Individuals will do part 1. Corps and govts will > follow Individuals. Corps and govts won't do part 2 without part 1. > > It's called marketing strategy :) There's another thing, though, that privacy advocates would be quick to point out: sharing self-signed certificates also shows exactly who you're communicating with. (Granted, with current client certificate (lack of) lookup support, this is also the case, since you have to keep the certificate that contains the public key you want to encrypt to for any given Subject.) Gee, we're just finding all the flaws in the PKI implementations here, aren't we? Let's see if I can enumerate them... 1) lack of customer value-perception in PKI 2) lack of customer cost-benefit perception in PKI 3) lack of by-default protocol security 4) lack of key/certificate lookup facility 5) lack of sanitary multi-CA handling 6) lack of community off-label CA support (ties into 5) >> I have no problem with any of them as long as their usage and trust >> remains limited with their domain and internal activities. > > This happens to be the case with all CAs (more or less, ref: RPA and the > concept of the relying party) and with all communities. Thank you for pointing that out -- end-users are not considered "relying parties" without reading the CPSes, but they don't bother because the lock is there and possibly the green bar is there too. >> No, I don't want that. But that's for web sites anyway, not connected to >> mail I think... > > Right! Email is p2p already, naturally. Web is more or less > client-to-server, and there is a case for 3rd party authentication. Mailing lists are a special case, and while web is more or less client to server, *there is no case for 3rd party authentication if money isn't changing hands*. Think about it: how many web forums exist which don't have any 3rd party identity verification at all, yet have managed to attract enough individual users to stimulate lively conversation and debate? These fora exist whether they're authenticated or not. They also happen to be the masters of their own authentication realms (borrowing the term from Kerberos). I've seen enough no-profit-motive communities that need some kind of SSO (oekaki boards running on machines other than the main forum sites, web boards that authenticate against MUD player databases, etc) that the dominant paradigm cannot support them. These communities would benefit greatly from the addition of client and server certificates so that multiple machines don't need proxy tricks played with in the path to prevent multiple authentication prompts. (such schemes are wasteful of internal network bandwidth, processing power, CPU, and administration know-how. The KISS principle applies.) Except that there's no way to describe which machines in a domain are intended to be part of the single-sign-on process, so every machine that you go to will ask for the certificate to use. *sighs* nice dream, anyway. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
