Hi Dan,
Dan Banach wrote:
Sorry it's taken some time to respond. We deal with a wide range of
email recipients (large companies, small offices, individuals, etc.)
with a wide range of email encryption knowledge, so the ideal encryption
solution for us would be very flexible. Not only flexible for outgoing
mail, but also incoming mail as well. Some users/business' use PGP,
others use certs and some use the various other options. Being able to
communicate with them all is very helpful.
Right now now I'm working on Blackberry S/MIME support for BIS users
(for BES users there is already S/MIME email). Once that is finished I
will start working on new major features. There are some features I
would like to start working on but I'm not sure which one that should be.
Two main new features I was thinking about are:
1. PGP support
2. Client-less email encryption
Nr 1 is clear. I will briefly explain nr 2.
Client-less
Currently Djigzo supports S/MIME and PDF encryption. Recipients that do
not want are cannot receive S/MIME or encrypted PDFs are currently not
supported. The new encryption functionality I would like to add is the
following:
If an email sent to an external recipient needs to be encrypted and the
recipient cannot receive S/MIME email of an encrypted PDF the email will
be converted to a .html file. The original plain-text message (and
attachments) will be encrypted with a certificate for the external
recipient and added to the .html. The .html will be added to a general
message (which does not contain any sensitive information) and sent to
the recipient. The recipient opens the .html message in the email client
(can for example be hotmail). The .html will open a SSL connection to
the companies Djigzo server (which can be a dedicated server just for
the portal). The Djigzo server will show a login page. The recipient now
has to login. After the login the recipients browser will push the
encrypted 'blob' (contained in the HTML) to the portal. The portal will
decrypt the message with the private key of the recipient (which is
stored on the companies Djigzo server). The recipient can now read the
message and download any attachments (the portal uses SSL for secure
access).
The main advantage is that the recipient only requires a browser. The
encrypted data is stored locally on the recipients system (there is no
long term copy on the Djigzo server). An attacker needs access to the
locally stored .html file AND the portal password to read the message.
The message is encrypted with the same algorithm as a S/MIME message.
The only difference is that it's encoded inside a .html file.
A disadvantage is that the Djigzo server needs to be accessible to
external recipients.
Right now I'm leaning towards implementing feature 2 but it could be
that you or any other Djigzo user has another preference or request for
a feature. If so I'm all ears 
I
think another great feature you could include would be to grant internal
users the ability to manage their own decryption profiles. They should
be able to add/create there own certs/keys and create their own
passwords. Ideally it is tied into the directory via ldap or something
so authentication and user information is seamless.
One problem is that currently the settings for an external user are
shared by all internal users. So, if internal user A changes settings
for external user E internal user B will also be affected. Do you want
the user list to be different for each internal user?
Right now you can add admins with different roles. You can add an admin
that can add keys etc. but not change the MTA settings,
Kind regards,
Martijn
Hi Martijn,
I have been playing with Djigzo for a couple of months now and I think
it is fantastic...so let me start by saying thanks for your hard work on
it and for releasing it to the open-source community.
If you are looking for votes (!), I think #2 below is a real winner. I
have been evaluating Djigzo in comparison to Cisco's Ironport for a
number of encryption requirements. While the "gateway-to-gateway"
S/MIME capabilities of Djigzo are ideal, I also have a requirement for
clientless support which Ironport's PXE does very nicely (but at a steep
price). There appear to be a few other products out there covering the
same ground (the ZixDirect at www.zixcorp.com and Trend Micro Private
Post from Trend Micro, to pick two examples). The PDF encryption in
Djigzo doesn't meet the requirements because to achieve an adequate key
length would require typing in a password so long that users would never
find it acceptable. I considered modifying your code to lengthen the
PDF encryption password and increase the "alphabet" from which password
characters were drawn but dropped the idea when I worked out how long
the password would need to be to achieve even 128-bit key strength. I
would therefore be delighted to see Djigzo offer the kind of clientless
capability you outline.
If I may venture a suggestion, I would have a slight concern about the
idea that the encrypted blob is pushed up to the server where the
decryption key is stored for decryption. I would suggest that it is not
ideal to have the decryption key and the encrypted content both on this
server. I know Cisco's Ironport works slightly differently. The user
receives the message in a HTML wrapper similar to what you describe
below. When he logs onto the server, a script in his browser downloads
the decryption key which is then used to decrypt the blob locally on the
user's PC (done by a bunch of Javascript code which comes down with the
HTML wrapper). This approach has the advantage that the message content
is never actually stored on the key server...only the decryption key
(which is pretty useless without the message content). I guess the
obvious counter-argument is that the message is encrypted on this server
in the first instance so uploading it again for decryption isn't a
dramatic dilution of the security (once the encrypted message content
isn't actually stored on the same server as the decryption keys).
Best Wishes,
Eamonn
Martijn Brinkers wrote:
···
Hi Dan,
Dan Banach wrote:
Sorry it's taken some time to respond. We deal with a wide range of
email recipients (large companies, small offices, individuals, etc.)
with a wide range of email encryption knowledge, so the ideal encryption
solution for us would be very flexible. Not only flexible for outgoing
mail, but also incoming mail as well. Some users/business' use PGP,
others use certs and some use the various other options. Being able to
communicate with them all is very helpful.
Right now now I'm working on Blackberry S/MIME support for BIS users
(for BES users there is already S/MIME email). Once that is finished I
will start working on new major features. There are some features I
would like to start working on but I'm not sure which one that should be.
Two main new features I was thinking about are:
1. PGP support
2. Client-less email encryption
Nr 1 is clear. I will briefly explain nr 2.
Client-less
Currently Djigzo supports S/MIME and PDF encryption. Recipients that do
not want are cannot receive S/MIME or encrypted PDFs are currently not
supported. The new encryption functionality I would like to add is the
following:
If an email sent to an external recipient needs to be encrypted and the
recipient cannot receive S/MIME email of an encrypted PDF the email will
be converted to a .html file. The original plain-text message (and
attachments) will be encrypted with a certificate for the external
recipient and added to the .html. The .html will be added to a general
message (which does not contain any sensitive information) and sent to
the recipient. The recipient opens the .html message in the email client
(can for example be hotmail). The .html will open a SSL connection to
the companies Djigzo server (which can be a dedicated server just for
the portal). The Djigzo server will show a login page. The recipient now
has to login. After the login the recipients browser will push the
encrypted 'blob' (contained in the HTML) to the portal. The portal will
decrypt the message with the private key of the recipient (which is
stored on the companies Djigzo server). The recipient can now read the
message and download any attachments (the portal uses SSL for secure
access).
The main advantage is that the recipient only requires a browser. The
encrypted data is stored locally on the recipients system (there is no
long term copy on the Djigzo server). An attacker needs access to the
locally stored .html file AND the portal password to read the message.
The message is encrypted with the same algorithm as a S/MIME message.
The only difference is that it's encoded inside a .html file.
A disadvantage is that the Djigzo server needs to be accessible to
external recipients.
Right now I'm leaning towards implementing feature 2 but it could be
that you or any other Djigzo user has another preference or request for
a feature. If so I'm all ears
I
think another great feature you could include would be to grant internal
users the ability to manage their own decryption profiles. They should
be able to add/create there own certs/keys and create their own
passwords. Ideally it is tied into the directory via ldap or something
so authentication and user information is seamless.
One problem is that currently the settings for an external user are
shared by all internal users. So, if internal user A changes settings
for external user E internal user B will also be affected. Do you want
the user list to be different for each internal user?
Right now you can add admins with different roles. You can add an admin
that can add keys etc. but not change the MTA settings,
Kind regards,
Martijn
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users
Hi Eamonn,
Gooed to hear from you
You seem to have quite some experience with email encryption which is
nice :). I know most of these products just from what I could find on
the Internet. Unfortunately I do not have any hands-on experience with
most of these products so it's nice to get your feedback on these
products. It's funny that you mention Ironmail. When it was still called
PostX (which was bought by Ironport) I did some product development for
them (specifically I created their Outlook and Lotus Notes plugins) so I
have some experience with Ironmail products. I have been thinking of
creating a .html envelope with a Javascript decryption engine.
Decrypting a message body is possible but I do not see how you can
extracting and writing attachments by using only Javascript. So for
attachments you have to use Flash, Java, ActiveX or “push” the
attachments to an external server because Javascript does not allow you
to write files to your local system. I'm not sure how Ironmail solves
this but I guess they use one of these technologies for writing the
attachments. Replying to the encrypted message with any client-less
solution requires you to open a portal page as well on which you have to
reply.
The question now is whether you can reliably extract attachments from
the .html file and store them locally. I think that most corporate users
are not allowed to run any .html that can write to the local file
system. Most corporate clients therefore need to open a portal to get
the attachments from the .html. So the main question now is whether it's
worth the trouble to do everything locally when it's not 100% reliable?
Do you know if and how others extract the attachments locally?
Kind regards,
Martijn Brinkers
Eamonn McGonigle wrote:
···
Hi Martijn,
I have been playing with Djigzo for a couple of months now and I think
it is fantastic...so let me start by saying thanks for your hard work on
it and for releasing it to the open-source community.
If you are looking for votes (!), I think #2 below is a real winner. I
have been evaluating Djigzo in comparison to Cisco's Ironport for a
number of encryption requirements. While the "gateway-to-gateway"
S/MIME capabilities of Djigzo are ideal, I also have a requirement for
clientless support which Ironport's PXE does very nicely (but at a steep
price). There appear to be a few other products out there covering the
same ground (the ZixDirect at www.zixcorp.com and Trend Micro Private
Post from Trend Micro, to pick two examples). The PDF encryption in
Djigzo doesn't meet the requirements because to achieve an adequate key
length would require typing in a password so long that users would never
find it acceptable. I considered modifying your code to lengthen the
PDF encryption password and increase the "alphabet" from which password
characters were drawn but dropped the idea when I worked out how long
the password would need to be to achieve even 128-bit key strength. I
would therefore be delighted to see Djigzo offer the kind of clientless
capability you outline.
If I may venture a suggestion, I would have a slight concern about the
idea that the encrypted blob is pushed up to the server where the
decryption key is stored for decryption. I would suggest that it is not
ideal to have the decryption key and the encrypted content both on this
server. I know Cisco's Ironport works slightly differently. The user
receives the message in a HTML wrapper similar to what you describe
below. When he logs onto the server, a script in his browser downloads
the decryption key which is then used to decrypt the blob locally on the
user's PC (done by a bunch of Javascript code which comes down with the
HTML wrapper). This approach has the advantage that the message content
is never actually stored on the key server...only the decryption key
(which is pretty useless without the message content). I guess the
obvious counter-argument is that the message is encrypted on this server
in the first instance so uploading it again for decryption isn't a
dramatic dilution of the security (once the encrypted message content
isn't actually stored on the same server as the decryption keys).
Best Wishes,
Eamonn
Martijn Brinkers wrote:
Hi Dan,
Dan Banach wrote:
Sorry it's taken some time to respond. We deal with a wide range of
email recipients (large companies, small offices, individuals, etc.)
with a wide range of email encryption knowledge, so the ideal encryption
solution for us would be very flexible. Not only flexible for outgoing
mail, but also incoming mail as well. Some users/business' use PGP,
others use certs and some use the various other options. Being able to
communicate with them all is very helpful.
Right now now I'm working on Blackberry S/MIME support for BIS users
(for BES users there is already S/MIME email). Once that is finished I
will start working on new major features. There are some features I
would like to start working on but I'm not sure which one that should be.
Two main new features I was thinking about are:
1. PGP support
2. Client-less email encryption
Nr 1 is clear. I will briefly explain nr 2.
Client-less
Currently Djigzo supports S/MIME and PDF encryption. Recipients that do
not want are cannot receive S/MIME or encrypted PDFs are currently not
supported. The new encryption functionality I would like to add is the
following:
If an email sent to an external recipient needs to be encrypted and the
recipient cannot receive S/MIME email of an encrypted PDF the email will
be converted to a .html file. The original plain-text message (and
attachments) will be encrypted with a certificate for the external
recipient and added to the .html. The .html will be added to a general
message (which does not contain any sensitive information) and sent to
the recipient. The recipient opens the .html message in the email client
(can for example be hotmail). The .html will open a SSL connection to
the companies Djigzo server (which can be a dedicated server just for
the portal). The Djigzo server will show a login page. The recipient now
has to login. After the login the recipients browser will push the
encrypted 'blob' (contained in the HTML) to the portal. The portal will
decrypt the message with the private key of the recipient (which is
stored on the companies Djigzo server). The recipient can now read the
message and download any attachments (the portal uses SSL for secure
access).
The main advantage is that the recipient only requires a browser. The
encrypted data is stored locally on the recipients system (there is no
long term copy on the Djigzo server). An attacker needs access to the
locally stored .html file AND the portal password to read the message.
The message is encrypted with the same algorithm as a S/MIME message.
The only difference is that it's encoded inside a .html file.
A disadvantage is that the Djigzo server needs to be accessible to
external recipients.
Right now I'm leaning towards implementing feature 2 but it could be
that you or any other Djigzo user has another preference or request for
a feature. If so I'm all ears
I
think another great feature you could include would be to grant internal
users the ability to manage their own decryption profiles. They should
be able to add/create there own certs/keys and create their own
passwords. Ideally it is tied into the directory via ldap or something
so authentication and user information is seamless.
One problem is that currently the settings for an external user are
shared by all internal users. So, if internal user A changes settings
for external user E internal user B will also be affected. Do you want
the user list to be different for each internal user?
Right now you can add admins with different roles. You can add an admin
that can add keys etc. but not change the MTA settings,
Kind regards,
Martijn
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users
--
Djigzo open source email encryption
Hi Eamonn,
I forgot to comment on the PDF password length.
You are right in that the PDF encryption is less secure because the
password has to be long enough to withstand an off-line brute-force
attack. The length of the generated password can be set under the
advanced settings. The longer the better but less user friendly. The
generated password is encoded using base32 (A-Z and six digits 2-7) .
The main advantage is that it's easier to read for humans and therefore
less error prone (the 1 is not used so it cannot be misread as the
letter l).
If you require 128-bits of a random you have to set the password length
to 16 (16*8=128) so that's a long password to type.
If your security requirements need 128-bits security it's better to use
something like S/MIME.
Kind regards,
Martijn Brinkers
Eamonn McGonigle wrote:
···
Hi Martijn,
I have been playing with Djigzo for a couple of months now and I think
it is fantastic...so let me start by saying thanks for your hard work on
it and for releasing it to the open-source community.
If you are looking for votes (!), I think #2 below is a real winner. I
have been evaluating Djigzo in comparison to Cisco's Ironport for a
number of encryption requirements. While the "gateway-to-gateway"
S/MIME capabilities of Djigzo are ideal, I also have a requirement for
clientless support which Ironport's PXE does very nicely (but at a steep
price). There appear to be a few other products out there covering the
same ground (the ZixDirect at www.zixcorp.com and Trend Micro Private
Post from Trend Micro, to pick two examples). The PDF encryption in
Djigzo doesn't meet the requirements because to achieve an adequate key
length would require typing in a password so long that users would never
find it acceptable. I considered modifying your code to lengthen the
PDF encryption password and increase the "alphabet" from which password
characters were drawn but dropped the idea when I worked out how long
the password would need to be to achieve even 128-bit key strength. I
would therefore be delighted to see Djigzo offer the kind of clientless
capability you outline.
If I may venture a suggestion, I would have a slight concern about the
idea that the encrypted blob is pushed up to the server where the
decryption key is stored for decryption. I would suggest that it is not
ideal to have the decryption key and the encrypted content both on this
server. I know Cisco's Ironport works slightly differently. The user
receives the message in a HTML wrapper similar to what you describe
below. When he logs onto the server, a script in his browser downloads
the decryption key which is then used to decrypt the blob locally on the
user's PC (done by a bunch of Javascript code which comes down with the
HTML wrapper). This approach has the advantage that the message content
is never actually stored on the key server...only the decryption key
(which is pretty useless without the message content). I guess the
obvious counter-argument is that the message is encrypted on this server
in the first instance so uploading it again for decryption isn't a
dramatic dilution of the security (once the encrypted message content
isn't actually stored on the same server as the decryption keys).
Best Wishes,
Eamonn
Martijn Brinkers wrote:
Hi Dan,
Dan Banach wrote:
Sorry it's taken some time to respond. We deal with a wide range of
email recipients (large companies, small offices, individuals, etc.)
with a wide range of email encryption knowledge, so the ideal encryption
solution for us would be very flexible. Not only flexible for outgoing
mail, but also incoming mail as well. Some users/business' use PGP,
others use certs and some use the various other options. Being able to
communicate with them all is very helpful.
Right now now I'm working on Blackberry S/MIME support for BIS users
(for BES users there is already S/MIME email). Once that is finished I
will start working on new major features. There are some features I
would like to start working on but I'm not sure which one that should be.
Two main new features I was thinking about are:
1. PGP support
2. Client-less email encryption
Nr 1 is clear. I will briefly explain nr 2.
Client-less
Currently Djigzo supports S/MIME and PDF encryption. Recipients that do
not want are cannot receive S/MIME or encrypted PDFs are currently not
supported. The new encryption functionality I would like to add is the
following:
If an email sent to an external recipient needs to be encrypted and the
recipient cannot receive S/MIME email of an encrypted PDF the email will
be converted to a .html file. The original plain-text message (and
attachments) will be encrypted with a certificate for the external
recipient and added to the .html. The .html will be added to a general
message (which does not contain any sensitive information) and sent to
the recipient. The recipient opens the .html message in the email client
(can for example be hotmail). The .html will open a SSL connection to
the companies Djigzo server (which can be a dedicated server just for
the portal). The Djigzo server will show a login page. The recipient now
has to login. After the login the recipients browser will push the
encrypted 'blob' (contained in the HTML) to the portal. The portal will
decrypt the message with the private key of the recipient (which is
stored on the companies Djigzo server). The recipient can now read the
message and download any attachments (the portal uses SSL for secure
access).
The main advantage is that the recipient only requires a browser. The
encrypted data is stored locally on the recipients system (there is no
long term copy on the Djigzo server). An attacker needs access to the
locally stored .html file AND the portal password to read the message.
The message is encrypted with the same algorithm as a S/MIME message.
The only difference is that it's encoded inside a .html file.
A disadvantage is that the Djigzo server needs to be accessible to
external recipients.
Right now I'm leaning towards implementing feature 2 but it could be
that you or any other Djigzo user has another preference or request for
a feature. If so I'm all ears
I
think another great feature you could include would be to grant internal
users the ability to manage their own decryption profiles. They should
be able to add/create there own certs/keys and create their own
passwords. Ideally it is tied into the directory via ldap or something
so authentication and user information is seamless.
One problem is that currently the settings for an external user are
shared by all internal users. So, if internal user A changes settings
for external user E internal user B will also be affected. Do you want
the user list to be different for each internal user?
Right now you can add admins with different roles. You can add an admin
that can add keys etc. but not change the MTA settings,
Kind regards,
Martijn
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users
--
Djigzo open source email encryption
This brings up an interesting topic of discussion. Is the IBE method
used by IronPort and others any more secure than the PDF encryption? I
personally don't think IBE offers the same level of security as true
128-bit encryption because public/known info (email address, etc.) acts
as part of the key negotiation, once one has the encrypted payload and
this known info you have most of the puzzle. Personally, I think PDF
with a strong password is on the same level as the IBE based products.
Just my $.02, I'd be curious what others thought.
Thanks,
Dan
···
-----Original Message-----
From: users-bounces(a)lists.djigzo.com
[mailto:users-bounces(a)lists.djigzo.com] On Behalf Of Martijn Brinkers
Sent: Wednesday, June 17, 2009 3:43 PM
To: Eamonn McGonigle
Cc: Users(a)lists.djigzo.com
Subject: Re: Customer experience
Hi Eamonn,
I forgot to comment on the PDF password length.
You are right in that the PDF encryption is less secure because the
password has to be long enough to withstand an off-line brute-force
attack. The length of the generated password can be set under the
advanced settings. The longer the better but less user friendly. The
generated password is encoded using base32 (A-Z and six digits 2-7) .
The main advantage is that it's easier to read for humans and therefore
less error prone (the 1 is not used so it cannot be misread as the
letter l).
If you require 128-bits of a random you have to set the password length
to 16 (16*8=128) so that's a long password to type.
If your security requirements need 128-bits security it's better to use
something like S/MIME.
Kind regards,
Martijn Brinkers
Eamonn McGonigle wrote:
Hi Martijn,
I have been playing with Djigzo for a couple of months now and I think
it is fantastic...so let me start by saying thanks for your hard work
on
it and for releasing it to the open-source community.
If you are looking for votes (!), I think #2 below is a real winner.
I
have been evaluating Djigzo in comparison to Cisco's Ironport for a
number of encryption requirements. While the "gateway-to-gateway"
S/MIME capabilities of Djigzo are ideal, I also have a requirement for
clientless support which Ironport's PXE does very nicely (but at a
steep
price). There appear to be a few other products out there covering
the
same ground (the ZixDirect at www.zixcorp.com and Trend Micro Private
Post from Trend Micro, to pick two examples). The PDF encryption in
Djigzo doesn't meet the requirements because to achieve an adequate
key
length would require typing in a password so long that users would
never
find it acceptable. I considered modifying your code to lengthen the
PDF encryption password and increase the "alphabet" from which
password
characters were drawn but dropped the idea when I worked out how long
the password would need to be to achieve even 128-bit key strength. I
would therefore be delighted to see Djigzo offer the kind of
clientless
capability you outline.
If I may venture a suggestion, I would have a slight concern about the
idea that the encrypted blob is pushed up to the server where the
decryption key is stored for decryption. I would suggest that it is
not
ideal to have the decryption key and the encrypted content both on
this
server. I know Cisco's Ironport works slightly differently. The user
receives the message in a HTML wrapper similar to what you describe
below. When he logs onto the server, a script in his browser downloads
the decryption key which is then used to decrypt the blob locally on
the
user's PC (done by a bunch of Javascript code which comes down with
the
HTML wrapper). This approach has the advantage that the message
content
is never actually stored on the key server...only the decryption key
(which is pretty useless without the message content). I guess the
obvious counter-argument is that the message is encrypted on this
server
in the first instance so uploading it again for decryption isn't a
dramatic dilution of the security (once the encrypted message content
isn't actually stored on the same server as the decryption keys).
Best Wishes,
Eamonn
Martijn Brinkers wrote:
Hi Dan,
Dan Banach wrote:
Sorry it's taken some time to respond. We deal with a wide range
of
email recipients (large companies, small offices, individuals, etc.)
with a wide range of email encryption knowledge, so the ideal
encryption
solution for us would be very flexible. Not only flexible for
outgoing
mail, but also incoming mail as well. Some users/business' use PGP,
others use certs and some use the various other options. Being able
to
communicate with them all is very helpful.
Right now now I'm working on Blackberry S/MIME support for BIS users
(for BES users there is already S/MIME email). Once that is finished
I
will start working on new major features. There are some features I
would like to start working on but I'm not sure which one that should
be.
Two main new features I was thinking about are:
1. PGP support
2. Client-less email encryption
Nr 1 is clear. I will briefly explain nr 2.
Client-less
Currently Djigzo supports S/MIME and PDF encryption. Recipients that
do
not want are cannot receive S/MIME or encrypted PDFs are currently
not
supported. The new encryption functionality I would like to add is
the
following:
If an email sent to an external recipient needs to be encrypted and
the
recipient cannot receive S/MIME email of an encrypted PDF the email
will
be converted to a .html file. The original plain-text message (and
attachments) will be encrypted with a certificate for the external
recipient and added to the .html. The .html will be added to a
general
message (which does not contain any sensitive information) and sent
to
the recipient. The recipient opens the .html message in the email
client
(can for example be hotmail). The .html will open a SSL connection to
the companies Djigzo server (which can be a dedicated server just for
the portal). The Djigzo server will show a login page. The recipient
now
has to login. After the login the recipients browser will push the
encrypted 'blob' (contained in the HTML) to the portal. The portal
will
decrypt the message with the private key of the recipient (which is
stored on the companies Djigzo server). The recipient can now read
the
message and download any attachments (the portal uses SSL for secure
access).
The main advantage is that the recipient only requires a browser. The
encrypted data is stored locally on the recipients system (there is
no
long term copy on the Djigzo server). An attacker needs access to the
locally stored .html file AND the portal password to read the
message.
The message is encrypted with the same algorithm as a S/MIME message.
The only difference is that it's encoded inside a .html file.
A disadvantage is that the Djigzo server needs to be accessible to
external recipients.
Right now I'm leaning towards implementing feature 2 but it could be
that you or any other Djigzo user has another preference or request
for
a feature. If so I'm all ears
I
think another great feature you could include would be to grant
internal
users the ability to manage their own decryption profiles. They
should
be able to add/create there own certs/keys and create their own
passwords. Ideally it is tied into the directory via ldap or
something
so authentication and user information is seamless.
One problem is that currently the settings for an external user are
shared by all internal users. So, if internal user A changes settings
for external user E internal user B will also be affected. Do you
want
the user list to be different for each internal user?
Right now you can add admins with different roles. You can add an
admin
that can add keys etc. but not change the MTA settings,
Kind regards,
Martijn
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users
--
Djigzo open source email encryption
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users
I think option 1 is a desirable feature. I'm not overly impressed by the
security of option 2 (see my other post) so I'd rather see option 1.
As for my other statement about the internal users being able to manage
their encryption profiles, I meant their personal profiles. Let them
upload their own certs if they have them and enter their own passwords,
etc. I agree that the external user profiles should be managed globally.
Thanks,
Dan
···
-----Original Message-----
From: users-bounces(a)lists.djigzo.com
[mailto:users-bounces(a)lists.djigzo.com] On Behalf Of Martijn Brinkers
Sent: Wednesday, June 17, 2009 9:33 AM
To: users(a)lists.djigzo.com
Subject: Re: Customer experience
Hi Dan,
Dan Banach wrote:
Sorry it's taken some time to respond. We deal with a wide range of
email recipients (large companies, small offices, individuals, etc.)
with a wide range of email encryption knowledge, so the ideal
encryption
solution for us would be very flexible. Not only flexible for outgoing
mail, but also incoming mail as well. Some users/business' use PGP,
others use certs and some use the various other options. Being able to
communicate with them all is very helpful.
Right now now I'm working on Blackberry S/MIME support for BIS users
(for BES users there is already S/MIME email). Once that is finished I
will start working on new major features. There are some features I
would like to start working on but I'm not sure which one that should
be.
Two main new features I was thinking about are:
1. PGP support
2. Client-less email encryption
Nr 1 is clear. I will briefly explain nr 2.
Client-less
Currently Djigzo supports S/MIME and PDF encryption. Recipients that do
not want are cannot receive S/MIME or encrypted PDFs are currently not
supported. The new encryption functionality I would like to add is the
following:
If an email sent to an external recipient needs to be encrypted and the
recipient cannot receive S/MIME email of an encrypted PDF the email will
be converted to a .html file. The original plain-text message (and
attachments) will be encrypted with a certificate for the external
recipient and added to the .html. The .html will be added to a general
message (which does not contain any sensitive information) and sent to
the recipient. The recipient opens the .html message in the email client
(can for example be hotmail). The .html will open a SSL connection to
the companies Djigzo server (which can be a dedicated server just for
the portal). The Djigzo server will show a login page. The recipient now
has to login. After the login the recipients browser will push the
encrypted 'blob' (contained in the HTML) to the portal. The portal will
decrypt the message with the private key of the recipient (which is
stored on the companies Djigzo server). The recipient can now read the
message and download any attachments (the portal uses SSL for secure
access).
The main advantage is that the recipient only requires a browser. The
encrypted data is stored locally on the recipients system (there is no
long term copy on the Djigzo server). An attacker needs access to the
locally stored .html file AND the portal password to read the message.
The message is encrypted with the same algorithm as a S/MIME message.
The only difference is that it's encoded inside a .html file.
A disadvantage is that the Djigzo server needs to be accessible to
external recipients.
Right now I'm leaning towards implementing feature 2 but it could be
that you or any other Djigzo user has another preference or request for
a feature. If so I'm all ears
I
think another great feature you could include would be to grant
internal
users the ability to manage their own decryption profiles. They should
be able to add/create there own certs/keys and create their own
passwords. Ideally it is tied into the directory via ldap or something
so authentication and user information is seamless.
One problem is that currently the settings for an external user are
shared by all internal users. So, if internal user A changes settings
for external user E internal user B will also be affected. Do you want
the user list to be different for each internal user?
Right now you can add admins with different roles. You can add an admin
that can add keys etc. but not change the MTA settings,
Kind regards,
Martijn
_______________________________________________
Users mailing list
Users(a)lists.djigzo.com
http://lists.djigzo.com/lists/listinfo/users