iTP Secure WebServer System Administrators Guide (Version 7.5+)

The most secure form of authentication involves enclosing multiple public key certificates with every
signed message sent. However, the more familiar the sender is (or becomes) to the receiver of a
message, the less need there is to enclose multiple certificates. For example, Juliet might send
Romeo multiple certificates with her first message to him but only a single certificate thereafter,
after Romeo has had a chance to verify all the certificates accompanying her first message.
The best practice is probably to enclose a certificate chain of sufficient length so that the issuer of
the highest-level certificate in the chain is well-known to the receiver.
In accordance with the Public Key Certificate Standards (PKCS), every signature points to a certificate
that validates the public key of the signer. In other words, each signature contains the name of the
issuer of the certificate and the serial number of the certificate. Therefore, even if no certificates
are enclosed with a message, a verifier can still use the certificate chain to check the status of the
public key.
Obtaining Certificates
To obtain a public key certificate, Juliet first generates her own key pair. She then sends the public
key part of her key pair to an appropriate CA, along with convincing proof of her identity. After
validating Juliet's identity, the CA sends Juliet a certificate attesting to the binding between Juliet
Capulet and her public key. It also sends her a certificate chain verifying the CA's own public key.
As discussed in “Using Certificates” (page 272), Juliet can now use her certificate and inherited
chain to demonstrate the legitimacy of her public key.
CAs require varying forms of proof for verifying an applicant's identity. One CA might require a
driver's license, another might require notarization of the certificate request form, yet another might
require fingerprints. The Apple Computer Open Collaborative Environment (OCE), for example,
requires that the certificate request form be notarized.
Transport Layer Security (TLS)
TLS is an Internet protocol, which is defined by the Internet Engineering Task Force (IETF) and
described in RFC 4346. This protocol ensures confidentiality, and authentication layers over reliable
transport layers. It allows client/server applications to communicate across a network without any
threat of eavesdropping or data tampering. Among other features, TLS provides the following:
• Endpoint authentication and communications confidentiality over public networks using
cryptography.
• RSA security with 1024 and 2048-bit strengths.
The TLS protocol is composed of the following layers:
• The TLS Record Protocol
• The TLS Handshake Protocol
TLS Record Protocol
The TLS Record Protocol encapsulates other higher level protocols and provides connection security.
When implemented, the TLS Record Protocol ensures that the connection is private and reliable.
The secured connection has the following properties:
• Data encryption is achieved using symmetric cryptography (such as DES, RC4 encryptions
algorithms). The TLS library generates unique keys for each connection. These keys are
generated in accordance with the protocols agreed by both, the client and the server.
• The message is transmitted securely using hashed MAC algorithms instead of simple MAC
algorithms. The hash algorithms supported are SHA256, SHA1 and MD5. In cases when the
communicating protocol negotiates security parameters, the TLS Record Protocol can operate
without a MAC.
TLS Handshake Protocol
The TLS Handshake protocol is an encapsulated protocol. This protocol facilitates client/server
authentication and enables them to agree on an encryption algorithm and the cryptographic keys.
Transport Layer Security (TLS) 273