115359 - Public key cert failed to add to certdb with encrypt only msg

Status: RESOLVED INVALID

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

Description

[Antonio Lam]

Build used: 2001-12-14 trunk

Step to reproduce:

1. Create a new profile with sectest account, go to "pb.mcom.com" to import the 
sectest2's public key certificate.
2. From sectest account, send an encrypt ONLY message to sectest2.
3. From sectest2 account, open the encrypted message sent from sectest1. The 
message should be decrypted and display correctly.

Actual result: The sender(sectest)'s public key cert is not added to the certdb. 
(Open the "Other People" tab from the Certificate Manager, and the sectest's 
public key cert is not there).

Expected result: The sender(sectest)'s public key cert should be added to the 
certdb, and can be viewed in the "Other People" tab from the Cert Manager.

Comment 1

[Stephane Saux]

Antonio,
Can you check that the certs did verify in each of these accounts? The issues
here may be that we won't import the cert in the db if the cert doesn't verify.
If you don't have the Intranet Certificate Authority cert in sectest2 profile,
or the GTE CyberTrust Root (signer of Int. Cert. Auth.) is not trusted then the
cert wouldn't verify, and would not be added to the cert.

Why shouldn't the cert not be added? Because otherwise, one may try to trick you
into believing that you have a valid encryption cert for sectest, and you would
send an encrypted email to sectest when in fact it would be encrypted with
somebody's cert. Somebody listening to the wire who would have planted the cert
would then be able to read the message.  Sectest wouldn't.

In fact the code today wouldn't find the certificate if it's not trusted and
would not use it to encrypt.

So if the issue was that you missed the appropriate trusted chain, the bug is
invalid.

Comment 2

[Antonio Lam]

I have confirmed that both the sectest and sectest2's certs are verified 
correctly, and the "GTE Cyber Trust Root" CA is trusted for the following:

1. Can identify web sites.
2. Can identify mail users
3. Can identify software makers

for both account.

Comment 3

[Antonio Lam]

I also trusted all three operations for "Intranet Certificate Authority" CA, and 
same problem: Sender's cert is not add to be certdb.

Comment 4

[Kai Engert (:KaiE:)]

I think I have seen this, too.

I suspect, when a encrypted only message is sent, the certificates are not even
getting attached to the message.

I will have to check that.

Comment 5

[Stephane Saux]

S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there
may be some adjustment of the list).

Comment 6

[Stephane Saux]

confirming

Comment 7

[Kai Engert (:KaiE:)]

Note to self: As far as I understand it now, we currently have only one location
in the code, where certs from messages are being imported, and that is inside
nsCMSMessage::VerifyDetachedSignature. 

Comment 8

[Kai Engert (:KaiE:)]

I would like to de-nominate from beta. I think this is a feature, not a bug.

I looked at what Communicator did. It doesn't learn the sender's by reading an
ecnrytped-only message.

Whenever I heard in the past about S/Mime, all instructions said, you begin by
receiving a signed message, to obtain someone's cert.

Is it even allowed to collect certs from non-signed emails?

Comment 9

[Charles Rosendahl]

If the sender cert is not present, then how will replies be encrypted or
forwarded messages be decrypted?

As to whether or not it gets added to the other's tab, is a matter of
preference.  My take on it is that a signature invites the use of encryption
(should an encryption cert be provided) in any case, whereas an encrypted
message mandates encryption on replies and forwarding.

Comment 10

[Kai Engert (:KaiE:)]

Ok, thinking about this more, I changed my mind and now agree the request is valid.


Suppose person A sends an encrypted message to a group of people, including B and C.
Suppose you previously received a signed message from person A.
Suppose you are person B.
Suppose you never received a signed message from person C.


I agree that it is reasonable that you (person B) should be able to compose an
encrypted reply to all recipients of the original message.

In order to achieve this goal, we must import all valid certificates of all
recipients of the received encrypted only message.


I wonder whether this problem still exists. There was a time, when sent messages
were not encrypted to self. As a result, the sender's cert was not contained in
the list of recipients. But meanwhile this problem was fixed, and if the sender
has a personal encryption cert configured, the sender's cert will be included.


Charles, could you please test whether this is meanwhile working?
If not, we should import all valid recipient certificates.

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

An encrypted-only (not signed) message is called an "enveloped" message in 
S/MIME-speak.  An enveloped message does not contain a complete copy of any
certificates (unless those certificates were sent as attachments to the 
message by the sender).  An enveloped message contains "Recipient Info" 
structures that help the recipient identify which of his certificates is 
the one that was used when the message was encrypted, but these typically
only contain the Issuer Name and Serial Number fields of the recipient's 
certificate, not the entire certificate.  

So, the messages simply do not have the info necessary to do what this bug/RFE
requests.  Changing that would mean changing the CMS protocol (the protocol
that defines the format of the signed or encrypted contents of an S/MIME 
message).  See RFC 2630, section 6, Enveloped-data Content Type.