# header information, ca settings and end-to-end encryption **URL:** \ **Category:** Gateway\ **Created:** [January 12, 2011, 2:32pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155 "2011-01-12T14:32:26Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Bernhard\_Heinzle](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@Bernhard\_Heinzle](https://community.ciphermail.com/u/Bernhard_Heinzle)\ **Post date:** [January 12, 2011, 2:32pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/1 "2011-01-12T14:32:26Z")
Hi Martjin, maybe you can help me with the following issues: On incoming signed E-Mails, Djigzo puts the CN of the sender's intermediate CA next to the "X-Djigzo-Info-Signer-ID-0-1"-header. Shouldn't it be the CN of the sender's user certificate which is displayed? Same thing happens with the " X-Djigzo-Info-Encryption-Recipient-0-0"-Header in incoming encrypted E-Mails. Is there a way to use the value of the FROM-header instead of the default CN ("persona non-validated" by default) for automatically generated certificates? As long as outgoing emails have their source in my trusted environment, this would make things easier without representing a security issue. Is it possible to use end-to-end encryption for specific users, so that a specific user has it's own private key stored on his client and djigzo only passes through the encrypted email? I tried to do so. But as I don't have any CA except Djigzo's built-in CA, i created the internal user and its certificate with the built-in CA, exported the key to the client, deleted the user, but Djigzo still decrypts incoming E-Mail for this user before. Is this a bug or working as intended? Kind regards, Bernhard ---
**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:** [January 12, 2011, 3:02pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/2 "2011-01-12T15:02:18Z")
Zitat von Bernhard Heinzle \: > Hi Martjin, > > maybe you can help me with the following issues: > > On incoming signed E-Mails, Djigzo puts the CN of the sender's > intermediate CA next to the "X-Djigzo-Info-Signer-ID-0-1"-header. > Shouldn't it be the CN of the sender's user certificate which is displayed? > Same thing happens with the " > X-Djigzo-Info-Encryption-Recipient-0-0"-Header in incoming encrypted > E-Mails. The standard mail clients i'm aware of don't display headers at all so not sure what you are trying to achieve... > Is there a way to use the value of the FROM-header instead of the > default CN ("persona non-validated" by default) for automatically > generated certificates? > As long as outgoing emails have their source in my trusted environment, > this would make things easier without representing a security issue. > > Is it possible to use end-to-end encryption for specific users, so that > a specific user has it's own private key stored on his client and djigzo > only passes through the encrypted email? > I tried to do so. But as I don't have any CA except Djigzo's built-in > CA, i created the internal user and its certificate with the built-in > CA, exported the key to the client, deleted the user, but Djigzo still > decrypts incoming E-Mail for this user before. Is this a bug or working > as intended? You must delete the users certificate/key after export in Djigzo. The "user" is only a container for user specific settings and created on-the-fly with defaults if not available. As long as Djigzo finds a matching private key it does its work and decrypt the message. Regards Andreas > **···** > > > Kind regards, > > Bernhard > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > Users mailing list > > Users(a)lists.djigzo.com > > [http://lists.djigzo.com/lists/listinfo/users](http://lists.djigzo.com/lists/listinfo/users) ---
**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:** [January 12, 2011, 3:26pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/3 "2011-01-12T15:26:08Z")
> On incoming signed E-Mails, Djigzo puts the CN of the sender's > intermediate CA next to the "X-Djigzo-Info-Signer-ID-0-1"-header. > Shouldn't it be the CN of the sender's user certificate which is displayed? > Same thing happens with the " > X-Djigzo-Info-Encryption-Recipient-0-0"-Header in incoming encrypted > E-Mails. I can understand the misunderstanding :). S/MIME (or CMS to be exact) identifies a signing and encryption certificate using the following two methods: Issuer/Serial number or, Subject Key Identifier Subject Key Identifier is not widely used so in most cases Issuer/Serial is used. The reason behind this is that in principle the sender is not obliged to add the signing certificate to the email. These headers are adding more or less for debugging purposes. I can however understand that it would be nice to also add info about the signing certificate. If you want you can add a JIRA feature request for this. Not sure however when it will be added. > Is there a way to use the value of the FROM-header instead of the > default CN ("persona non-validated" by default) for automatically > generated certificates? > As long as outgoing emails have their source in my trusted environment, > this would make things easier without representing a security issue. The email address is added to the Subject of the generated certificate. But you also want to use the "name" part of the from? > Is it possible to use end-to-end encryption for specific users, so that > a specific user has it's own private key stored on his client and djigzo > only passes through the encrypted email? Only if the message is encrypted with a certificate for which the gateway does not have a private key. > I tried to do so. But as I don't have any CA except Djigzo's built-in > CA, i created the internal user and its certificate with the built-in > CA, exported the key to the client, deleted the user, but Djigzo still > decrypts incoming E-Mail for this user before. Is this a bug or working > as intended? See Andreas explanation (i.e., you should delete the certificate with the private key). Kind regards, Martijn Brinkers > **···** > > -- > Djigzo open source email encryption ---
**Author:** ![Bernhard\_Heinzle](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@Bernhard\_Heinzle](https://community.ciphermail.com/u/Bernhard_Heinzle)\ **Post date:** [January 12, 2011, 4:21pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/4 "2011-01-12T16:21:00Z")
> The standard mail clients i'm aware of don't display headers at all so > not sure what you are trying to achieve... of course you are right, but i'm thinking about if it makes sense to make this information (wether the email was encrypted and/or signed) accessible for end-users in a way they can unterstand it, for instance by extending the web mail software. same as a possible thunderbird-addon, which was discussed some time ago in this mailing list ([http://lists.djigzo.com/pipermail/users/2010-July/000335.html](http://lists.djigzo.com/pipermail/users/2010-July/000335.html)) > You must delete the users certificate/key after export in Djigzo. The > "user" is only a container for user specific settings and created > on-the-fly with defaults if not available. As long as Djigzo finds a > matching private key it does its work and decrypt the message. > > Regards > > Andreas as i was not quite sure anymore if i deleted the certificate/key or not i tested it once again. djigzo decrypts the message even after deleting the certificate/key. even after rebooting the gateway. kind regards bernhard > **···** > > Am 12.01.2011 16:02, schrieb lst\_hoe02(a)kwsoft.de: ---
**Author:** ![Bernhard\_Heinzle](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@Bernhard\_Heinzle](https://community.ciphermail.com/u/Bernhard_Heinzle)\ **Post date:** [January 12, 2011, 4:24pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/5 "2011-01-12T16:24:42Z")
exactly, i'd like to use the name-part of the from-header as common name. > **···** > > Am 12.01.2011 16:26, schrieb Martijn Brinkers: > > > > Is there a way to use the value of the FROM-header instead of the > > > default CN ("persona non-validated" by default) for automatically > > > generated certificates? > > > As long as outgoing emails have their source in my trusted environment, > > > this would make things easier without representing a security issue. > > > > The email address is added to the Subject of the generated certificate. > > But you also want to use the "name" part of the from? ---
**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:** [January 12, 2011, 4:32pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/6 "2011-01-12T16:32:47Z")
Zitat von Bernhard Heinzle \: > > The standard mail clients i'm aware of don't display headers at all so > > not sure what you are trying to achieve... > > of course you are right, but i'm thinking about if it makes sense to > make this information (wether the email was encrypted and/or signed) > accessible for end-users in a way they can unterstand it, for instance > by extending the web mail software. same as a possible > thunderbird-addon, which was discussed some time ago in this mailing > list ([http://lists.djigzo.com/pipermail/users/2010-July/000335.html](http://lists.djigzo.com/pipermail/users/2010-July/000335.html)) With this in mind it would be useful, yes. > > You must delete the users certificate/key after export in Djigzo. The > > "user" is only a container for user specific settings and created > > on-the-fly with defaults if not available. As long as Djigzo finds a > > matching private key it does its work and decrypt the message. > > as i was not quite sure anymore if i deleted the certificate/key or not > i tested it once again. djigzo decrypts the message even after deleting > the certificate/key. even after rebooting the gateway. Huhh? This would be magic, because without private key you can and should never be able to decrypt a message. Do you maybe have more than one key for the user (=address) in question or using the same private key in different certificates? BTW: I have seen you are using the built in CA. In most cases it is more useful to get some cheap "well-known" certificates like from www.startssl.com instead, so you don't suffer the pain to distribute your root CA certificate. The builtin CA is useful if you like to create a "island-of-trust" or a S/MIME site-to-site VPN. Regards Andreas > **···** > > > Am 12.01.2011 16:02, schrieb lst\_hoe02(a)kwsoft.de: ---
**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:** [January 12, 2011, 4:37pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/7 "2011-01-12T16:37:25Z")
> as i was not quite sure anymore if i deleted the certificate/key or not > i tested it once again. djigzo decrypts the message even after deleting > the certificate/key. even after rebooting the gateway. Are you sure you deleted all private keys? You can see with what certificates the message was encrypted with from the headers. Are you sure that the gateway does not have a copy of the signer's private key? Email clients also encrypt the message with the signing certificate to make sure you can read the message from the sent items folder. Martijn > **···** > > -- > Djigzo open source email encryption ---
**Author:** ![Bernhard\_Heinzle](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@Bernhard\_Heinzle](https://community.ciphermail.com/u/Bernhard_Heinzle)\ **Post date:** [January 12, 2011, 4:54pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/8 "2011-01-12T16:54:13Z")
recipient's private key definitely got deleted. seems as if i found the reason. as the sender's certificate was issued by the same CA as the recipient's certificate, djigzo took the sender's certificate for decrypting the message. could this be the explanation? if yes: given the situation that user a and b are internal users in djigzo, b gets deleted (user, certificate and keys), but emails send to a and b still can be read by b because djigzo uses the key of user a. is this justifiable (if the explanation mentioned above is correct)? kind regards, bernhard > **···** > > Am 12.01.2011 17:37, schrieb Martijn Brinkers: > > > > as i was not quite sure anymore if i deleted the certificate/key or not > > > i tested it once again. djigzo decrypts the message even after deleting > > > the certificate/key. even after rebooting the gateway. > > > > Are you sure you deleted all private keys? You can see with what > > certificates the message was encrypted with from the headers. Are you > > sure that the gateway does not have a copy of the signer's private key? > > Email clients also encrypt the message with the signing certificate to > > make sure you can read the message from the sent items folder. ---
**Author:** ![Bernhard\_Heinzle](https://avatars.discourse-cdn.com/v4/letter/b/71e660/32.png) [@Bernhard\_Heinzle](https://community.ciphermail.com/u/Bernhard_Heinzle)\ **Post date:** [January 12, 2011, 4:56pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/9 "2011-01-12T16:56:58Z")
> Zitat von Bernhard Heinzle \: > > > > The standard mail clients i'm aware of don't display headers at all so > > > not sure what you are trying to achieve... > > > > of course you are right, but i'm thinking about if it makes sense to > > make this information (wether the email was encrypted and/or signed) > > accessible for end-users in a way they can unterstand it, for instance > > by extending the web mail software. same as a possible > > thunderbird-addon, which was discussed some time ago in this mailing > > list ([http://lists.djigzo.com/pipermail/users/2010-July/000335.html](http://lists.djigzo.com/pipermail/users/2010-July/000335.html)) > > With this in mind it would be useful, yes. > > > > You must delete the users certificate/key after export in Djigzo. The > > > "user" is only a container for user specific settings and created > > > on-the-fly with defaults if not available. As long as Djigzo finds a > > > matching private key it does its work and decrypt the message. > > > > as i was not quite sure anymore if i deleted the certificate/key or not > > i tested it once again. djigzo decrypts the message even after deleting > > the certificate/key. even after rebooting the gateway. > > Huhh? This would be magic, because without private key you can and > should never be able to decrypt a message. Do you maybe have more than > one key for the user (=address) in question or using the same private > key in different certificates? 'magic' would be the right word 😉 it might be that i found the solution (see the reply on martjin's post) > BTW: I have seen you are using the built in CA. In most cases it is more > useful to get some cheap "well-known" certificates like from > www.startssl.com instead, so you don't suffer the pain to distribute > your root CA certificate. The builtin CA is useful if you like to create > a "island-of-trust" or a S/MIME site-to-site VPN. sure, but i'm still using djigzo in a testing environment, but thanks for the advice. > **···** > > Am 12.01.2011 17:32, schrieb lst\_hoe02(a)kwsoft.de: > > > > Am 12.01.2011 16:02, schrieb lst\_hoe02(a)kwsoft.de: ---
**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:** [January 12, 2011, 5:08pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/10 "2011-01-12T17:08:29Z")
> seems as if i found the reason. > as the sender's certificate was issued by the same CA as the recipient's > certificate, djigzo took the sender's certificate for decrypting the > message. could this be the explanation? Yes if the private key of the sender is stored on the gateway and the message was encrypted by an email client (Outlook, Thunderbird) etc. the gateway will be able to decrypt the message. The email client will also encrypt the message with the certificate of the sender to make sure the sender can open the message from the sent items folder. > if yes: > given the situation that user a and b are internal users in djigzo, b > gets deleted (user, certificate and keys), but emails send to a and b > still can be read by b because djigzo uses the key of user a. is this > justifiable (if the explanation mentioned above is correct)? Yes. Djigzo tries to decrypt the message not matter who the recipient is. It only looks with which certificate the message was encrypted with and uses the private key associated with the certificate. Djigzo also checks attached messages (message/rfc822) to see whether they are encrypted. You can for example forward two messages both encrypted with a different certificate and Djigzo will decrypt the messages (if a private key is available). Kind regards, Martijn > **···** > > -- > 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, 10:11am UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/11 "2011-02-01T10:11:24Z")
Hi, \> \> if yes: \> \> given the situation that user a and b are internal users in djigzo, \> \> b gets deleted (user, certificate and keys), but emails send to a \> \> and b still can be read by b because djigzo uses the key of user a. \> \> is this justifiable (if the explanation mentioned above is correct)? \> \> Yes. Djigzo tries to decrypt the message not matter who the recipient \> is. It only looks with which certificate the message was encrypted \> with and uses the private key associated with the certificate. \> \> Djigzo also checks attached messages (message/rfc822) to see whether \> they are encrypted. You can for example forward two messages both \> encrypted with a different certificate and Djigzo will decrypt the \> messages (if a private key is available). I think this behaviour can be used to decrypt messages in a way it was never intended to: Given the situation a colleague of mine receives an encrypted email from an external communication partner. I was able to eavesdrop the SMTP communication between the sender and our Djigzo appliance, so I possess the encrypted mail cipher. I may now send the encrypted mail to myself via our Djigzo Appliance to gain access to the content of the mail: Djigzo decrypts the mail with the key of my colleague, but delivers the mail to myself. In my opinion Djigzo should not deliver any decrypted mails to recipients their certificate was not used to encrypt the mail. Is this behaviour intended to exist? I think not even being in the same enterprise legitimises being able to decrypt confidential messages of others. 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, 10:25am UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/12 "2011-02-01T10:25:10Z")
> I think this behaviour can be used to decrypt messages in a way it > was never intended to: Given the situation a colleague of mine > receives an encrypted email from an external communication partner. I > was able to eavesdrop the SMTP communication between the sender and > our Djigzo appliance, so I possess the encrypted mail cipher. I may > now send the encrypted mail to myself via our Djigzo Appliance to > gain access to the content of the mail: Djigzo decrypts the mail with > the key of my colleague, but delivers the mail to myself. "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. > In my opinion Djigzo should not deliver any decrypted mails to > recipients their certificate was not used to encrypt the mail. > Is this behaviour intended to exist? I think not even being in the > same enterprise legitimises being able to decrypt confidential > messages of 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. Kind regards, Martijn Brinkers > **···** > > -- > Djigzo open source email encryption ---
**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, 10:40am UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/13 "2011-02-01T10:40:57Z")
I can see whether I can make it optional (default off) to add checks to make sure the email is only delivered in decrypted form if the email address matches the certificate used for decryption. There are a couple of problems that need to be solved. \*\* Start of technical stuff you can skip if you are not interested \*\* A message can have multiple recipients so the message should be split if encrypted into multiple recipients. It's also unclear how to handle domain encryption. Domain encryption is used by companies to setup a secure S/MIME tunnel. It currently is not clear whether the certificate was intended as a domain certificate so if additional checks are required to make sure only the intended recipients can read the message the receiving gateway should know whether the certificate is a domain certificate. Another option would be to completely disable domain encryption if the additional checks are enabled because you probably don't want domain encryption in that case. Kind regards, Martijn > **···** > > On 02/01/2011 11:11 AM, Manuel Faux wrote: > > > Is this behaviour intended to exist? I think not even being in the same > > enterprise legitimises being able to decrypt confidential messages of > > others. > > -- > 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:36am UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/14 "2011-02-01T11:36:40Z")
> "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? > 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 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. Kind Regards, Manuel Faux ---
**Author:** ![Christine](https://avatars.discourse-cdn.com/v4/letter/c/8491ac/32.png) [@Christine](https://community.ciphermail.com/u/Christine)\ **Post date:** [February 1, 2011, 11:48am UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/15 "2011-02-01T11:48:33Z")
> I think a gateway solution should not weaken the security of a > desktop-to-desktop scenario, in situations it is not necessary in. The reason to use a gateway is that most users find it too hard to use email encryption properly. If your end users will not use encryption, then it's better to have gateway to gateway encryption than no encryption at all. If you're willing to force your user to use desktop encryption, then you don't need a gateway for encryption. The use of a gateway would be limited to issuing certificates and certificate management and such. dagdag Christine > **···** > > On 02/01/2011 12:36 PM, Manuel Faux wrote: > > >   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 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. > > > > Kind Regards, > > > > Manuel Faux > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > Users mailing list > > Users(a)lists.djigzo.com > > [http://lists.djigzo.com/lists/listinfo/users](http://lists.djigzo.com/lists/listinfo/users) > > -- > dagdag is just a two-character rotation of byebye. ---
**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, 1:45pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/16 "2011-02-01T13:45:56Z")
I was just thinking of the following situation which actually happens in my case. I still use a very old email address I have already for a long time (m.brinkers(a)pobox.com). Pobox is only a forwarding service so email sent to my Pobox account is forwarded to my Djigzo email address. When someone sends encrypted email to my Pobox account using an email client it will be encrypted with the certificate for the Pobox email address. The email however will be forwarded to my Djigzo address. The gateway can decrypt the message because the gateway contains the private key of the Pobox account. When strict mode will be enabled, the gateway will refuse to decrypt the message because there will be a mismatch between recipient email address and certificate email address. Whether or not this is a good think (not in my case) it of course up to the gateway admin. Kind regards, Martijn Brinkers > **···** > > On 02/01/2011 12:36 PM, Manuel Faux wrote: > > > > "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? > > -- > Djigzo open source email encryption ---
**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, 3:02pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/17 "2011-02-01T15:02:28Z")
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? > > I was just thinking of the following situation which actually happens in > my case. I still use a very old email address I have already for a long > time (m.brinkers(a)pobox.com). Pobox is only a forwarding service so email > sent to my Pobox account is forwarded to my Djigzo email address. When > someone sends encrypted email to my Pobox account using an email client > it will be encrypted with the certificate for the Pobox email address. > The email however will be forwarded to my Djigzo address. The gateway > can decrypt the message because the gateway contains the private key of > the Pobox account. When strict mode will be enabled, the gateway will > refuse to decrypt the message because there will be a mismatch between > recipient email address and certificate email address. Whether or not > this is a good think (not in my case) it of course up to the gateway admin. I would suggest the following: - For "non-domain-encryption" eg. automatic private-key selection only use a key if the recipient address also matches - If one would like settings like above or domain-encryption it is necessaey to manual select the keys considered by Djigzo for decryption and asign it to the user (address) or domain (domain-encryption) In any case incoming encrypted mail should be split to single recipient to simplify the handling and allow a mix of both. The percentage of encrypted mail which has also multiple recipients should be low enough to not bother with the additional overhead. Regards Andreas > **···** > > > On 02/01/2011 12:36 PM, 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, 4:11pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/18 "2011-02-01T16:11:03Z")
> > I was just thinking of the following situation which actually happens in > > my case. I still use a very old email address I have already for a long > > time (m.brinkers(a)pobox.com). Pobox is only a forwarding service so email > > sent to my Pobox account is forwarded to my Djigzo email address. When > > someone sends encrypted email to my Pobox account using an email client > > it will be encrypted with the certificate for the Pobox email address. > > The email however will be forwarded to my Djigzo address. The gateway > > can decrypt the message because the gateway contains the private key of > > the Pobox account. When strict mode will be enabled, the gateway will > > refuse to decrypt the message because there will be a mismatch between > > recipient email address and certificate email address. Whether or not > > this is a good think (not in my case) it of course up to the gateway > > admin. > > I would suggest the following: > - For "non-domain-encryption" eg. automatic private-key selection only > use a key if the recipient address also matches > - If one would like settings like above or domain-encryption it is > necessaey to manual select the keys considered by Djigzo for decryption > and asign it to the user (address) or domain (domain-encryption) Yes agree. So the above settings will be used in the "strict mode". > In any case incoming encrypted mail should be split to single recipient > to simplify the handling and allow a mix of both. The percentage of > encrypted mail which has also multiple recipients should be low enough > to not bother with the additional overhead. Yes splitting the mail into multiple emails might be the easiest approach. However this also makes the gateway vulnerable to a DOS attack. Suppose someone sends an encrypted message to 1000 recipients. If the message is split up, it will explode into 1000 messages which need to be handled/decrypted individually. In real life situations an encrypted email can have a lot of recipients when domain encryption is used (for example when a mailing is sent to multiple recipients). I'm therefore thinking to split the message in two (only in strict mode) if needed. If there is no decryption certificate for one or more users, split the message into a message that will be decrypted and into a message that won't be encrypted. This way you only require two messages no matter how many recipients there are. I think I don't have to decrypt the complete message. I only need to decrypt the encrypted session keys to see whether there is a valid certificate for the recipient. Kind regards, Martijn > **···** > > -- > Djigzo open source email encryption ---
**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, 5:19pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/19 "2011-02-01T17:19:15Z")
Zitat von Martijn Brinkers \: > > > I was just thinking of the following situation which actually happens in > > > my case. I still use a very old email address I have already for a long > > > time (m.brinkers(a)pobox.com). Pobox is only a forwarding service so email > > > sent to my Pobox account is forwarded to my Djigzo email address. When > > > someone sends encrypted email to my Pobox account using an email client > > > it will be encrypted with the certificate for the Pobox email address. > > > The email however will be forwarded to my Djigzo address. The gateway > > > can decrypt the message because the gateway contains the private key of > > > the Pobox account. When strict mode will be enabled, the gateway will > > > refuse to decrypt the message because there will be a mismatch between > > > recipient email address and certificate email address. Whether or not > > > this is a good think (not in my case) it of course up to the gateway > > > admin. > > > > I would suggest the following: > > - For "non-domain-encryption" eg. automatic private-key selection only > > use a key if the recipient address also matches > > - If one would like settings like above or domain-encryption it is > > necessaey to manual select the keys considered by Djigzo for decryption > > and asign it to the user (address) or domain (domain-encryption) > > Yes agree. So the above settings will be used in the "strict mode". > > > In any case incoming encrypted mail should be split to single recipient > > to simplify the handling and allow a mix of both. The percentage of > > encrypted mail which has also multiple recipients should be low enough > > to not bother with the additional overhead. > > Yes splitting the mail into multiple emails might be the easiest > approach. However this also makes the gateway vulnerable to a DOS > attack. Suppose someone sends an encrypted message to 1000 recipients. > If the message is split up, it will explode into 1000 messages which > need to be handled/decrypted individually. In real life situations an > encrypted email can have a lot of recipients when domain encryption is > used (for example when a mailing is sent to multiple recipients). > I'm therefore thinking to split the message in two (only in strict mode) > if needed. If there is no decryption certificate for one or more users, > split the message into a message that will be decrypted and into a > message that won't be encrypted. This way you only require two messages > no matter how many recipients there are. I think I don't have to decrypt > the complete message. I only need to decrypt the encrypted session keys > to see whether there is a valid certificate for the recipient. This is the same problem any MTA will have. Postfix by default limit the number of recipients per mail to 100... What i don't found out yet is if the domain-encryption feature can be set on the receiver side or if it is only triggered by the sender, using one of the recipients valid certificates to encrypt mail for many different recipients. So is it a sender or a recipient "policy". I would for sure like to control on my end (receiver) if i like cross-usage of certificates/keys, but it looks like all is needed is a sender able split certificate usage from recipient address?? In case i got it right the answer will be yes, we need a switch to turn off this behaviour and splitting the messages in a part with valid recipient\<--\>certificate pairs and a part without, which will not be decrypted will be a way to go. Regards Andreas ---
**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, 5:28pm UTC](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155/20 "2011-02-01T17:28:30Z")
Currently the domain certificate is only used for encrypting. For decryption the gateway works like any email client i.e, decrypt when possible. So what I'm thinking of is to add "strict mode", In "strict mode" a recipient will only receive the message decrypted if one of the following is true: 1. the message is encrypted with a certificate with private key containing an email address that matches the email address of the recipient. or, 2. the message is encrypted with a certificate with private key that was manually selected for the recipient or, 3. the message is encrypted with a certificate with private key that was manually selected for the domain of the recipient On non-strict mode the gateway behaves like it does not i.e, decrypt when possible. Am I missing something? Kind regards, Martijn > **···** > > On 01/-10/-28163 08:59 PM, lst\_hoe02(a)kwsoft.de wrote: > > > This is the same problem any MTA will have. Postfix by default limit the > > number of recipients per mail to 100... > > What i don't found out yet is if the domain-encryption feature can be > > set on the receiver side or if it is only triggered by the sender, using > > one of the recipients valid certificates to encrypt mail for many > > different recipients. > > So is it a sender or a recipient "policy". I would for sure like to > > control on my end (receiver) if i like cross-usage of certificates/keys, > > but it looks like all is needed is a sender able split certificate usage > > from recipient address?? > > In case i got it right the answer will be yes, we need a switch to turn > > off this behaviour and splitting the messages in a part with valid > > recipient\<--\>certificate pairs and a part without, which will not be > > decrypted will be a way to go. > > -- > Djigzo open source email encryption [Next page](https://community.ciphermail.com/t/header-information-ca-settings-and-end-to-end-encryption/155.md?page=2)