John R Levine wrote:
S/MIME has been widely available for close to 20 years, implemented in
nearly all desktop MUAs, and the number of people who use it (other than
the ones whose employers demand it) still rounds to zero. PGP is no
better, despite the wide availablity of public PGP key servers. I think
the poor match between the addresses in certs and the ones in real mail is
one of the reasons.
I've seen something called S/MIME in MUAs, but it is not even close to
what I would consider usable support for encryption & digital signatures
in EMail. The original PGP, although it's not used more often,
at least doesn't suffer from obvious S/MIME fuckups.
What I've been seeing with S/MIME is several obvious total failures
(1) in aspects of the protocol
(2) in the MUA handling of archived digitally signed and encrypted mail
(3) in the management of S/MIME certs (and S/MIME credentials)
by both the public CAs signing these
(4) in the management of S/MIME certs and trust by the MUAs
But the underlying fundamental problem is that PKIX only really
works for *online* authentication, and EMail implies archiving of
messages, and PKIX just sucks here and S/MIME is TITSUP about
archived EMails.
Several years go I received an S/MIME signed email from the car dealer&garage
about a maintenance issue with my car. The signing certificate was
issued under a RootCA cert that was neither publicly available,
nor was it included in the S/MIME message (an S/MIME protocol defect).
It was simply impossible to make Outlook (2003 on WinXP 64-bit) verify
that S/MIME signature due to the lack of the RootCA cert. Importing
and marking as trusted the intermediateCA cert (that was included in the
S/MIME message) or the end-entity cert (that was also included in the
S/MIME message) did not help a iota.
The obvious failures here are (1) why does S/MIME allow sending of
S/MIME message with cert _chains_ that are incomplete. This is obvious
crap and should have been prohibited in S/MIME from the beginning.
The decision which cert from an X.509v3 cert path to trust, whether to use
"leap-of-faith" to establish this trust, and wether trust anchor
certs for the purpose are pulled from the message or distributed
out-of-band *MUST* be with the end-user.
Not being able to configure trust for this message to that signature
verification would succeed is TITSUP type (4) of the Outlook MUA.
I also have dozens of S/MIME-signed messages from colleagues sitting
in my EMail archives that are now being reported with "invalid signature",
but which verified just fine at some point in the past. That is a total
failure of the (3) kind of the cert-signing CAs, plus a total failure
in (2) of the Outlook MUA in not timestamp-resigning received
digitally-signed mail before archiving it, so that digital signature
can still be verified in 20+ years.
Another issue is with encrypted EMail (one receives) and having to roll
one's own S/MIME keypair when the short-lived cert expires. S/MIME MUAs
must either be prepared to properly handle dozens of prior S/MIME credentials
in order to access archived encrypted S/MIME messages, or they will have
to detach the encryption from the S/MIME-credential before message archival,
and re-encrypt the message with a key that will be long-term available.
The options for access of archived encrypted needs to be *standardized*
by S/MIME so that switching from one MUA to a different one will work
smoothly. S/MIME is TITSUP in that area of archived encrypted EMail.
-Martin
*TITSUP = "Totally Incapable To Support Usual Performance" (theRegister)
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp