Raph,
I agree with your characterization of the sort of "automated"
public key acquisition (local cache building) feature that is important to
make secure email systems workable. When BBN first demonstrated the
Message Security Protocol (MSP) in 1990, we had just this sort of facility
in place. (MSP was developed for use in the Defense Message System and is
now the cornerstone for email security in that emerging environment, which
includes "shrink wrap" support for MSP by Microsoft and Lotus.) When
email arrived with a certificate that was new to this user, a window popped
up displaying the relevent certification path info and the user was
prompted to add the cert to his cache. The window displayed the
(purported) email source address and allowed the user to have that address,
and/or an optional alias, used for lookups on future outgoing mail. With
the advent of X.509 v3 certificates, one can image a more complex window to
express some of the other cert constraints, but one would probably prefer
good management tools to allow apporpriate defaults to be established, to
minimize per-cert user intervention.
However, I must point out that these features are not one of the
secure email protocol, but rather of an implementation. I don't think that
any of the protocols being discussed here specify the sort of user
interface features we are discussing. It is reasonable to evaluate secure
email protocols on two levels: what the protocol provides and what are the
features and limitations of extant implementations. It is useful, though,
not to confuse these two aspects since better implementations may be
waiting in the wings, whereas protocol design deficiencies require more
substantial efforts to fix and then to deploy the fixed version.
Steve