Michael Ströder wrote:
Anders Rundgren wrote:
Ian G wrote:
=> Encrypting/signing must be made a business requirement in contracts.
That's the whole point. And there's no technical solution for it.
That's as close to a perfect dilemma as I've come across! It's not a
business requirement, so we must make it a business requirement ...
Another alternative is to
Anders, still you fail to see the real problems since you propose
technical solutions for non-technical issues.
But let's see:
1. abandon non-scalable trust infrastructures such as the one
required by S/MIME
Why "non-scalable"? Can you be more verbose?
I don't know what Anders thinks, but I see these reasons as to why
S/MIME is non-scaleable:
* 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.) 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...
* 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.
C.f., that recent thread with Nelson, where he reads everything before
signing.
* 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.
* 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.
That's off the top of my head. There are others on my blog, likely.
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?
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.
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 :)
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.
(Mind you, let's not get too hung up on this, as "trust" is not defined
yet!)
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
