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
