<div dir="ltr">I can't see anyway that S/MIME gets resolved with anything other than heuristics that look for the footprints of the CBC malleability in efail (random blocks and/or 8bit content) etc.<div><br></div><div>There are two other alternatives, only one is plausible, IMO</div><div><br></div><div>1) Only allow emails where the signature verifies. It doesn't have to be valid in terms of chaining to a trusted root, but it does need to verify. This also means you throw out anything not signed (or signed first, then encrypted) (both of which are allowed).<br></div><div><br></div><div>This option may turn out to be plausibly implemented - but is a pretty big change to how most S/MIME implementations in actual clients work - they usually hardly do anything even with bad signatures.</div><div><br></div><div>2) Use the various AE CMS RFCs - This is a long-term effort given the experience with OpenPGP in deprecating non-MDC packets. First either the S/MIME RFC needs to be updated to remove AES-CBC as essentially the default and replace it with another one - AND certificates need to start using the SMIMECapabilitiesExtensions - or vendors start ignoring the existing RFC and just go ahead. I don't see any way a sender can have some plausible idea what the recipient can decrypt without having some knowledge of the version of S/MIME they are using - and this is what SMIMECapabilities is for in the certificate.</div><div><br></div><div>Then once the vendors get together and decide on the new behaviour, and the certs get updated with new Capabilities - we can wait about how many years for it all to percolate through the ecosystem? There is a reason no one bothered to implement any of those RFCs in the first place.</div><div><br></div><div>For OpenPGP and MDC, I vote for completely and fully removing non-MDC SE Packets - no more generating SE packets for any version of keys or ciphers, ignoring the MDC feature packet in V4 keys, and refusing to decrypt anything without MDC. I'm ok if some kind of user option needs to exist to decrypt old content - but I think it should be clearly seen as a dangerous and insecure option.</div><div><br></div><div>-Earle</div></div>