Encouraging email security.
tk
tony.kwok@3web.net
Mon May 19 02:58:02 2003
>>No control of public key exchange and authentication.
>>Public keys are simply computer files, passed around as one
>>would pass around (for instance) his digital photos.
>
>
> I agree. We also need to find an easy way to pass the keys around.
> That's why I advocate the keyID-based method. Pass around key
> IDs and have the MUA download the keys from a server.
>
No download.
I assume that the computer is not connected to the 'net (while
the mail is composed, crypted, or read). It might only be conected
to upload and download the mail, but not even that is to be assumed
let alone required. Note that I assume no integration with the
mail client - the text is transfered via files (and clipboard?).
(Of course, nothing prevents the mail client programmer to
offer some level of integration - but the crypto program makes
no such assumption and can be used without it.
>
>
>>Medium (instead of computer) resident, no installation,
>>mobile-use-friendly.
>
>
> I'm not sure I understand this one.
>
The program requires no "installation". (there were many discussions
on this list about the "mobile use" of GPG). The program can be
executed from floppy, CD, USB drive... A large percentage of problems
that users experience are caused by unresolved or ill-resolved
components residing (or assumed to be residing) on the computer.
I assume single-executable, single-file program; thus nothing
to "install", nothing that can be wrong with installation,
nothing to prevent the user from using it on any number of
computers interchangibly (on "work" computer during the day,
"home" computer at night...). The design simply assumes that
both the program and the key files may reside on removable
media, with no state-preserving items between invocations of
the program.
>
> I would add signing/authentication, but since it happens automatically
> there is no "sign" or "authenticate" function. No added complication.
I believe that anything that imposes formatting rules and assumption
on the message text is a significant complication and source of errors.
(see many line-wrapping related snafu's reported on this mail-list).
And as stated previously, I see signing of only marginal value, to a
very small number of users. Such users should turn to GPG and full
public key infrastructure it offers.
> We can simplify (2) by simply making the MUA display the Key ID
> somewhere on the UI automatically.
Key-id is the name of the key file; there are no other "identifiers".
If a certain community wants to introduce key file naming conventions,
it is free to do so. But there is no global id name-space control.
(Remenber CB handles..? see the hypothetical sig below). Again, those
that need better should turn to GPG. What I propose here pretty
well defines the extreme low end of the simplicity scale.
tony abalony
GPGsimple: http://rumba.ohnemuhe.net/gpgsimple/tonyabalony.pubkey
key fingerprint: b7.02.de.8f.04.38.42.7c