Yes Reflex MailSafe client supports MS Outlook 97,98, 2000 & 2002.

Reflex MailSafe can be run on MS Windows 9x, ME, NT, 2000 & XP.

No the receive need only to have an email client compatible with S/MIME V2 or 3+ and X.509 certificates. Standard MS Outlook 2000 onwards would be capable.

There are a number of reasons why you might consider Reflex MailSafe instead of relying on native MS Outlook. Firstly if you are considering implementing secure e-mail for a company or organisation it might be that not all of your deployed MS Outlook clients are 2000+ and thus compliant. Furthermore there is no central management offered for native MS Outlook clients with regard to the security settings. Native MS Outlook offers no integrated anti-virus support or active content checking thus secure e-mail would be sent and received unchecked. Native MS Outlook offers no Certification Authority (CA). Microsoft’s implementation of the RSA algorithm does not default to a secure setting and when set to secure does not allow caching of passwords/phrases when sending multiple secure e-mails.

Reflex Magnetics are committed to developing standards based software. We have actively taken part in UK Government sponsored industry interoperability trials and consistently been the highest achiever in these reported tests.

The first step is to import a Reflex MailSafe CA certificate to Netscape 7/Mozilla. This imported CA certificate will determine the level of trust for the PK. Within Netscape 7/Mozilla it is necessary to go to Edit/Preferences, then Privacy&Security, Certificates, Manage Certificates, go to the Authorities tab, press Import and import CA root certificate. Then check 'Trust this CA to identify e-mail users' checkbox and press OK.

Reflex MailSafe does not rely upon scripting being switched off; instead it strips all potentially harmful contents from the HTML code of the message body.

Unfortunately Reflex MailSafe would not help in the given scenario. Reflex MailSafe requires MS Outlook Client to operate and is not compatible with Outlook Web Access.

In order to be able to decrypt old e-mails you need to have these old encryption certificates present on the machine (not necessarily selected as personal), even if your new certificate is a renewed version of the old one with the same private key. This is a requirement of the S/MIME standard and cannot be changed. However, if the new certificate is using the same private key as the old one, you will not have to think of another password to protect your private key, which makes things a little easier.

Yes, Active Directory is supported however it is necessary to manually (with Active Directory editing tools) create a special container like (CN=MailSafe CA,DC=microsoft,DC=com) under which the CA certificate, CRLs and user certificates can be published.

Yes Reflex MailSafe is compatible with S/MIME V2.0 & V3+. It will require you to have a pair of keys for both versions however. Once these have been created one set can be your default key pair the other can be configured as your additional key pair so that they can be automatically selected when responding to a S/MIME message of that particular version.

Yes it is possible to deploy Reflex MailSafe clients across a LAN with the security settings pre-configured and controlled by the Reflex Configuration Server.

If you receive a new public self-signed certificate from someone Reflex MailSafe will notify you that there is a security problem – “You do not trust the sender’s certificate”. Click the “Details” button and then click “Edit Trust”. You can now select the “Explicitly trust this certificate” radio button and trust will be established.

Yes this is done by editing the the “Setup.iss” file.

Reflex MailSafe CA has a number of advantages over Microsoft CA including: - Reflex MailSafe CA can be configured to receive certificate requests and send issued certificates by e-mail thus the CA can be offline. - Reflex MailSafe CA does not require Active Directory and can be configured to publish certificates/CRLs into any LDAP directory. This is important as it is rather dangerous to expose ActiveDirectory to the Internet. - User-supplied prime numbers can be used in DSA / DH keys. - Support for Diffie-Hellman algorithm - Reflex MailSafe CA can be configured to work as part of another vendor based PKI. It is relatively easy to add/remove required certificate policies and extensions to the issued certificates. - Reflex MailSafe CA functionality can be extended using plug-ins. In MS Windows 2000 CA only one plug-in can be installed and the plug-in cannot display any user interface. - Reflex MailSafe CA has key recovery functionality At the same time Reflex MailSafe CA administration interface is similar to MS Windows 2000 CA. Reflex MailSafe CA can be configured to issue user certificates automatically if a certificate requester has online access to Reflex MailSafe CA and Exchange 5.5 or Active Directory is available. NT security is used to estabilish user identity and therefore Reflex MailSafe CA and the certificate requester must be in one domain or in trusted domains for this feature to be available. This functionality is implemented using the certificate authority plug-ins. a) Microsoft Exchange 5.5. Reflex MailSafe CA verifies that the certificate requester has read/write access to the Exchange mailbox corresponding to the requested e-mail address. If the request has such access, a certificate is issued automatically using the information from the Exchange user database. Issued certificates can be published to an Exchange LDAP directory. b) With Active Directory setup Reflex MailSafe CA uses the Active Directory user entry as the source for the user certificate information. MS Exchange 2000 is not required in this setup. This plug-in is currently under development.

The Signature Algorithm is the algorithm used by the CA to sign the certificate. It usually looks like sha1RSA (i.e. certificate subject, serial number, public key and extensions are combined together, then hashed with SHA-1 and then the produced hash is signed with RSA) or sha1DSA (SHA1 then DSA) etc. The Certificate thumbprint is a hash calculated of the whole certificate (including the CA signature and other data). This thumbprint is calculated every time a certificate is displayed - it is not contained in the certificate. In other words it is just a control sum of a certificate. The Certificate key thumbprint is a hash of the certificate public key - two certificates with the same public key will have identical certificate key thumbprints, but different certificate thumbprints. For example, if you feed one certificate request to the CA twice, the produced certificates will have same certificate key thumbprint (the key is taken from the request) and different certificate thumbprints (because certificates have different serial numbers). The purpose of thumbprints is to verify the trustworthiness of a certificate when two people do not have a CA that they both trust. This makes sense with self-signed certificates or in rather marginal scenario with CAs. For example, when user A has a cert issued by CA-A, and user B has a cert issued by CA-B. These two CAs don't know about each other and do not trust each other. When user B sends a message to A, A receives "Certificate is not trusted" message. A would like to explicitly trust B's certificate, but has no way to know whether it is really certificate of B. So A contacts B over the phone or personally and asks him for the thumbprint of his certificate. If the thumbprint matches - the certificate of B and the certificate A has received in the e-mail are the same and can be trusted.