# header information, ca settings and end-to-end encryption **URL:** \ **Category:** Gateway\ **Created:** [February 1, 2011, 11:37am UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/160 "2011-02-01T11:37:56Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![martijn](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/martijn/32/127_2.png) [@martijn](https://community.ciphermail.com/u/martijn)\ **Post date:** [February 1, 2011, 11:37am UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/160/1 "2011-02-01T11:37:56Z")
> > "was never intended to" depends on how you look at it :). From my point > > of view it was intended that way because I implemented it that way. > > Djigzo is an email encryption gateway that encrypts and decrypts email > > at the gateway level. If you don't want email to be decrypted at the > > gateway level than don't put the private key on the gateway. If the > > private key is not available, the message cannot be decrypted. > > What do you think is the benefit of this feature? Is there any "normal" situation you forward an encrypted email without reencrypting it? Quite a lot of companies you it for domain to domain encryption. Setting up domain to domain encryption is really easy because the email is decrypted with any key it can find. > > Then you should either not use a gateway encryption product or encrypt > > email for specific users with certificates that are not stored on the > > gateway (i.e., use real desktop-to-desktop encryption). A gateway > > encryption solution assumes that you can trust you internal infrastructure. > > I think a gateway solution should not weaken the security of a desktop-to-desktop scenario, in situations it is not necessary in. I use a gateway scenario, because I want to benefit from the advantages like a centralized archive, an enforceable security policy and the transparency in front of my users. On the one hand I share your opinion, that in general you should assume to trust your internal infrastructure, but on the other hand there may be employees with different responsibilities which may not share same trust level. I understand your objections. Part of the reasons it was implemented this way is that it's much easier from a management perspective. The gateway tries to decrypt if possible. If this is not the required behavior it's best to use a desktop encryption product. I can however see how I can add an option to turn on "extra secure" mode. This however requires that when a message is received and the message has multiple recipients that the message is decrypted multiple times for all recipients and if it cannot be decrypted for a recipient because there is no key for the recipient that the message is delivered encrypted. It also has to be clear what certificate belongs to the user. Certificates are ok for a recipient if the email addresses in the certificate matches? This implies that domain encryption no longer works. What behavior would you like the gateway to have in "extra secure" mode? > I have noticed, that other products refuse to decrypt messages in such a scenario. I just wanted to make sure you are aware of this feature and wanted to hear your opinion about it. I really appreciate your help and input. Have you also tried to see how they handle the case where you add an extra recipient. So, you have an encrypted message for user test(a)example.com, now you also add as an extra recipient test2(a)example.com (to the message envelope and header). Is the message then decrypted for user test(a)example.com and for user test2(a)example.com it's still encrypted? Kind regards, Martijn > **···** > > On 02/01/2011 11:53 AM, Manuel Faux wrote: > > -- > Djigzo open source email encryption ---
**Author:** ![Manuel\_Faux](https://avatars.discourse-cdn.com/v4/letter/m/50afbb/32.png) [@Manuel\_Faux](https://community.ciphermail.com/u/Manuel_Faux)\ **Post date:** [February 1, 2011, 11:53am UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/160/2 "2011-02-01T11:53:45Z")
> I understand your objections. Part of the reasons it was implemented > this way is that it's much easier from a management perspective. The > gateway tries to decrypt if possible. If this is not the required > behavior it's best to use a desktop encryption product. I can however > see how I can add an option to turn on "extra secure" mode. This however > requires that when a message is received and the message has multiple > recipients that the message is decrypted multiple times for all > recipients and if it cannot be decrypted for a recipient because there > is no key for the recipient that the message is delivered encrypted. It > also has to be clear what certificate belongs to the user. Certificates > are ok for a recipient if the email addresses in the certificate > matches? This implies that domain encryption no longer works. > > What behavior would you like the gateway to have in "extra secure" mode? Maybe explicitly distinguishing between user certificates and domain certificates solves the problem. A domain certificate should not contain any email address at all, is that correct? I would simply remove all recipients from the mail, which do not have a valid certificate to decrypt the mail. Is this possible with the internal structure of Djigzo? Does the decrypting engine know anything about recipients? > > I have noticed, that other products refuse to decrypt messages in such a > > scenario. I just wanted to make sure you are aware of this feature and wanted > > to hear your opinion about it. > > I really appreciate your help and input. Have you also tried to see how > they handle the case where you add an extra recipient. So, you have an > encrypted message for user test at example.com, now you also add as an > extra recipient test2 at example.com (to the message envelope and header). > Is the message then decrypted for user test at example.com and for user > test2 at example.com it's still encrypted? In this case, test2(a)example.com would receive the encrypted mail as an pkcs7 attachment, as he would receive without the existence of any encryption gateway, but the subject contains a string, which explains, that the mail could not be decrypted. ---
**Author:** ![lst\_hoe021](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lst\_hoe021](https://community.ciphermail.com/u/lst_hoe021)\ **Post date:** [February 1, 2011, 12:00pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/160/3 "2011-02-01T12:00:11Z")
Zitat von Martijn Brinkers \: > > > "was never intended to" depends on how you look at it :). From my point > > > of view it was intended that way because I implemented it that way. > > > Djigzo is an email encryption gateway that encrypts and decrypts email > > > at the gateway level. If you don't want email to be decrypted at the > > > gateway level than don't put the private key on the gateway. If the > > > private key is not available, the message cannot be decrypted. > > > > What do you think is the benefit of this feature? Is there any > > "normal" situation you forward an encrypted email without > > reencrypting it? > > Quite a lot of companies you it for domain to domain encryption. Setting > up domain to domain encryption is really easy because the email is > decrypted with any key it can find. > > > > Then you should either not use a gateway encryption product or encrypt > > > email for specific users with certificates that are not stored on the > > > gateway (i.e., use real desktop-to-desktop encryption). A gateway > > > encryption solution assumes that you can trust you internal infrastructure. > > > > I think a gateway solution should not weaken the security of a > > desktop-to-desktop scenario, in situations it is not necessary in. > > I use a gateway scenario, because I want to benefit from the > > advantages like a centralized archive, an enforceable security > > policy and the transparency in front of my users. On the one hand I > > share your opinion, that in general you should assume to trust your > > internal infrastructure, but on the other hand there may be > > employees with different responsibilities which may not share same > > trust level. > > I understand your objections. Part of the reasons it was implemented > this way is that it's much easier from a management perspective. The > gateway tries to decrypt if possible. If this is not the required > behavior it's best to use a desktop encryption product. I can however > see how I can add an option to turn on "extra secure" mode. This however > requires that when a message is received and the message has multiple > recipients that the message is decrypted multiple times for all > recipients and if it cannot be decrypted for a recipient because there > is no key for the recipient that the message is delivered encrypted. It > also has to be clear what certificate belongs to the user. Certificates > are ok for a recipient if the email addresses in the certificate > matches? This implies that domain encryption no longer works. > > What behavior would you like the gateway to have in "extra secure" mode? > > > I have noticed, that other products refuse to decrypt messages in > > such a scenario. I just wanted to make sure you are aware of this > > feature and wanted to hear your opinion about it. > > I really appreciate your help and input. Have you also tried to see how > they handle the case where you add an extra recipient. So, you have an > encrypted message for user test(a)example.com, now you also add as an > extra recipient test2(a)example.com (to the message envelope and header). > Is the message then decrypted for user test(a)example.com and for user > test2(a)example.com it's still encrypted? What does a normal Mailclient do in this case? As far as i know Outlook/Thunderbird refuses to send a encrypted mail if there is no matching (mailadress) certificate for one of the recipients and split the mail so every copy is encrypted with the certificate which matches the recipient. So the case to have a (internal) recipient with no private key on the gateway but encrypted mail (with some other certificate from the gateway) should not happen beside the case "domain-encryption". So i would vote for a switch to allow either domain-encryption or secure-mode with matching recipient address and private-key. Regards Andreas > **···** > > > On 02/01/2011 11:53 AM, Manuel Faux wrote: ---
**Author:** ![martijn](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/martijn/32/127_2.png) [@martijn](https://community.ciphermail.com/u/martijn)\ **Post date:** [February 1, 2011, 12:23pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/160/4 "2011-02-01T12:23:09Z")
> > I really appreciate your help and input. Have you also tried to see how > > they handle the case where you add an extra recipient. So, you have an > > encrypted message for user test(a)example.com, now you also add as an > > extra recipient test2(a)example.com (to the message envelope and header). > > Is the message then decrypted for user test(a)example.com and for user > > test2(a)example.com it's still encrypted? > > What does a normal Mailclient do in this case? As far as i know > Outlook/Thunderbird refuses to send a encrypted mail if there is no > matching (mailadress) certificate for one of the recipients and split > the mail so every copy is encrypted with the certificate which matches > the recipient. > So the case to have a (internal) recipient with no private key on the > gateway but encrypted mail (with some other certificate from the > gateway) should not happen beside the case "domain-encryption". There are exceptions to the rule (as always 🙂 but in most cases this is true. An exception is when the sender manually selected a certificate for a recipient with a non-matching email address. This can happen in practice when a recipient has multiple aliases (and is using a gateway). > So i would vote for a switch to allow either domain-encryption or > secure-mode with matching recipient address and private-key. This option would imply that a message need to be decrypted multiple times, once for each recipient, so it may impact the speed a bit. I will put this option on the development agenda. > **···** > > On 01/-10/-28163 08:59 PM, lst\_hoe02(a)kwsoft.de wrote: > > -- > Djigzo open source email encryption ---
**Author:** ![Manuel\_Faux](https://avatars.discourse-cdn.com/v4/letter/m/50afbb/32.png) [@Manuel\_Faux](https://community.ciphermail.com/u/Manuel_Faux)\ **Post date:** [February 1, 2011, 12:26pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/160/5 "2011-02-01T12:26:20Z")
> What does a normal Mailclient do in this case? As far as i know > Outlook/Thunderbird refuses to send a encrypted mail if there is no matching > (mailadress) certificate for one of the recipients and split the mail so every > copy is encrypted with the certificate which matches the recipient. > So the case to have a (internal) recipient with no private key on the gateway > but encrypted mail (with some other certificate from the > gateway) should not happen beside the case "domain-encryption". Yes, Thunderbird refuses to send or even store the mail until a certificate is configured to be used. The trick is not to encrypting the whole email several times, but to encrypt the mail once with a random generated passphrase and encrypting this passphrase several times. This keeps the mail smaller in size and allows the use of hybrid encryption (asymmetric certificates and symmetric mail encryption). Thunderbird also behaves similar as Djigzo does at the moment: Is uses any available private key to open the mail, regardless if the key was configured for another mail account than the mail was received with. I think this behavior is legitimate, because one Thunderbird profile is only used by one person at one time. > So i would vote for a switch to allow either domain-encryption or secure-mode > with matching recipient address and private-key. I share your opinion, but maybe it is possible to use both modes at the same time, by differentiating at certificate level: A domain certificate does not contain any email address, but a personal certificate does. Kind Regards, Manuel Faux ---
**Author:** ![martijn](https://dub1.discourse-cdn.com/flex017/user_avatar/community.ciphermail.com/martijn/32/127_2.png) [@martijn](https://community.ciphermail.com/u/martijn)\ **Post date:** [February 1, 2011, 12:31pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/160/6 "2011-02-01T12:31:49Z")
> Thunderbird also behaves similar as Djigzo does at the moment: Is uses any > available private key to open the mail, regardless if the key was configured > for another mail account than the mail was received with. I think this behavior > is legitimate, because one Thunderbird profile is only used by one person at one > time. As far as I know all email clients work like this. They use any private key available for decryption. > > So i would vote for a switch to allow either domain-encryption or secure-mode > > with matching recipient address and private-key. > > I share your opinion, but maybe it is possible to use both modes at the same time, > by differentiating at certificate level: A domain certificate does not contain > any email address, but a personal certificate does. Strictly speaking there is no RFC yet (I think) that defines what a domain certificate should look like. There should therefore be some way to differentiate a domain certificate from a non-domain certificate. Right now only the sender specifies which certificate the receiver is using as a domain certificate. With the strict mode, the receiver should also specify which certificate is used as a domain certificate. Kind regards, Martijn > **···** > > -- > Djigzo open source email encryption