On Nov 24, 2007, at 3:46 AM, Anders Rundgren wrote:
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.
Depends on your needs. DoD encrypted S/MIME is intended for end-to-
end message privacy. How do you get this by reusing a web service
TLS certificate?
In addition, how do you get by the rfc822Name matching requirements?
As far as I know *only* Microsoft Outlook can be configured to ignore
the required match between the recipient's email address and the
rfc822Name extension when encrypting a message.
Using the most current key is also a factor that were missing in Ian's
proposal.
This is a problem for all distribution methods *except* direct end
user to end user exchanges. Publication *always* lags issuance, and
often enough fails completely.
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.
Not just a bad provider. This exposes the key distribution mechanism
to DNS hijacking as well.
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...
If the goal is end-to-end message privacy, then server-side
decryption is a major violation. If you allow *either* server-side
decryption or end-user decryption, you've just made the protocol even
more complex than it currently is (and now you have the problem of no
knowing the complete security profile of your S/MIME deployment--are
messages decrypted at the server or not, who chooses, and in what
instances?).
-- Tim
smime.p7s
Description: S/MIME cryptographic signature