What plans are there for providing security services within MH?
('Scuse me if this topic's already been talked to death here -
I've not been a regular reader - but I raised the question in
another forum, and Bill Wohler encouraged me to bring it here,
if I understood him right. If the _keeper_ of the FAQ thinks it
needs discussion, who am I to disagree? But I will be watching
comp.mail.mh for answers, now that I've asked a question there ;-)
Formats for enclosing secured materials (signed and/or
encrypted) within email are approaching standardization in MIME,
shifting the burden to mail handling systems to actually
implement something. There are, of course, important issues and
questions that the MIME standard can't and shouldn't address,
and therefore that the core mail handling system can't pass off
onto the MIME interface. For some time, I've been maintaining
pgp.el, a PGP-specific extension to the GNU Emacs mailers (mh-e,
which is in turn layered upon MH proper; and rmail), which has
given me some exposure to the questions.
I'd like to explore future security services within MH, both as
a user and as a maintainer of an associated security component.
Here are some pump-priming details.
I think the overall structure of this service is generally
clear, but there some surprises lurk therein as well. Only the
surprises are any fun, so I'll just lay out a few of them, but
if anyone sees core service details worth discussion, feel free
to raise them as well.
Disambiguation and canonicalization: Generally speaking,
cryptosystems are prepared to use familiar identity tags like
names and email addresses. But these are not always unique or
unambiguous, and indeed their clarity can change from time to
time (as new keys are added to a keyring, for example).
Cryptosystems generally have a guaranteed unique handle on the
identity, and allied services like mailers are most successful
if they use the unique handle rather than the possibly-ambiguous
familiar tag. But this requires a canonicalization dialog
between
mail and crypto system (whic
h in general will include
user interaction as well), and obligates the mail system to
store the canonical handle in association with the familiar one,
perhaps in the personal aliases database.
Many-to-many identities: Even after canonicalization, identities
and keys are not always mapped one-to-one. The same person may
have several mail addresses, all of which should be mapped onto
the same, single key; a mail address may actually be a remotely
expanded mail list, mapped onto a list of keys; a group of
people may sometimes share a single key for some joint purpose,
so that any one or subset of them should be mapped onto the same
key; and individuals may maintain several keys for different
purposes.
User interaction: normal crypto operations sometimes require
user interaction, triggered by the operation, and not
predictable by a mailer service. Encryption to an ambiguous
identity tag may require the user to choose which actual key
should be used; signature checking may produce more information
and a richer result set than merely "pass/fail"; encryption
requested to a list may be possible only to a subset of the
list, requiring a decision whether to send, split, or abort. In
any of these cases, the crypto system discovers the need for
user interaction, but may not know the appropriate communication
mode: terminal I/O, terminal forms, dialog boxes. In a rich
environment, the right mode may not be discernable even by
gestalt approaches. The mail system knows better here than the
crypto system, but means of communicating this, or protocol for
the crypto system to ask the mailer to do the I/O, are among the
least standard things.
And there are occasional important security issues here as well.
For example, by far the most common type of unpredictable user
interaction is password or passphrase entry. Passwords/phrases
are in fact the most sensitive material a cryptosystem handles,
since they are effectively equivalent to all the information
ever protected by the system. From that perspective, it would
be far better if the mailer never touched them at all, never had
to worry about secure prompt/respose systems, caching, proper
disposal, and so forth. But that further complicates the issues
in the previous paragraph: how does the mailer inform the
cryptosystem of the appropriate I/O channel?
Storage considerations: Messages that arrive encrypted may very
well be sensitive - that's sort of the point, after all. A
mailer should not assume that, having decrypted them (or had
them decrypted by the cryptosystem), they can be stored away in
the clear. But decryption is expensive, and security is
complex: a user may need to store in clear, depending on
whole-system security once the traffic has arrived. This does
not seem to be a choice the mailer can make; rather, it must be
an option the mailer provides. And there are the intermediate
copies - temp files, memory copies, even I/O buffers in the
kernel - all of which can constitute undesirable exposure of
sensitive material.
Crypto-system neutrality: There is no One True Cryptosystem, and
probably won't be. There's also the problem that cryptosystems
are export controlled. Standards in this area are seriously
lagging standards in message formats. The net of these is that
a mail hander needs (ideally) to be adaptable to whatever
cryptosystem the user may have installed. While the fundamental
issues that distinguish cryptosystems are the business of the
cryptosystem, not the mailer, there are secondary factors that
very much concern the mailer. There are picayune details like
the API (as picayune as "what's the name of the library routine
I call?"). There are deeper issues like the authentication model
(which, for example, can expect the mailer to spontaneously
exchange email with a keyserver when a new key is needed).