Conversely, if you want bob(_at_)example(_dot_)com's public key, the best way
to get it is to go straight to the horse's mouth and ask
bob(_at_)example(_dot_)com,
or in this case a proxy, his MUA.
If MUA means mail-client this introduces a noticeable latency as well as
only working when the MUA is on-line. This alone makes this proposal
a rather handicapped scheme IMO.
It seems that interrogating a Web Service associated with the target
domain (like __mail_encryption.example.com) would be fairly simple to
get going and facilitates immediate responses. If the acquired certificate
is issued by a known party and conforms with the mail-address, it seems
that you can automate this. Using a TLS connection to the service you
might even accept any e-mail certificate issuer by "reusing" the trust in the
server certificate. For encryption purposes this should be satisfactory.
Using the most current key is also a factor that were missing in Ian's
proposal.
A security implication with using DNS + a WebService is that a bad
provider could replace your encryption key with something that would
allow it to read incoming messages in clear. OTOH, that is what they
already do today 99.9% of the time. In fact, this scheme allows an
enterprise to add content control by performing the decryption on the
server. For outgoing messages I believe Outlook already supports
some kind of message "escrow" mechanism...
Anders