S/MIME or PGP/MIME?

[Len Sassaman]

Another point to note, of course, is that there is no way to prevent
people from using 40 bit encryption when sending S/MIME messages to you,
due to a number of technical mistakes in the S/MIME standard.

If people are interested, I'll dig up my list of reasons why S/MIME is
dumb.

On Fri, 7 Dec 2001, Lionel Elie Mamane wrote:

> On Thu, Dec 06, 2001 at 05:14:34PM -0800, Paul Holman wrote:
>
> > I think there are a couple really important things to learn from the
> > S/MIME mailer implementations we've seen:
>
> IMHO, these are convenience-over-security choices.
>
> > 1	Key Propogation
> > S/MIME mailers attach the cert to every outgoing message and notice
> > when a cert is attached to incoming messages and add it to the
> > keyring (mixing metaphors a bit).
>
> Bandwidth waste... And this is polluting the keyring with potentially
> invalid (faked) keys. Adding a key to the keyring in the user's back
> certainly isn't good an idea.
>
> > 2	Opportunistic Encryption
> > Try sending a message to half a dozen recipients when you only have
> > keys for half of them.  S/MIME mailers will encrypt tho those it
> > can, and send cleartext to the rest.
>
> Hu? That's clearly a security risk. If you want the message encrypted
> and it silently sends it as cleartext... You mean they really do that?
> Oh my god...
>
> > 3	Seamless Integration (My favorite!)
> > S/MIME mailers never show you any cyphertext.  They just have little
> > icons to indicate when a message was encrypted or verified
> > successfully.
>
> Mutt does that >:-)
>
> > However, the problem isn't that the mailer developers are doing it
> > wrong, it is that they haven't been given the tool they need - an open
> > source OpenPGP toolkit.
>
> libgpgme?
>

--

Len Sassaman

Security Architect            |  "Now it's all change --
Technology Consultant         |   It's got to change more."
                              |
http://sion.quickie.net       |              --Joe Jackson