31 Oct
2011
31 Oct
'11
6:31 p.m.
Hello,
let' s think of the following scenario:
Our client has 5 employees and uses Djigzo
E1, E2, E3, E4, E5
His business contact hat 5 employess, too, but doesn't use an encryption gateway
(encryption is performed by the email client) :
e1, e2, e3, e4, 5
E1 exchanges emails with e1, e3, e5
E2 exchanges emails with e1, e2, e3
E3 echanges emails with e2,e3,e5
and so on.
Is it really necessary, that the IT admin on the other side runs around and distributes
all required user certificates?
Or is it possible to have a wildcard domain certificate, which only has to be installed
once? The web interface accepts "*(a)abc.com" as an "email address".
The problem in our real world scenario is, that our client has 250 employees and the other
side is a governmental organization with some 3000+ employees.
Therefore, running around and distributing certifocates would only be an option for
marathon runners. ;-))
Thanks for any suggestions,
Stefan
31 Oct
31 Oct
8:22 p.m.
Zitat von Stefan Michael Guenther <s.guenther(a)in-put.de>de>:
Hello,
let' s think of the following scenario:
Our client has 5 employees and uses Djigzo
E1, E2, E3, E4, E5
His business contact hat 5 employess, too, but doesn't use an
encryption gateway (encryption is performed by the email client) :
e1, e2, e3, e4, 5
E1 exchanges emails with e1, e3, e5
E2 exchanges emails with e1, e2, e3
E3 echanges emails with e2,e3,e5
and so on.
Is it really necessary, that the IT admin on the other side runs
around and distributes all required user certificates?
Or is it possible to have a wildcard domain certificate, which only
has to be installed once? The web interface accepts "*(a)abc.com" as
an "email address".
The problem in our real world scenario is, that our client has 250
employees and the other side is a governmental organization with
some 3000+ employees.
Therefore, running around and distributing certifocates would only
be an option for marathon runners. ;-))
While there are wildcard or domain certificates available and Djigzo
can handle them fine you are in trouble when using this certificates
with non-Gatewayed Clients, because as far as i know every Mailclient
check the e-mail address listed in the certificate against the
mail-from header. Wildcard certificates are really useful if
negotiated with the remote side also using a gateway, but otherwise
the recipients will get warnings about non matching addresses.
What might be a solution is to sign all outgoing mail so the
recipients get the certificates automatically. But if you want
encryption the remote mail clients must also have their own
certificate/private-key to encrypt the local copy of the mail.
Regards
Andreas
8:53 p.m.
On 10/31/2011 07:31 PM, Stefan Michael Guenther wrote:
Hello,
let' s think of the following scenario:
Our client has 5 employees and uses Djigzo
E1, E2, E3, E4, E5
His business contact hat 5 employess, too, but doesn't use an encryption gateway
(encryption is performed by the email client) :
e1, e2, e3, e4, 5
E1 exchanges emails with e1, e3, e5
E2 exchanges emails with e1, e2, e3
E3 echanges emails with e2,e3,e5
and so on.
Is it really necessary, that the IT admin on the other side runs around and distributes
all required user certificates?
Or is it possible to have a wildcard domain certificate, which only has to be installed
once? The web interface accepts "*(a)abc.com" as an "email address".
The problem in our real world scenario is, that our client has 250 employees and the
other side is a governmental organization with some 3000+ employees.
Therefore, running around and distributing certifocates would only be an option for
marathon runners. ;-))
The recipients can in principle use just one certificate to decrypt
incoming email. Most (if not all) S/MIME email clients will use any
available certificate (with private key) to decrypt the message with.
So, from Djigzo gateway -> recipient(s) this would work since with the
Djigzo gateway you can select a certificate for a particular domain. All
email sent to that domain will then be encrypted with that particular
domain certificate.
Although the recipient can decrypt the message, with most S/MIME email
clients the recipient cannot however reply encrypted. Outlook for
example refuses to use a certificate with a non-matching email address
(although I haven't tried a wildcard address). So, if the recipient need
to reply, the recipient need it's own valid and trusted certificate with
matching email address. This is a shortcoming of the email clients in my
opinion. S/MIME encryption would have been a lot easier if the email
clients would allow more manual overrides.
About distributing certificates, there are ways to make it somewhat
easier to distribute a lot of client certificates. However, if a lot of
client certificates are required, it might be *a lot* easier for them to
install a gateway as well (unless client side encryption is a requirement).
Kind regards,
Martijn
--
Djigzo open source email encryption
1 Nov
1 Nov
9:07 a.m.
Zitat von Martijn Brinkers <martijn(a)djigzo.com>om>:
On 10/31/2011 07:31 PM, Stefan Michael Guenther
wrote:
But this will require to install this particular certificate on any
recipient mail client, no?
Hello,
let' s think of the following scenario:
Our client has 5 employees and uses Djigzo
E1, E2, E3, E4, E5
His business contact hat 5 employess, too, but doesn't use an
encryption gateway (encryption is performed by the email client) :
e1, e2, e3, e4, 5
E1 exchanges emails with e1, e3, e5
E2 exchanges emails with e1, e2, e3
E3 echanges emails with e2,e3,e5
and so on.
Is it really necessary, that the IT admin on the other side runs
around and distributes all required user certificates?
Or is it possible to have a wildcard domain certificate, which only
has to be installed once? The web interface accepts "*(a)abc.com" as
an "email address".
The problem in our real world scenario is, that our client has 250
employees and the other side is a governmental organization with
some 3000+ employees.
Therefore, running around and distributing certifocates would only
be an option for marathon runners. ;-))
The recipients can in principle use just one certificate to decrypt
incoming email. Most (if not all) S/MIME email clients will use any
available certificate (with private key) to decrypt the message with.
So, from Djigzo gateway -> recipient(s) this would work since with the
Djigzo gateway you can select a certificate for a particular domain. All
email sent to that domain will then be encrypted with that particular
domain certificate. Although the recipient can decrypt the message, with
most S/MIME email
clients the recipient cannot however reply encrypted. Outlook for
example refuses to use a certificate with a non-matching email address
(although I haven't tried a wildcard address). So, if the recipient need
to reply, the recipient need it's own valid and trusted certificate with
matching email address. This is a shortcoming of the email clients in my
opinion. S/MIME encryption would have been a lot easier if the email
clients would allow more manual overrides.
That is the problem indeed. Mail clients rely to a big extend on
matching mail addresses, so this would not work well. Even if it would
be configurable, it does not make a big difference to configure
"something" on all clients versus to install a matchnig
certificate/key on every client.
After all that's why the S/MIME Gateways were invented ;-)
About distributing certificates, there are ways to
make it somewhat
easier to distribute a lot of client certificates. However, if a lot of
client certificates are required, it might be *a lot* easier for them to
install a gateway as well (unless client side encryption is a requirement).
That said if the recipient are a german governmental organization they
nearly for sure have a S/MIME Gateway, you only have to convince them
to use it.
Regards
Andreas
1:18 p.m.
Hi,
thanks you for your answers, which were exactly what I had expected.
Well, let's see how this project goes on.
Stefan
3685
days inactive
3686
days old
4 comments
3 participants
participants (3)
-
lst_hoe02＠kwsoft.de -
Martijn Brinkers -
Stefan Michael Guenther