Brad,
You sent a message proposing that an MTA could fetch the
requisite certificates for a user without continuous connectivity,
as a side effect of delivering email. I don't think that solution
is in keeping with the PEM design principles. We have tried to
make PEM not require any modifications to the message routing
infrastructure. Your proposal would require such modification.
The other suggestion, that this specially modified MTA should
fetch the requisite certificates for outbound email, and perform
the encryption for the user, also is not in keeping with the
spirit of performing the encryption at the user's desktop. PEM
requires that you know the DN of each recipient for an encrypted
message, because the DN is what is authenticated by the
certificate. A user without access to a recipient's certificate
may have no way of knowing the recipient's DN and has no way to
express that DN as part of the (partially PEM processed) message
header. The originator also cannot view the name of the PCA under
whose policy the recipient's certificate was issued, and thus
cannot make a value judgment about the trustworthiness of the
binding. These are among the reasons that PEM calls for the
encryption (as well as signing) to take place "near" the user.
With respect to DNS-DN mappings, although one can map DNS names to
a syntactic DN format, this does not yield the sort of descriptive
"real" DNs called for in PEM. The DNs used with PEM really should
be suitable for registration in an X.500 DSA not as a special
Internet hack.
Steve