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

RESOLVED FIXED in mozilla1.9alpha1

Status

P2
normal
RESOLVED FIXED
13 years ago
7 years ago

People

(Reporter: kaie, Assigned: kaie)

Tracking

Trunk
mozilla1.9alpha1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kerh-coa][psm-smime])

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

13 years ago
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.
(Assignee)

Updated

13 years ago
Depends on: 337433
(Assignee)

Updated

13 years ago
Depends on: 337486
(Assignee)

Comment 1

13 years ago
Created attachment 221629 [details] [diff] [review]
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.
Attachment #221629 - Flags: review?(rrelyea)
(Assignee)

Updated

13 years ago
Priority: -- → P2
Whiteboard: [kerh-coa]
Target Milestone: --- → mozilla1.9alpha

Comment 2

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

r+=relyea
Attachment #221629 - Flags: review?(rrelyea) → review+
QA Contact: s.mime

Updated

10 years ago
Assignee: kaie → nobody
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
(Assignee)

Updated

8 years ago
Whiteboard: [kerh-coa] → [kerh-coa][psm-smime]
(Assignee)

Comment 3

8 years ago
Created attachment 478243 [details] [diff] [review]
Patch v1 - mozilla portion - merged to mozilla-central

merged
Attachment #221629 - Attachment is obsolete: true
Attachment #478243 - Flags: review+
(Assignee)

Comment 4

8 years ago
Created attachment 478244 [details] [diff] [review]
Patch v1 - mailnews portion - merged to comm-central
Attachment #478244 - Flags: review+
(Assignee)

Updated

8 years ago
Assignee: nobody → kaie
(Assignee)

Comment 5

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

Updated

8 years ago
Depends on: 599324

Comment 6

8 years ago
(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.)
(Assignee)

Comment 7

8 years ago
(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.-
(Assignee)

Comment 8

8 years ago
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.
Attachment #478243 - Flags: review+ → review-
(Assignee)

Updated

8 years ago
Attachment #478244 - Flags: review+ → review-
(Assignee)

Comment 9

7 years ago
We believe this has been fixed by bug 596221.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.