Comments: How S/MIME could suck slightly less with a simple GETSMIME

I think you're over-thinking this, which is the whole problem with S/MIME.

If people in crypto didn't over-think so much, companies like Apple would have S/MIME enabled by default to at least *read* signed E-Mails. There is absolutely zero rationale why S/MIME is disabled even to the point of not being able to read the checkmark next to someone's name, even with the "sign: no encrypt: no" setting on the iOS. That makes zero sense-- it means everyone gets an attachment when they read my signed E-Mails, instead of a checkmark, until they enable S/MIME (and I'm not talking about asking them to sign themselves).

Also, judges aren't idiots. They don't conflate "signed" E-Mails with authorization of its contents-- merely that the E-Mail originated from its sender, the actual definition of the instance the word is used for. Also, you don't need to sign an E-Mail with S/MIME to be held liable for having written it-- ask Apple RE: the outcome of their book deal.

Until signature authorities get smart about issuing creds to the point of making partnerships with E-Mail clients like Outlook and Thunderbird, only nerds have them, and lawyers don't even use them most of the time to their individual clients because they don't feel like giving tech support lessons on how to enable S/MIME and avoiding webmail for confidential correspondence.

All in all, if cryptographers just took more valium, E-Mail clients partnered with CA authorities for in-client registration of a certification for personal use, we'd have one-click issuance of CA's, millions more would use them, and the damn iPhone wouldn't needlessly not enable *reading* S/MIME even though it's built-in to the damn thing.

Posted by Unsigned at August 17, 2013 10:31 AM
Post a comment

Remember personal info?

Hit Preview to see your comment.
MT::App::Comments=HASH(0x55c5ccbcd6a8) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/ line 125.