Todays Internet offers methods for secure web access and email transfer which are based on cryptographic
methods, called public keys.
These ensure privacy of communication and authentification of the sender and receiver.
Most contemporary browsers and email programs support these with one or two "mouse clicks" and the
advantages are numerous.
More information is found at
http://www.pki-page.org/ and other places.
Web pages and emails can be signed and encrypted by digital certificates which are issued by
Certificate Authorities (CA). Most of these are privately operated,
commercial companies. Your web browser has a built-in list of about a few dozen of these CAs
(listing of CAs in webbrowser Firefox, March 2007), and when ever it
encounters a certificate issued by one of them, it trust that certificate without any further questions
asked. This, by itself, could be regarded as being a fairly optimistic view on cryptographic security.
It does ease handling at the client side and may therefor be suitable for mass access to
secure web pages, e.g. banks or e-vendors like amazon .
Since communication at our site is much more personal, we chose being our own CA. Which works exactly the
same way as described, except our CA is not ad-hoc known to your browser.
Accordingly, you may make it known to your browser, which requires a one-time step on your side:
When loading our CA certificate, your browser shows a dialog window requesting you to confirm loading of an "untrusted" certificate. Depending on your browser, the dialog looks similar to this one (Mozilla browser 1.5):
By all security and cryptographic standards you may want to verify that it is truly our certificate. Examining the certificate shows (again Mozilla 1.5):
Verification of the certificate is done by checking the SHA1 fingerprint,
a number shown in the dialog window:
88:B8:DD:40:FC:5F:49:BC:9E:59:98:F2:8F:EB:D5:D2:43:DB:4E:1F
It is a general cryptological circumstance that an authentication code or encryption passphrase
has to be communicated on other transport ways as the authenticated or encrypted message itself.
In this scenario, we fax you this fingerprint as reference upon request,
or sent you the complete key by post.
Sending it by email would be logically inconsistent, of course.
Note: New key generated 28th December 2010.
Please contact us prior to sending S/MIME encrypted emails.
You might have to unset "OCSP Validate Certificates" in "Security Prefs" on the "opera:config" page.