Open Bug 1858275 Opened 1 year ago Updated 1 year ago

Support for vanilla offline and online CRLs v2 (certificate revocation lists)

Categories

(MailNews Core :: Security: S/MIME, enhancement)

Thunderbird 115
enhancement

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: leszek.zablocki, Unassigned)

Details

Attachments

(2 files)

Steps to reproduce:

· RFC 5280 May 2008

This is a feature request. I know that mozilla creates a clever variation of CRL (CRLite) and got rid of the regular CRL bug#322070#c8. But certificates and their management are different between SSL and S/MIME. The specifics of browsing secure sites in Firefox are different, and receiving encrypted emails in Th. are different. The CRL can be useful for administrators of a small, private PKI. The operation and configuration of CRL is relatively simple compared to OCSP. etc.

In the S/MIME BRs standard, the CRL is treated on a par with the OCSP.

I write this also as a fan of the replacement for OpenPGP for individuals. Th. does not support WebOfTrust, as far as I know, and S/MIME has more capabilities. In addition, it has the support of the industry and relies on certificates used by websites. etc.

I would distinguish between the introduction of the CRL online (via X509v3 CRL Distribution Points in certificates), and offline (in the certificates there are no URIs with CRLDP). Certificate status is received in emails (bug#36454), from .crl files on disk, etc.

https://datatracker.ietf.org/doc/html/rfc5280#section-3.3

An advantage of this revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves,
namely, via untrusted servers and untrusted communications.

This can be solved as follows:

If the EE (leaf) certificate does not have OCSP in AIA, we check CRLDP (online approach). If the leaf certificate has neither OCSP nor CRLDP, when we receive a CRL from someone in the message, we capture the CRL and overwrite the certs database.

I created scripts that create 2 certificates. The first one is revoked, and then a second key and a new certificate are created (mimicking keyCompromise). The script does exactly the same thing in the offline and online versions, the difference is only the addition of CRLDP to the online version. You can observe the behavior of the programs by configuring a mini http server XAMPP (I used Rebex Tiny Web Server) and checking if the program pings the CRL from this server. The script creates 2 S/MIME signed messages: the first one before revocation, the second one with a new key and certificate after the first cert is revoked.

related: bug#530356, bug#481447, bug#133191, bug#234762, bug#217387, bug#1738592, bug#355513, bug#418762, bug#457923, bug#36454, bug#1735832

closed: bug#292776, bug#1248557, bug#1490737, bug#118855

· CRLs in enterprise PKI environments

· how browsers handle certificate revocation

· Revocation is broken

· A New Life for Certificate Revocation Lists

· CRLite: A Scalable System...

Actual results:

Th. 115 has the option to check status through the CRL disabled.

Expected results:

After importing: root cert, first cert - displays message no1 indicating OK.

After importing: the second cert and crl (received from email or imported directly) displays OK the second message, the first with a message about the revocation of the cert used to sign this message.

we need to move these two messages to a local folder (bug#1806122, bug#1688163)

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: