337430 - Dual Key Certs with different subject: Can't find S/Mime Encryption cert

Status: RESOLVED FIXED

(MailNews Core :: Security: S/MIME, defect, P2)

Description

[Kai Engert [:KaiE:]]

Mozilla Mail is unable to find a recipient's email encryption cert, although it is already stored in our cert database.

Background:
===========
When issueing certificates to individuals, it is possible to issue multiple separate certificates, one for each desired usage.

For example, you could issue one cert for email signing and one for email encryption.

When issueing such sets of certificates, usually all certs are issued to identical subjects / common names.

However, some PKI infrastructures do not follow this common practice.

We have encountered certificates, where different values for the individuals common name are being used. In the encryption cert we see a ".Encrypt" suffix, in the signing cert we see a ".ID" suffix.

Our current application logic does not find the encryption cert, when trying to compose and send an encrypted S/Mime message.

This bug suggests to enhance our application logic, in order to support such infrastructures.

Comment 1

[Kai Engert [:KaiE:]]

Attachment: Experimental Patch v1

This is an experimental patch.
It requires the enhancements from bug 337433 and bug 337486.

The idea is explicitly ask the cert database for certs with the required email encryption usage. Therefore I changed our calls to FindCertByEmailAddress to use FindEmailEncryptionCert.

(In the past FindEmailEncryptionCert (and FindEmailSigningCert) have been used to look for user certs only. But the API description does not make such a promise. The patch extends both functions. The behaviour will be extended, only if no user cert (cert having private key) is available for the given nickname. Instead of always returning an empty result, we'll now search for a peer cert with the respective usage.)

We're not yet 100% sure extending the interface this way is a good idea.
It would be the only approach possible to get a fix into TB 2, because we're already too late in the game to API additions.

Comment 2

[Robert Relyea]

Comment on attachment 221629 [details] [diff] [review]
Experimental Patch v1

r+=relyea

Comment 3

[Kai Engert [:KaiE:]]

Attachment: Patch v1 - mozilla portion - merged to mozilla-central

merged

Comment 4

[Kai Engert [:KaiE:]]

Attachment: Patch v1 - mailnews portion - merged to comm-central

Comment 5

[Kai Engert [:KaiE:]]

While directory mailnews/extensions/smime/ logically belongs to the PSM module, so Bob's and my participation and a single review are sufficient, IMO.

Comment 6

[Kaspar]

(In reply to comment #1)
> We're not yet 100% sure extending the interface this way is a good idea.
> It would be the only approach possible to get a fix into TB 2, because we're
> already too late in the game to API additions.

Actually, I think it isn't really a good idea... there are currently two callers of these functions:

- nsMsgComposeSecure::MimeCryptoHackCerts, in mailnews/extensions/smime/src/nsMsgComposeSecure.cpp

- checkOtherCert, in mailnews/extensions/smime/content/am-smime.js

(cf. http://mxr.mozilla.org/comm-central/ident?i=FindEmailSigningCert and http://mxr.mozilla.org/comm-central/ident?i=FindEmailEncryptionCert)

In both cases, the caller expects that it gets a "user certificate" - i.e., a cert where NSS also has a matching private key. If this assumption no longer holds true, then chances are pretty good that things will go wrong with nsMsgComposeSecure::MimeCryptoHackCerts and checkOtherCert (such as being unable to sign/encrypt "for unknown reasons" etc.).

I know that I'm repeating myself, but let me once again point to bug 596215 and bug 596221, which is a more thorough fix for the problem of finding an appropriate encryption cert. (Perhaps it could be enhanced to find signing certs as well.)

Comment 7

[Kai Engert [:KaiE:]]

(In reply to comment #6)
> 
> there are currently two
> callers of these functions:
> 
> - nsMsgComposeSecure::MimeCryptoHackCerts, in
> mailnews/extensions/smime/src/nsMsgComposeSecure.cpp
> 
> - checkOtherCert, in mailnews/extensions/smime/content/am-smime.js
> 
> (cf. http://mxr.mozilla.org/comm-central/ident?i=FindEmailSigningCert and
> http://mxr.mozilla.org/comm-central/ident?i=FindEmailEncryptionCert)
> 
> In both cases, the caller expects that it gets a "user certificate" - i.e., a
> cert where NSS also has a matching private key. If this assumption no longer
> holds true, then chances are pretty good that things will go wrong ... 


I agree.

I filed bug 612613 to get the intention clarified in the API comments.-

Comment 8

[Kai Engert [:KaiE:]]

Comment on attachment 478243 [details] [diff] [review]
Patch v1 - mozilla portion - merged to mozilla-central

I now agree with Kaspar that this patch is a bad idea.

Comment 9

[Kai Engert [:KaiE:]]

We believe this has been fixed by bug 596221.