"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?
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.
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
"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.
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:
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.
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.
but in most cases this is