Cryptography Reference
In-Depth Information
and RSA for digital signatures and public-key encryption (the original S/MIME
proposal came from RSA Data Security Inc.).
Public-key management
. Again, OpenPGP is more flexible and can be supported
by almost any form of public-key management system. The default public key
management model for OpenPGP is to use a web of trust (see Section 11.4.1),
although more formal public-key management can also be supported. On
the other hand, S/MIME is based on the use of X.509 Version 3 certificates
(see Section 11.1.2) supported by a structured public-key management system
relying on Certificate Authorities.
AN ALTERNATIVE APPROACH TO EMAIL SECURITY
Since the approaches to email security that we have just discussed all rely on the
use of public-key cryptography, the problem of assurance of purpose of public
keys needs to be addressed by whichever public-key management system is used
to support an email security application.
In Section 11.4.2 we explained the potential benefits of identity-based public-
key cryptography in addressing the problem of providing assurance of purpose of
public keys. The IDPKC concept requires unique identifiers that can be associated
with users of the system. In email security applications such a potential unique
identifier exists in the form of the email address of the recipient. Thus, using
IDPKC, an email sender is potentially able to send an encrypted email to
any
recipient simply by encrypting the email using the recipient's email address.
The advantages offered by this concept have resulted in the commercial
development of email security applications based on IDPKC. As we discussed
in Section 11.4.2, one of the potential drawbacks with IDPKC is the need for
an online centrally-trusted key centre (TKC). Thus IDPKC is most suited to
large organisations where such a TKC can easily be provided, rather than home
users. However, a home user could well receive encrypted email from such an
organisationwithout needing any formal relationshipwith the sender. In this case:
1. The sender (from the organisation supporting IDPKC) sends an encrypted email
to the recipient (the home user), using the recipient's email address as the
encryption key.
2. The recipient receives an email message informing them that they have received
an encrypted email message and inviting them to visit a secure website in order
to view the contents.
3. The recipient clicks on the provided web link and is directed via an SSL-
protected channel to the organisation's TKC web server. This generates
the necessary private decryption key and recovers the email, which is then
displayed to the recipient.
The obvious concern with this approach is that the IDPKC approach requires
the recipient of the email to trust the sending organisation enough to visit the
website and request decryption of the protected email. From the organisation's
perspective, however, there is no need to rely on third-party public-key certificates.
