ietf-smime
[Top] [All Lists]

Re: S/MIME key distribution proposal

2007-11-28 09:53:38
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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>