N
Nathan Dornbrook
Hi, guys!
I'm trying to secure email between two organisations.
Both organisations are using Outlook 2003, Exchange 2003, Mailsweeper,
Server 2003 and Windows XP.
Both organisations have their own internal Entrust PKI to issue certificates.
Neither organisation can use their certificates with the built in Digital ID
support for Outlook 2003. This appears to be because the certificate type
that Entrust recommends for personal users is an RFC 822 compliant
certificate with a SubjectAlternateName field that contains all of the email
addresses of the individual - but Outlook 2003 looks for the optional E=
extension in the Subject field of the certificate instead and will never look
in SubjectAlternateName.
Since the Entrust based RFC 822 certificates don't have an E= field, they
can't be used.
This is annoying more than anything else; we're developing a new certificate
type that will be simultaneously RFC 822 compliant and also contain an E=
field in the subject line, but in the meantime still want to exchange
encrypted and signed emails.
So we thought we'd try something else while this development work takes place.
One organisation made the decision to switch cryptographic service provider
to the Entrust CSP and roll out Entrust Express + Entelligence. The other to
use Digital IDs from Verisign.
The results are...odd. And here's where I really need your help.
Organisation A, using Entrust Express, can sign or encrypt or both.
If the email is signed by Entrust, but not encrypted, the Mailsweeper
gateway flags it as malformed, because the crytpographic hash doesn't match.
This happens because the disclaimer added by the Exchange bridgehead server
on the way out changes what the hash should be when it's hashed again, so the
value in the signature.p7s file is now wrong. But legally, this company MUST
have a disclaimer added to each email as it leaves.
If the email is encrypted or encrypted and signed, it makes it through the
gateway just fine - that's because the signature.p7s matches the encrypted
attachement, which is all it refers to.
Organisation A can exchange encrypted and signed emails with test external
users using a variety of POP3 clients that also use POP3 (i.e. no Exchange
protocol, no X.400, no CCMAIL or MSMAIL or Pegasus or BlueMail, just vanilla
TCP/IP). This includes Outlook 2003, Entourage 2004, Eudora and Ximian, on
Windows XP, Vista, MacOS X and Ubuntu.
If the email is encrypted or encrypted and signed, the INBOUND Mailsweeper
in Organisation B flags it as malformed.
Adding an attachment of any type causes Mailsweeper to catch it outbound at
both organisations as malformed and this is still under investigation.
Organisation B is getting the classic "Your messge cannot be read because
the underlying security system cannot find the Digital ID name."
The fascinating thing here is that they can send signed emails, which
organisation can receive and read. The attached <certname>.p7c file can't be
added to the Entrust Address Book (unknown problem with Entrust Entelligence,
trouble ticket raised), but the public portion of the certificate can be
downloaded from Verisign in *.p7c format and installed manually.
They can also send encrypted emails, and sign them with their certificate.
They then can't read the emails that they just encrypted, getting the same
Digital ID name cannot be found error.
A lot of obvious stuff occurs right away, and we've tried the following to
resolve the issue:
1. Ensuring that the root CA relevant to the Verisign certificates is
installed.
2. Ensuring that in the Outlook Contacts, the users only have one Contact
per person and it has the right certificate and the certificate E= field and
the email address match. Outlook has the uncanny knack of UNERRINGLY picking
the wrong contact if there are two, one with the wrong certificate and one
with the right certificate.
This leaves us with the following theories:
1. Organisation B already has a Personal Certificate installed in the
Microsoft Ceritificate Store - exclusively for use with PEAP when
authenticating to their WiFi infrastructure. Because Outlook 2003 seems to
ALWAYS pick the wrong certificate if you have two Digital IDs for signing
email, it might be trying to pick up the WiFi certificate.
2. Both organisations us a Global Address List. The GAL contains entries for
each individual that contains multiple email addresses. When Outlook 2003
resolves your own address in this situation, it defaults to the X.400
address. Digital IDs can be issued with either X.400 or SMTP addresses, but
they can only be used to send encrypted email across the Internet using SMTP.
We think that the underlying security system might be able to encrypte using
a Digital ID with an SMTP address, but then can't open those emails because
the self-encryption is with the sender's SMTP address and the underlying
security system believes that the user is an X.400 user (remember, encrypting
and sending with S/MIME in most implementations encrypts twice: once to
send, with the recipient's public key and once for storage locally with the
sender's public key).
Both organisations are large (employees > 100,000).
While we could solve the confidentiality issue with site-to-site TLS or,
even easier, site-to-site VPNs at the network layer, this won't buy us
non-repudiability.
Non-repudiability is a key feature here. If we have to print, sign and fax,
then Microsoft's vision of a digital office is pretty much bust.
The Entrust, Mailsweeper and disclaimer issues we will pursue with the
companies contracted to provide 3rd level support for the issue and we've
engaged Microsoft for the Outlook 2003 problem, but I was hoping that someone
in the community would have seen something like this before and have an
answer.
Sincerely,
Nathan Dornbrook
I'm trying to secure email between two organisations.
Both organisations are using Outlook 2003, Exchange 2003, Mailsweeper,
Server 2003 and Windows XP.
Both organisations have their own internal Entrust PKI to issue certificates.
Neither organisation can use their certificates with the built in Digital ID
support for Outlook 2003. This appears to be because the certificate type
that Entrust recommends for personal users is an RFC 822 compliant
certificate with a SubjectAlternateName field that contains all of the email
addresses of the individual - but Outlook 2003 looks for the optional E=
extension in the Subject field of the certificate instead and will never look
in SubjectAlternateName.
Since the Entrust based RFC 822 certificates don't have an E= field, they
can't be used.
This is annoying more than anything else; we're developing a new certificate
type that will be simultaneously RFC 822 compliant and also contain an E=
field in the subject line, but in the meantime still want to exchange
encrypted and signed emails.
So we thought we'd try something else while this development work takes place.
One organisation made the decision to switch cryptographic service provider
to the Entrust CSP and roll out Entrust Express + Entelligence. The other to
use Digital IDs from Verisign.
The results are...odd. And here's where I really need your help.
Organisation A, using Entrust Express, can sign or encrypt or both.
If the email is signed by Entrust, but not encrypted, the Mailsweeper
gateway flags it as malformed, because the crytpographic hash doesn't match.
This happens because the disclaimer added by the Exchange bridgehead server
on the way out changes what the hash should be when it's hashed again, so the
value in the signature.p7s file is now wrong. But legally, this company MUST
have a disclaimer added to each email as it leaves.
If the email is encrypted or encrypted and signed, it makes it through the
gateway just fine - that's because the signature.p7s matches the encrypted
attachement, which is all it refers to.
Organisation A can exchange encrypted and signed emails with test external
users using a variety of POP3 clients that also use POP3 (i.e. no Exchange
protocol, no X.400, no CCMAIL or MSMAIL or Pegasus or BlueMail, just vanilla
TCP/IP). This includes Outlook 2003, Entourage 2004, Eudora and Ximian, on
Windows XP, Vista, MacOS X and Ubuntu.
If the email is encrypted or encrypted and signed, the INBOUND Mailsweeper
in Organisation B flags it as malformed.
Adding an attachment of any type causes Mailsweeper to catch it outbound at
both organisations as malformed and this is still under investigation.
Organisation B is getting the classic "Your messge cannot be read because
the underlying security system cannot find the Digital ID name."
The fascinating thing here is that they can send signed emails, which
organisation can receive and read. The attached <certname>.p7c file can't be
added to the Entrust Address Book (unknown problem with Entrust Entelligence,
trouble ticket raised), but the public portion of the certificate can be
downloaded from Verisign in *.p7c format and installed manually.
They can also send encrypted emails, and sign them with their certificate.
They then can't read the emails that they just encrypted, getting the same
Digital ID name cannot be found error.
A lot of obvious stuff occurs right away, and we've tried the following to
resolve the issue:
1. Ensuring that the root CA relevant to the Verisign certificates is
installed.
2. Ensuring that in the Outlook Contacts, the users only have one Contact
per person and it has the right certificate and the certificate E= field and
the email address match. Outlook has the uncanny knack of UNERRINGLY picking
the wrong contact if there are two, one with the wrong certificate and one
with the right certificate.
This leaves us with the following theories:
1. Organisation B already has a Personal Certificate installed in the
Microsoft Ceritificate Store - exclusively for use with PEAP when
authenticating to their WiFi infrastructure. Because Outlook 2003 seems to
ALWAYS pick the wrong certificate if you have two Digital IDs for signing
email, it might be trying to pick up the WiFi certificate.
2. Both organisations us a Global Address List. The GAL contains entries for
each individual that contains multiple email addresses. When Outlook 2003
resolves your own address in this situation, it defaults to the X.400
address. Digital IDs can be issued with either X.400 or SMTP addresses, but
they can only be used to send encrypted email across the Internet using SMTP.
We think that the underlying security system might be able to encrypte using
a Digital ID with an SMTP address, but then can't open those emails because
the self-encryption is with the sender's SMTP address and the underlying
security system believes that the user is an X.400 user (remember, encrypting
and sending with S/MIME in most implementations encrypts twice: once to
send, with the recipient's public key and once for storage locally with the
sender's public key).
Both organisations are large (employees > 100,000).
While we could solve the confidentiality issue with site-to-site TLS or,
even easier, site-to-site VPNs at the network layer, this won't buy us
non-repudiability.
Non-repudiability is a key feature here. If we have to print, sign and fax,
then Microsoft's vision of a digital office is pretty much bust.
The Entrust, Mailsweeper and disclaimer issues we will pursue with the
companies contracted to provide 3rd level support for the issue and we've
engaged Microsoft for the Outlook 2003 problem, but I was hoping that someone
in the community would have seen something like this before and have an
answer.
Sincerely,
Nathan Dornbrook