On Mon, Sep 9, 2013 at 9:41 PM, Ted Lemon
<Ted(_dot_)Lemon(_at_)nominum(_dot_)com> wrote:
On Sep 9, 2013, at 9:26 PM, John R Levine <johnl(_at_)taugh(_dot_)com> wrote:
Um, didn't this start out as a discussion about how we should try to get
people using crypto, rather than demanding perfection that will never
happen?
Yes.
Typical S/MIME keys are issued by CAs that verify them by
sending you mail with a link. While it is easy to imagine ways that
could be subverted, in practice I've never seen it.
The most obvious way that it can be subverted is that the CA issues you a
key pair and gives a copy of the private key to one or more others who
would like either to be able to pretend to be you, or to intercept
communication that you have encrypted. I would argue that this is
substantially less trustworthy than a PGP key!
The CA NEVER ever gives the user the key in any of the systems I have
worked on.
VeriSign did offer a key recovery system for enterprise use with central
key generation but the keypair is generated on the enterprise side and
never passed to the CA.
Of course you can _do_ S/MIME with a non-shared key, but not for free, and
not without privacy implications. (I'm just assuming that an individual
can get an S/MIME Cert on a self-generated public key—I haven't actually
found a CA who offers that service.)
Comodo offers that exact service today.
https://secure.comodo.com/products/!SecureEmailCertificate_Signup
Now this product still has the usual problems of S/MIME and PGP in that
there is no infrastructure that allows a receiver to easily acquire the
certificate (except by bulk query on the CA LDAP server) and there is no
way to know what the sending policy should be.
The key pair is generated in the browser using the Javascript mechanism (as
far as I know, I have not checked but my understanding is that this is how
it works).
Just applied for a cert for Safari on phill(_at_)hallambaker(_dot_)com. Worked
fine.
But the process of getting the certificate into my email client is far from
simple. Apple mail certainly has the capability to do S/MIME but the
controls to enable it are buried deep.
Same issue. I can send signed mail to a buttload more people with
S/MIME than I can with PGP, because I have their keys in my MUA.
Hypothetically, one of them might be bogus. Realistically, they aren't.
Very nearly that same degree of assurance can be obtained with PGP; the
difference is that we don't have a ready system for making it happen.
I don't see the value of this argument.
We have to fix key distribution. We have to make the CA actions
transparent. That means a redesign of that whole part of the technology. If
we are looking forward to new email systems then we can combine PGP Web of
Trust with S/MIME message formats.
E.g., if my MUA grabs a copy of your key from a URL where you've published
it, and validates email from you for a while, it could develop a degree of
confidence in your key without requiring an external CA, and without that
CA having a copy of your private key. Or it could just do ssh-style
leap-of-faith authentication of the key the first time it sees it; a fake
key would be quickly detected unless your attacker controls your home MTA
or the attacked identity's home MTA.
Eliminate the CA and you eliminate the parties with the incentive to sell
the solution.
Whatever scheme is picked to complete secure email there is going to be a
problem finding end users certs and end user policies. And there may be a
market for solving that problem just like there is a market for blocking
spam.
--
Website: http://hallambaker.com/