When processing incoming S/MIME email that is digitally signed, we:
- (a) perform a check of the signature, including verification of the signing certificate
- (b) import the certificates that are found inside the signature, because they might be necessary for verifying the signing certificate, and also for making it possible to use these certificates in the future for encryption
The classic NSS verification is limited in its ability to perform revocation checking, in particular the current configuration used by the Gecko platform has trouble with a proxy configuration.
In addition the S/MIME implementation in NSS is hardcoded to use the classic NSS verification APIs.
Therefore in bug 324474, we had added an additional check at the mail code level. In bug 813418 that code was later upgraded to use the mozilla::pkix for an initial validity check.
However, that additional check is limited to check the signature certificate. Earlier, we perform import of certificates that are bundled with the signature.
This bug suggests that we perform the additional check for all certificates that we are automatically importing, too.
We should expedite adding this check, therefore I'm using a workaround that involves copying some internal NSS code to the Thunderbird code. At a later time, we should clean this up by adding a new API to NSS, that allows the mail code to perform its own additional checks using a callback. (The design of the new API can be discussed at a later time, when we perform the cleanup.)
It was noticed that the mozilla::pkix code doesn't support checking DSA certificates nor RSA-PSS certificates.
This means, because of the existing checks, we never show signatures from such certificates as valid. I couldn't find any bug report in the S/MIME component mentioning the classic DSA algorithm, so apparently nobody has ever complained that DSA cert signatures are always reported in Thunderbird as invalid. And it's already known that RSA-PSS is not yet supported by the Thunderbird S/MIME code (bug 1597202).
Therefore I'm not worried that the suggested change will extend this limitation to the automatic certificate import from incoming email, it seems unlikely that it will have a relevant impact.