Re: ::scr tales from the crypto

[Alex Robinson <scr@xxxxxxxxxxxxxxxxxx>]

>No, I don't believe I have missed your point.

I regretted putting it that way the moment I sent it. I think the words "I
obviously didn't express myself clearly enough" would have been more
appropriate. Anyways your email is a case of "good points, well made"

>>>> the few scripts I mentioned before <<<<

But Matt's original question was how to get it working for John and Jane
Noclue who have neither the nous nor the inclination to get into the itty
gritty. The seamless implementation is all important here. Having the
recipient open up a message and find out s|he can't decrypt it and then
send back to the original sender obviously works but is blatantly pants for
those with no clue and who want things to just work. Or are you suggesting
some more scripts that decode the message and verify that the output is
meaningful and if that fails send back notification that the key was cack
along with a new key and an instruction to resend?

<rummage>
  OpenPGP (RFC2440)
  http://RFC.net/rfc2440.html
</rummage>

"5.2.3.17. Preferred key server

   (String)

   This is a URL of a key server that the key holder prefers be used for
updates. Note that keys with multiple user ids can have a preferred key
server for each user id. Note also that since this is a URL, the key server
can actually be a copy of the key retrieved by ftp, http, finger, etc."

Well, fine and dandy. But it's still just one protocol. All clients would
have to use it and if ever there was move to another protocol (for whatever
reasons) all those clients would have to be reengineered. Surely, it's
better to have a keyserver mechanism that is
ignorant/agnostic/$correct_word about the actual encrypting scheme. Or is
OpenPGP the one true path?

Hmm. Ok, I can now see that it really makes no odds to the client or the
user which way it happens.

The main thing is that the method of retrieval from the keyserver needs to
be an agreed upon standard. Is it? Is it? I can see lots of plugins with
relatively complicated instructions and gotchas but nothing built-in that
the user never even has to think about (except of course when generating
new keys). Surely the desired behaviour should be for the client to attempt
to send the message encrypted and only offer the user the opportunity to
not do so  if no key can be found or if the user has explicitly chosen to
override it?

As to whether the system is centralised and ahead of time or distributed
and in real time, I think the latter is preferable, but more for political
reasons than technical ones. But you call that overengineering. You are
probably right. I am just a fscking designer, not a computer scientist.

---

On a different tangent, is overengineering always bad?