Hi Martin, Thanks for your email.
I’ve been using S/MIME within the US Government since 2006. We have an integrated PKI that’s based on hardware tokens. The experience is generally good. However, I do agree with you that there are persistent problems with verifying old signatures and decrypting old messages. For these reasons, NIST SP800-177 recommends that email clients re-encrypt messages, rather than leaving them encrypted for the original recipient. It’s also advisable for email clients to indicate if the signature was valid when received and retain this information somewhere, in addition to knowing if it is still valid. As an aside, this is not a problem specific to S/MIME — it’s a problem with any document-based encryption system. It impacts PGP, for example: I have old PGP-encrypted messages that I cannot decrypt because the keys were not properly migrated. Apple’s S/MIME implementation does a good job resolving some of these issues. For example, the S/MIME client (Mail.app) allows the user specify if the full-text of encrypted messages should be indexed. This presents a security vulnerability, since the message context and subject matter can be reconstructed from the index. However, if the index is stored on an encrypted media (and it should be), the risk is decreased. That’s why SP800-177 recommends that the mail store reside in a file system that is cryptographically protected. I should add that I also have 10+ year’s experience with soft certificates. Here the experience with the Apple implementation is better. Apple retains all old certificates and private keys in the user’s keychain, and that is replicated to all devices. So I am able to access old encrypted messages that were encrypted to my soft certificate. Simson > On Nov 28, 2016, at 7:48 AM, Martin Rex <[email protected]> wrote: > > Stephen Farrell wrote: >> >> Peter Gutmann wrote: >>> >>> Stephen Farrell <[email protected]> writes: >>> >>>> Is there a particular reason to try focus on enterprises here? >>> >>> That's about the only environment where it's feasible to deploy S/MIME. >> >> Sure. And yet smime is only deployed in a tiny fraction >> of enterprises and probably only used in a smallish >> fraction of the mail sent in those. > > I don't think that there exists an implementation of S/MIME that > can be reasonably deployed _anywhere_. > > S/MIME defines PDUs and PDU semantics. Those specs are OK for basic > interop. The problem isn't with S/MIME itself, but with how S/MIME > typically involves PKIX for certificates and certificate chains and > the private key associated with your own cert. > > What I'm seeing in S/MIME implementations is that S/MIME signatures > in archived EMails typically start failing within a year after archival. > I have a number of archived EMails from failed attempts to use S/MIME > in the enterprise, and they all fail signature validation today, although > there was no data corruption, and none of the signer certs have been revoked. > > In addition, there are a small number of messages that I can no longer open, > because renewal/replacement of my user's private key & cert was > "managed" in the enterprise setting, and the old/expired PKI credentials > weren't kept around by that foolish "enterprise solution". > > > Personally, I'm not aware of an S/MIME solution that works reasonably > with archived S/MIME-protected EMails. > > > -Martin _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
