Graham Leggett wrote:
>
> This won't work.
>
> In order for me to send you mail that other people cannot read, I need
> your public key. Whether that key is embedded in an S/MIME certificate
> or a PGP key is irrelevent, I need something from you first that I can
> verify is yours before I can encrypt mail to you. Without that key you
> cannot encrypt.
Yes, but it's trivial to send a message to somebody containing your
public key, after which they can send you mail. The problem comes in the
fact that with existing S/MIME implementations, you don't just need a
public key but also a certification from a "trusted" third party
("trusted" by your mail program vendor, not by you). I'd like to be able
to get an email from somebody with their public key, verify to MY
satisfaction that it's genuine (for most purposes that I'm concerned
with, sending them an email back saying "did you really send me this
mail?" and including the key fingerprint for them to check would be
plenty; in other circumstances I might be able to call them) rather than
relying on some third party that I don't actually trust at all.
> SSH doesn't work this way - it too uses a public private key, which is
> typically generated once when the connection is first established
> between two machines. From a risk perspective there is only a risk on
> the first connection, but then the user was expecting a key exchange so
> the risk is minimal.
Given my clarification above, do you still disagree that this is how SSH
works? (Your description matches my understanding of ssh, but it also
matches how I intended to propose that S/MIME could work).
Stuart.
