Jennifer Knoell wrote:

Mostly for verification. Encryption is a non-issue since all mail communication stays within our network - which already provides mandatory encryption for road warriors. I'd like to make sure that if the managers get a mail from the IT department they _know_ its from the IT department. And vice versa ofcourse.

Sorry, are you saying that people are forging email headers and pretending to send email from your IT department? Within your network?

I agree with your boss.  Unless there is something
very specific and unusual, there is absolutely no
reason to "invest" in signing emails.


As far as I see it, it's one more layer to secure communication.

Well, maybe. It is only "secure" if people are forging email. If no-one is forging email, then there is no need for sigs. The fact that digital signatures exist doesn't mean we have to use them.

I stand by my comment - I see no reason why your
boss should pay money to sign emails.  Security
comes at a cost.  If it costs, and there is no
threat, don't pay the cost.

There isn't much value in signing emails.  There
is some value in encrypting emails, but it is
completely obscure why this should be done with
purchased certs;  people using OpenPGP products
tend to get by happily without paying anyone
for permission to communicate securely.


Too cumbersome. The whole infrastructure here is windows-based, and my experience with PGP on windows were such that our average employee here wouldn't be able to use it.

OK. ... but, I wasn't so much referring there to the clumsiness of the product, more the concept that PGP, however cumbersome, seems to achieve what you want without offending your boss's sense of investment. I.e., when it works, it is free. The fact that the concept is not deployed under SMIME/x.509/email is not the fault of the technology...

Creating self signed certs (SSCs) should really be
the way to go.  You do after all create your own
hand written signature.  Also, with anyone who wants
to check your signature, you already have a prior
relationship, so it's not as if you need to worry
about people creating an SSC in your name and
pretending to be you.


That's the idea, yes. AFAIK every email client out there complains if the digital signature doesn't match the saved signature. The only thing I need to get around is the warning, which may confuse people outside of our organization. Sure it's a simple thing to disable digital signing in this case - but let me tell you with what kind of employees I deal here: Got a call today from a fairly high-up guy raving that his newly serviced printer doesn't work. Turned out he forgot to put paper in, and it even told him so. Duh.

Right. Well, that's about the face of the ordinary user. I couldn't agree more, and in terms of crypto solutions there is only one product that I know that has achieved widespread usage within its sector, without imposing harrassment above and beyond the call of duty, and that is SSH.

Unfortunately, you have hit a real shortfall in the
crypto architecture.  Somewhere around the mid 90s,
someone convinced everyonne that self signed certs
were insecure.  This was of course nonsense, but he
succeeded, and now we are left with the legacy of
browsers and mailers not really accepting SSCs in
any real life scenario.  In the case of SMIME email,
that was a killer.  In the case of secure browsing,
that forced it to be used in only a small, lesser
important segment, e.g., transfer of credit cards
and other merchant stuff where the merchant can be
coerced into purchase.  Check the statistics on
securityspace.com, the rollout is somewhere in the
noise level.

Either way you are stuck.  There is no easy solution
for an organisation that wants to do its own crypto
within the CA/x509/SMIME world - that I know of.

Unfortunately, email clients like thunderbird and
the others are not set up to generate or accept SSCs
for the user.  This in my view is a general and
specific flaw in the entire model, and is probably
the one single biggest reason why x509 email (or
whatever term applies) is a flop.


I'd generate them for the users anyway, even install it in their clients.

Whichever. The main thing is that unless someone is attacking the weaknesses of either model, it comes down to what is easiest to do.

Another possibility is to use a proxy like that
which PGP Inc sells, I can't recall the name, but
it is a server that encrypts and presumably signs
as mails go out.

[CACert]

Which would not necessarily help me, considering the fact that I only control which clients are used _inside_ our company. I'm currently using Thunderbird, but the majority of the office does not (yet). Still working on that though :)

Ah, good point.

General problem with PGP: most clients don't support it, certainly not natively.

If you're talking about native email support, then you are in trouble. Either it is SMIME, or it is PGP. There are no nice solutions in email.

I appreciate your feedback, it gave me some more ideas to look in to.

Sure. Another idea - switch to chat. I think chat will more easily deal with crypto, although you do have the issue that you'll need to select a common chat client to get cross-network comms. So you run into the same incompatibility issue.

iang
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto

Reply via email to