I wish I could wave my hands and say "it's a non-issue" like you. Unfortunately, I'm the one who has to try to explain how to use these things. Unfortunately, I'm the one who has to deal with the tech support calls. When I can't figure it out (and I've been trying for over a decade), how the fuck are non-experts supposed to figure it out?
I'm rather annoyed at people who seem to think that the problems that our world has are just going to magically not be problems. They are, and they will continue to do so, and thus far all attempts to change the situations from whence the problems arise have failed spectacularly. Fact: it's not just businesses who have need for S/MIME. (It's not just private individuals who have need for S/MIME, either, but I'll blast the businesses later.) Fact: Home users don't want to pay upkeep for their machines. Fact: Over half of all computers (meaning, machines that users use with a keyboard, monitor, mouse, or other I/O devices) don't have backups. Fact: people lose critical data all the time. Fact: Even those who do try to maintain backups and such have to deal with failing hardware. Fact: Those who do suffer failing hardware quite often have unusable backups when they are finally restored. And another Fact: Those who understand are willing to move mountains and work their way past insurmountable mountain ranges to get something to work. A corollary to this fact is that those who are willing to do that have a rather huge emotional investment in making sure that it works for them -- and thus have huge blind spots: they're willing to ignore those who say that it won't work for the masses, and they're willing to say "it works for me, you must be doing it wrong" to those who can't get it to work. Directories don't solve telephone issues. Directories don't solve email issues. Directories don't even solve IM issues. And that's just to get the most basic, most rudimentary form of contact going. Much less being able to exchange the keys necessary for secure conversation. Directories are, after all, just another form of data binding. Certificates are simply means of showing that the provider of that data actually bound that data. (Note that I didn't say 'proving'. That's a semantic can of worms that I'm not willing to open just yet.) Realistically, if you can send email to a mailbox at a domain that is read by somebody, then at the least the following must have happened: 1) the domain registrant had to talk to a domain registrar. 2) the domain registrar had to talk to the domain master. 3) the domain master had to add the domain to the DNS. 4) the DNS must have either an MX or an IP that will accept SMTP connections. 5) the SMTP receiver must accept the message. 6) the SMTP receiver must find the mailbox to put it into. 7) the mail must be put into the mailbox. 8) the recipient must be able to read the mailbox. 9) the mailbox's address must be distributed to whoever wants to send to it. And all 9 steps must be followed for the person who sent it, if that person wants to receive it. And this is even beyond the problem of getting connected to the network in a way that you can even run an SMTP server that can be reached. Each of these problems is surmountable. We've had over 30 years to figure out how to get network access, over 30 years to figure out how to get DNS running, over 30 years to figure out how to transfer mail. All of these are successful because even if it does take understanding, it's only the cognocenti -- those who know and care to know, who can get it figured out. That's why we're hired by businesses. The masses only deal with email clients, and bitch when they don't work. We need something that's as transparent to the end-user as possible, if we're going to get cryptographic authentication and transformation working. This is why Cerulean Studios introduced SecureIM, even if it fails at anything resembling end-to-end authentication (and for a fairly good reason: honestly, if someone's using an IM service, it's up to that service to ensure that identities are limited to those who have the passwords for them, so it shouldn't matter if there's an extrinsic authority butting into a private conversation trying to "prove" everyone's identity to a level far beyond what would be desired or useful for anyone). The problem that I have with certifying authorities isn't what they do as far as cryptographically signing things. The problem that I have with them is that they spread fear, uncertainty, and doubt about any communication (not simply transaction, but any COMMUNICATION) that isn't authenticated by something that they issue. The problem that I have with Mozilla is that it's allowed itself to swallow that entire concept, hook line and sinker, without doing effective and appropriate risk assessment with appropriate threat models. Because of this, it has failed to accept certain things: 1) not everything needs a vetted CA, and 2) even if it thinks that it does, the public is going to ignore any demand/requirement that is extrinsic and useless to the purposes they have in mind. This means that Mozilla is operating blind to what its public users need, for the sake of stroking a few egos. -Kyle H On Thu, Nov 27, 2008 at 5:51 AM, Michael Ströder <[EMAIL PROTECTED]>wrote: > Just to clarify: I also see a lot of practical problems to be solved when > encrypting/signing e-mails. And I supported real end-users doing so. But > these are not caused by S/MIME (or PGP) standards itself. > > Ian G wrote: > >> * it has no open + effective key distribution mechanism. (I exclude the >> LDAP stuff as that is generally for internal / corporates, and is not a >> general solution for the users.) >> > > Just exchanging signed S/MIME e-mails is quite easy for most users. The > case that e-mail receivers are completely unknown is fairly seldom. This is > a non-issue. > > E.g., after changing laptops recently, I still cannot s/mime to half >> my counterparties because I don't have their certs. This happens >> regularly with everyone I know... >> > > ??? > > I've changed my notebook harddisk quite often. I never lost my Seamonkey > cert DB containing the key history of the last 10 years since it's part of > the Mozilla profile which I have backups of. When people in companies get > new PCs there's backup concept to migrate their old data. If not the user > has more problems than just the e-mail certs of others. > If you create a new profile in your MUA then you have to import the certs > therein. But does that happen very often? > > This is a non-issue. > > * it needs a few tweaks in UI to align it with the safe usage models, so, >> for example the "signing" icon has to go because it cannot be used for >> signing, because signing is needed for key distribution. It also cannot be >> used for signing unless reference is made to the conditions of signing, and >> no UI vendor has ever wanted to give time&space to a CPS. >> > > Maybe it's me but frankly I don't understand what you say here. Especially > I don't see the need for a "UI vendor" to define a CPS (if Certificate > Practice Statement is meant here). > > No doubt the UI could be better in some S/MIME-enabled MUAs. > > > C.f., that recent thread with Nelson, where he reads everything before > > signing. > > The thread about form signing? There was a basic question whether it's > feasible at all and I commented on that. > > * it needs a click-to-launch method of key-creation, sort of like that >> which Anders was demoing with Firefox. Or preferably, it should be launched >> by default. "There is only one mode, and it is secure." But that will >> likely clash with the next point. >> > > Are you talking about the PGP model of peer trust? (Each end-user defining > individual trust for each participant's public key). > > * the security architecture is referred to some IETF committee. This >> means it is incapable of modifying its security model to deal with evolving >> threats. Anything with its security leadership split across too many >> components eventually falls into stasis. >> > > I don't understand this. > > 2. abandon schmes that use explicit encryption keys like S/MIME >>>> >>> >>> Are you aware of the requirements for separate encryption keys? Some >>> companies have the legal requirements for key escrow in litigation cases. >>> That's the main reason why encryption and signature keys are separated. >>> >> >> What happens when we add complexity to an already broken system? >> > > I fail to see why it's broken. So I can't answer. And I fail to see why the > other schemes proposed are less broken. IMHO the opposite is true. > > 3. introduce secure mobile secure key-storage >>>> >>> >>> Ah, yeah. Did you ever think of a growing key history and such? >>> >> >> Is that the counterparty certs, which would then also disappear every time >> someone changed cellphone? Yeah, I agree. It needs a better key distro >> mechanism, like the key servers of OpenPGP. >> > > No, I meant the archived private keys for accessing old encrypted e-mails. > > 4. put the latter in cell phones >>>> >>> >>> Even cell phones can break. And I don't consider them to be trustworthy >>> key stores >>> 1. with all the control the cell phone provider has over them, >>> 2. all the gadgets installed with security issues, >>> 3. with the limited data storage size on today's SIM cards. >>> >> >> Sounds about as robust as any Internet software on any modern PC that >> bombs out once a year or so :) >> > > Yes, there are risks with software on a PC. But on a PC I have a fairly > good chance to keep more control on what I'm using. The mobile phones tend > to be customized. Configuration options are very sparse. There is no > reasonable update mechanism keeping me informed about security updates. (It > was a major PITA to update the buggy firmware on my Sony Ericsson mobile > phone. The update software needed a flash player to be installed to display > some fancy graphics. Uumpf!) > > And the main point: You fail to explain how trust is to be established. >>> >> >> Well, there is the old trick I described: do a DH key exchange and then >> use the voice to authenticate the checksum over the results. >> > > Yupp. But that's kind of an enrollment process which is what Anders would > like to avoid. > > (Mind you, let's not get too hung up on this, as "trust" is not defined >> yet!) >> > > Trust is like beauty. Beauty is in the eye of the beholder. ;-) > > > Ciao, Michael. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto >
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
