Used Zammad version: 5.1.0-1648060831.1049368f.bullseye
Installation method (source, package, …): package
Operating system: Debian 11
Database + version: PostgreSQL 13.5
Elasticsearch version: 7.17.1
Browser + version: Firefox 98.0.1
Creating a new article (new or existing ticket) as mail with To and CC addresses correctly checks for each of the addresses if encryption is possible (i.e. enables and disables the “encrypt” button accordingly). However, sending this article with encryption and signature enabled generates an email that is only encrypted to the addresses listed in the To field. Example:
Encrypted mail is only readable by direct recipients and not by CC’d ones.
Steps to reproduce the behavior:
Create a new ticket
Select email
Fill To and CC with different mail addresses that you both have an imported S/MIME public key for
Send mail
Download raw version of the created article
Observe via openssl cms that it is only encrypted for the certificate of the “To” address
I am not sure how this is a technical question and not considered a bug, but I was directed here. I can only assume that this might be specific to our installation, so any confirmation of this behaviour in other installations using S/MIME encryption is welcome
Because this issue was quite problematic in an ongoing case, a colleague and I investigated more deeply. We found the root cause to be this line of code, which does not include CC addresses during encryption. A “works, but probably suboptimal” patch can be found here, I’m sure there is a cleaner way to implement if one actually knows how to write ruby. We might also have missed some other cases were this needs change.
However, I have to disagree with your judgement. S/MIME encryption has always been “one-to-many”, see RFC 2315, Cryptographic Message Syntax in section 10 (RFC 2315 - PKCS #7: Cryptographic Message Syntax Version 1.5). A message-specific symmetric content encryption key is encrypted with every recipients public key from their certificate and stored in a specified place in the ASN.1 structure. In fact, the Ruby implementation for S/MIME in use by Zammad is capable of producing such ASN.1 structures.
With the, and I agree here with you, very hot patch, Zammad sends messages that all receivers can decrypt and read.
Even without the patch, it is possible in Zammad to send to multiple TO’s if you select “new mail” from an existing ticket. In this case, a correctly encrypted mail to multiple recipients will be sent!
In my opinion, this non-conformance to specifications is clearly a bug.
It might be that this is technically a feature request and not a bug. In this case, I would ask you to consider this as a feature request and consider another thing:
Zammad does not signal that the CC’d recipients will not be able read the encrypted mail. The interface gladly lets you select “Encryption” and proceed to send a mail that most of the recipients will not be able to read. I would consider this to be a flaw in the user interface at the very least.
I do not quite get what you mean by “conflicting keys”, can you elaborate?
P.S: Every large S/MIME capable mail client I have experience with (Outlook, Thunderbird, FairEmail) can encrypt to many receivers, no matter if they are given in the TO, CC or BCC fields. The same scheme is used by OpenPGP to implement multiple receivers.
I believe it was specified the way I’ve described it. At least application wise.
If this is against RFC and the native libaries do support it already feel free to fill a bug report.
That’s clearly a feature request for this board section:
