After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777524 - Evolution does not perform revocation checks for S/MIME certificate
Evolution does not perform revocation checks for S/MIME certificate
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Mailer
3.22.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2017-01-20 09:52 UTC by Matthias Wachs
Modified: 2021-05-19 12:27 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Wachs 2017-01-20 09:52:32 UTC
S/MIME signatures on emails from in the revoked certificates are considered "valid". Evolution seems not to perform a revocation check.

According to https://tools.ietf.org/html/rfc5750#section-4.1

"4.1.  Certificate Revocation Lists

   All agents MUST be capable of performing revocation checks using CRLs
   as specified in [KEYM].  All agents MUST perform revocation status
   checking in accordance with [KEYM].  Receiving agents MUST recognize
   CRLs in received S/MIME messages.
"

revocation checks must be performed.

Outlook Web App and Thunderbird indicate such signatures as invalid.
Comment 1 Michael Catanzaro 2017-01-20 22:15:24 UTC
We definitely should add support for some form of revocation checking, but CRLs have kinda failed and no longer have industry support, so I'm not sure it's worthwhile to respect the standard in that regard. This would not be acceptable to Epiphany, for instance, since we shouldn't block page load to download a huge revocation list. That's not a good experience for email either. And I don't think we want to leave it up to applications to decide what form of revocation checking to perform; GTlsConnection should just do the right thing by default. And there's no way to implement this in Evolution with the current GTlsConnection API anyway, so I'll mark this as a duplicate of bug #636573. If you have opinions on certificate revocation, that would be a good place to share.

*** This bug has been marked as a duplicate of bug 636573 ***
Comment 2 Michael Catanzaro 2017-01-20 22:17:11 UTC
Actually it's not a duplicate, sorry, since this is for S/MIME, not TLS. My bad. I don't know how Evolution handles that.
Comment 3 Jeffrey Stedfast 2018-11-25 04:23:55 UTC
Evolution uses the Netscape Security library (libNSS iirc?) assuming things have stayed relatively the same since I last worked on Evolution (12+ years ago).

My recommendation would be to switch to GPGME which also supports gpgsm (i.e. the S/MIME module of gpg) which would automatically add revocation checks.

That said, there would need to be a way to import the user's existing certificates into gpgsm and I'm not sure how easy that would be.

FWIW, GMime's S/MIME support comes from GPGME now as well, so that would be a relatively easy way to port Camel's logic from (minus any headaches of migrating user certificate data).
Comment 4 André Klapper 2021-05-19 12:27:28 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. 
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
and create a new bug report ticket at
  https://gitlab.gnome.org/GNOME/evolution/-/issues/

Thank you for your understanding and your help.