<?xml version='1.0' encoding='UTF-8' ?>

<!DOCTYPE manualpage SYSTEM "/style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="/style/manual.en.xsl"?>

<manualpage metafile="ssl_intro.xml.meta">

<parentdocument href="./">SSL/TLS</parentdocument>

<title>SSL/TLS Strong Encryption: An Introduction</title>

<summary>

<p>As an introduction this chapter is aimed at readers who are familiar

with the Web, HTTP, and Apache, but are not security experts. It is not

intended to be a definitive guide to the SSL protocol, nor does it discuss

specific techniques for managing certificates in an organization, or the

important legal issues of patents and import and export restrictions.

Rather, it is intended to provide a common background to <module

>mod_ssl</module> users by pulling together various concepts, definitions,

and examples as a starting point for further exploration.</p>

</summary>

<section id="cryptographictech">

<title>Cryptographic Techniques</title>

<p>Understanding SSL requires an understanding of cryptographic

algorithms, message digest functions (aka. one-way or hash functions), and

digital signatures. These techniques are the subject of entire books (see

for instance [<a href="#AC96">AC96</a>]) and provide the basis for privacy,

integrity, and authentication.</p>

<section id="cryptographicalgo">

<title>Cryptographic Algorithms</title>

<p>Suppose Alice wants to send a message to her bank to transfer some

money. Alice would like the message to be private, since it will

include information such as her account number and transfer amount. One

solution is to use a cryptographic algorithm, a technique that would

transform her message into an encrypted form, unreadable until it is

decrypted. Once in this form, the message can only be

decrypted by using a secret key. Without the key the message is useless:

good cryptographic algorithms make it so difficult

for intruders to decode the original text that it isn't worth their

effort.</p>

<p>There are two categories of cryptographic algorithms: conventional

and public key.</p>

<dl>

<dt>Conventional cryptography</dt>

<dd>also known as symmetric cryptography, requires the sender and

receiver to share a key: a secret piece of information that may be

used to encrypt or decrypt a message. As long as this key is kept

secret, nobody other than the sender or recipient can read the message.

If Alice and the bank know a secret key, then they can send each other

private messages. The task of sharing a key between sender and recipient

before communicating, while also keeping it secret from others, can be

problematic.</dd>

<dt>Public key cryptography</dt>

<dd>also known as asymmetric cryptography, solves the key exchange

problem by defining an algorithm which uses two keys, each of which

may be used to encrypt a message. If one key is used to encrypt a

message then the other must be used to decrypt it. This makes it

possible to receive secure messages by simply publishing one key

(the public key) and keeping the other secret (the private key).</dd>

</dl>

<p>Anyone can encrypt a message using the public key, but only the

owner of the private key will be able to read it. In this way, Alice

can send private messages to the owner of a key-pair (the bank), by

encrypting them using their public key. Only the bank will be able to

decrypt them.</p>

</section>

<section id="messagedigests">

<title>Message Digests</title>

<p>Although Alice may encrypt her message to make it private, there

is still a concern that someone might modify her original message or

substitute it with a different one, in order to transfer the money

to themselves, for instance. One way of guaranteeing the integrity

of Alice's message is for her to create a concise summary of her

message and send this to the bank as well. Upon receipt of the message,

the bank creates its own summary and compares it with the one Alice

sent. If the summaries are the same then the message has been received

intact.</p>

<p>A summary such as this is called a <dfn>message digest</dfn>, <em>one-way

function</em> or <em>hash function</em>. Message digests are used to create

a short, fixed-length representation of a longer, variable-length message.

Digest algorithms are designed to produce a unique digest for each

message. Message digests are designed to make it impractically difficult

to determine the message from the digest and (in theory) impossible to

find two different messages which create the same digest -- thus

eliminating the possibility of substituting one message for another while

maintaining the same digest.</p>

<p>Another challenge that Alice faces is finding a way to send the digest

to the bank securely; if the digest is not sent securely, its integrity may

be compromised and with it the possibility for the bank to determine the

integrity of the original message. Only if the digest is sent securely can

the integrity of the associated message be determined.</p>

<p>One way to send the digest securely is to include it in a digital

signature.</p>

</section>

<section id="digitalsignatures"><title>Digital Signatures</title>

<p>When Alice sends a message to the bank, the bank needs to ensure that the

message is really from her, so an intruder cannot request a transaction

involving her account. A <em>digital signature</em>, created by Alice and

included with the message, serves this purpose.</p>

<p>Digital signatures are created by encrypting a digest of the message and

other information (such as a sequence number) with the sender's private key.

Though anyone can <em>decrypt</em> the signature using the public key, only the

sender knows the private key. This means that only the sender can have signed

the message. Including the digest in the signature means the signature is only

good for that message; it also ensures the integrity of the message since no one

can change the digest and still sign it.</p>

<p>To guard against interception and reuse of the signature by an intruder at a

later date, the signature contains a unique sequence number. This protects

the bank from a fraudulent claim from Alice that she did not send the message

-- only she could have signed it (non-repudiation).</p>

</section>

</section>

<section id="certificates">

<title>Certificates</title>

<p>Although Alice could have sent a private message to the bank, signed

it and ensured the integrity of the message, she still needs to be sure

that she is really communicating with the bank. This means that she needs

to be sure that the public key she is using is part of the bank's key-pair,

and not an intruder's. Similarly, the bank needs to verify that the message

signature really was signed by the private key that belongs to Alice.</p>

<p>If each party has a certificate which validates the other's identity,

confirms the public key and is signed by a trusted agency, then both

can be assured that they are communicating with whom they think they are.

Such a trusted agency is called a <em>Certificate Authority</em> and

certificates are used for authentication.</p>

<section id="certificatecontents">

<title>Certificate Contents</title>

<p>A certificate associates a public key with the real identity of

an individual, server, or other entity, known as the subject. As

shown in <a href="#table1">Table 1</a>, information about the subject

includes identifying information (the distinguished name) and the

public key. It also includes the identification and signature of the

Certificate Authority that issued the certificate and the period of

time during which the certificate is valid. It may have additional

information (or extensions) as well as administrative information

for the Certificate Authority's use, such as a serial number.</p>

<section id="table1">

<title>Table 1: Certificate Information</title>

<table>

<columnspec><column width=".35"/><column width=".35"/>

</columnspec>

<tr><th>Subject</th>

<td>Distinguished Name, Public Key</td></tr>

<tr><th>Issuer</th>

<td>Distinguished Name, Signature</td></tr>

<tr><th>Period of Validity</th>

<td>Not Before Date, Not After Date</td></tr>

<tr><th>Administrative Information</th>

<td>Version, Serial Number</td></tr>

<tr><th>Extended Information</th>

<td>Basic Constraints, Netscape Flags, etc.</td></tr>

</table>

</section>

<p>A distinguished name is used to provide an identity in a specific

context -- for instance, an individual might have a personal

certificate as well as one for their identity as an employee.

Distinguished names are defined by the X.509 standard [<a

href="#X509">X509</a>], which defines the fields, field names and

abbreviations used to refer to the fields (see <a href="#table2">Table

2</a>).</p>

<section id="table2">

<title>Table 2: Distinguished Name Information</title>

<table border="1">

<columnspec><column width=".25"/><column width=".15"/>

<column width=".3"/><column width=".25"/></columnspec>

<tr><th>DN Field</th>

<th>Abbrev.</th>

<th>Description</th>

<th>Example</th></tr>

<tr><td>Common Name</td>

<td>CN</td>

<td>Name being certified</td>

<td>CN=Joe Average</td></tr>

<tr><td>Organization or Company</td>

<td>O</td>

<td>Name is associated with this<br />organization</td>

<td>O=Snake Oil, Ltd.</td></tr>

<tr><td>Organizational Unit</td>

<td>OU</td>

<td>Name is associated with this <br />organization unit, such

as a department</td>

<td>OU=Research Institute</td></tr>

<tr><td>City/Locality</td>

<td>L</td>

<td>Name is located in this City</td>

<td>L=Snake City</td></tr>

<tr><td>State/Province</td>

<td>ST</td>

<td>Name is located in this State/Province</td>

<td>ST=Desert</td></tr>

<tr><td>Country</td>

<td>C</td>

<td>Name is located in this Country (ISO code)</td>

<td>C=XZ</td></tr>

</table>

</section>

<p>A Certificate Authority may define a policy specifying which

distinguished field names are optional and which are required. It

may also place requirements upon the field contents, as may users of

certificates. For example, a Netscape browser requires that the

Common Name for a certificate representing a server matches a wildcard

pattern for the domain name of that server, such

as <code>*.snakeoil.com</code>.</p>

<p>The binary format of a certificate is defined using the ASN.1

notation [<a href="#ASN1">ASN1</a>] [<a href="#PKCS">PKCS</a>]. This

notation defines how to specify the contents and encoding rules

define how this information is translated into binary form. The binary

encoding of the certificate is defined using Distinguished Encoding

Rules (DER), which are based on the more general Basic Encoding Rules

(BER). For those transmissions which cannot handle binary, the binary

form may be translated into an ASCII form by using Base64 encoding

[<a href="#MIME">MIME</a>]. When placed between begin and end delimiter

lines (as below), this encoded version is called a PEM ("Privacy Enhanced

Mail") encoded certificate.</p>

<example>

<title>Example of a PEM-encoded certificate (snakeoil.crt)</title>

<pre>-----BEGIN CERTIFICATE-----

MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx

FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG

A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv

cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz

bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL

MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h

a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl

cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN

AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB

gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b

vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa

lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV

HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB

gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt

2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7

dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==

-----END CERTIFICATE-----</pre>

</example>

</section>

<section id="certificateauthorities">

<title>Certificate Authorities</title>

<p>By verifying the information in a certificate request

before granting the certificate, the Certificate Authority assures

itself of the identity of the private key owner of a key-pair.

For instance, if Alice requests a personal certificate, the

Certificate Authority must first make sure that Alice really is the

person the certificate request claims she is.</p>

<section id="certificatechains">

<title>Certificate Chains</title>

<p>A Certificate Authority may also issue a certificate for

another Certificate Authority. When examining a certificate,

Alice may need to examine the certificate of the issuer, for each

parent Certificate Authority, until reaching one which she has

confidence in. She may decide to trust only certificates with a

limited chain of issuers, to reduce her risk of a "bad" certificate

in the chain.</p>

</section>

<section id="rootlevelca">

<title>Creating a Root-Level CA</title>

<p>As noted earlier, each certificate requires an issuer to assert

the validity of the identity of the certificate subject, up to

the top-level Certificate Authority (CA). This presents a problem:

who can vouch for the certificate of the top-level

authority, which has no issuer? In this unique case, the

certificate is "self-signed", so the issuer of the certificate is

the same as the subject. Browsers are preconfigured to trust well-known

certificate authorities, but it is important to exercise extra care in

trusting a self-signed certificate. The wide publication of a

public key by the root authority reduces the risk in trusting this

key -- it would be obvious if someone else publicized a key

claiming to be the authority.</p>

<p>A number of companies, such as <a href="http://www.thawte.com/"

>Thawte</a> and <a href="http://www.verisign.com/">VeriSign</a>

have established themselves as Certificate Authorities. These

companies provide the following services:</p>

<ul>

<li>Verifying certificate requests</li>

<li>Processing certificate requests</li>

<li>Issuing and managing certificates</li>

</ul>

<p>It is also possible to create your own Certificate Authority.

Although risky in the Internet environment, it may be useful

within an Intranet where the organization can easily verify the

identities of individuals and servers.</p>

</section>

<section id="certificatemanagement">

<title>Certificate Management</title>

<p>Establishing a Certificate Authority is a responsibility which

requires a solid administrative, technical and management

framework. Certificate Authorities not only issue certificates,

they also manage them -- that is, they determine for how long

certificates remain valid, they renew them and keep lists of

certificates that were issued in the past but are no longer valid

(Certificate Revocation Lists, or CRLs).</p>

<p>For example, if Alice is entitled to a certificate as an

employee of a company but has now left

that company, her certificate may need to be revoked.

Because certificates are only issued after the subject's identity has

been verified and can then be passed around to all those with whom

the subject may communicate, it is impossible to tell from the

certificate alone that it has been revoked.

Therefore when examining certificates for validity

it is necessary to contact the issuing Certificate Authority to

check CRLs -- this is usually not an automated part of the process.</p>

<note><title>Note</title>

<p>If you use a Certificate Authority that browsers are not configured

to trust by default, it is necessary to load the Certificate

Authority certificate into the browser, enabling the browser to

validate server certificates signed by that Certificate Authority.

Doing so may be dangerous, since once loaded, the browser will

accept all certificates signed by that Certificate Authority.</p>

</note>

</section>

</section>

</section>

<section id="ssl">

<title>Secure Sockets Layer (SSL)</title>

<p>The Secure Sockets Layer protocol is a protocol layer which may be

placed between a reliable connection-oriented network layer protocol

(e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides

for secure communication between client and server by allowing mutual

authentication, the use of digital signatures for integrity and encryption

for privacy.</p>

<p>The protocol is designed to support a range of choices for specific

algorithms used for cryptography, digests and signatures. This allows

algorithm selection for specific servers to be made based on legal, export

or other concerns and also enables the protocol to take advantage of new

algorithms. Choices are negotiated between client and server when

establishing a protocol session.</p>

<section id="table4">

<title>Table 4: Versions of the SSL protocol</title>

<table border="1">

<columnspec><column width=".15"/><column width=".2"/>

<column width=".30"/><column width=".25"/></columnspec>

<tr><th>Version</th>

<th>Source</th>

<th>Description</th>

</tr>

<tr><td>SSL v2.0</td>

<td>Vendor Standard (from Netscape Corp.)</td>

<td>First SSL protocol for which implementations exist</td>

</tr>

<tr><td>SSL v3.0</td>

<td>Expired Internet Draft (from Netscape Corp.) [<a href="#SSL3"

>SSL3</a>]</td>

<td>Revisions to prevent specific security attacks, add non-RSA

ciphers and support for certificate chains</td>

</tr>

<tr><td>TLS v1.0</td>

<td>Proposed Internet Standard (from IETF) [<a href="#TLS1"

>TLS1</a>]</td>

<td>Revision of SSL 3.0 to update the MAC layer to HMAC, add block

padding for block ciphers, message order standardization and more

alert messages.</td>

</tr>

<tr><td>TLS v1.1</td>

<td>Proposed Internet Standard (from IETF) [<a href="#TLS11"

>TLS11</a>]</td>

<td>Update of TLS 1.0 to add protection against Cipher block chaining

(CBC) attacks.</td>

</tr>

<tr><td>TLS v1.2</td>

<td>Proposed Internet Standard (from IETF) [<a href="#TLS12"

>TLS12</a>]</td>

<td>Update of TLS 1.2 deprecating MD5 as hash, and adding incompatibility

to SSL so it will never negotiate the use of SSLv2.</td>

</tr>

</table>

</section>

<p>There are a number of versions of the SSL protocol, as shown in

<a href="#table4">Table 4</a>. As noted there, one of the benefits in

SSL 3.0 is that it adds support of certificate chain loading. This feature

allows a server to pass a server certificate along with issuer certificates

to the browser. Chain loading also permits the browser to validate the

server certificate, even if Certificate Authority certificates are not

installed for the intermediate issuers, since they are included in the

certificate chain. SSL 3.0 is the basis for the Transport Layer Security

[<a href="#TLS1">TLS</a>] protocol standard, currently in development by

the Internet Engineering Task Force (IETF).</p>

<section id="session">

<title>Establishing a Session</title>

<p>The SSL session is established by following a handshake sequence

between client and server, as shown in <a href="#figure1"

>Figure 1</a>. This sequence may vary, depending on whether the server

is configured to provide a server certificate or request a client

certificate. Although cases exist where additional handshake steps

are required for management of cipher information, this article

summarizes one common scenario. See the SSL specification for the full

range of possibilities.</p>

<note><title>Note</title>

<p>Once an SSL session has been established, it may be reused. This

avoids the performance penalty of repeating the many steps needed

to start a session. To do this, the server assigns each SSL session a

unique session identifier which is cached in the server and which the

client can use in future connections to reduce the handshake time

(until the session identifier expires from the cache of the server).</p>

</note>

<p class="figure">

<img src="/images/ssl_intro_fig1.gif" alt="" width="423"

height="327" /><br />

<a id="figure1" name="figure1"><dfn>Figure 1</dfn></a>: Simplified SSL

Handshake Sequence</p>

<p>The elements of the handshake sequence, as used by the client and

server, are listed below:</p>

<ol>

<li>Negotiate the Cipher Suite to be used during data transfer</li>

<li>Establish and share a session key between client and server</li>

<li>Optionally authenticate the server to the client</li>

<li>Optionally authenticate the client to the server</li>

</ol>

<p>The first step, Cipher Suite Negotiation, allows the client and

server to choose a Cipher Suite supported by both of them. The SSL3.0

protocol specification defines 31 Cipher Suites. A Cipher Suite is

defined by the following components:</p>

<ul>

<li>Key Exchange Method</li>

<li>Cipher for Data Transfer</li>

<li>Message Digest for creating the Message Authentication Code (MAC)</li>

</ul>

<p>These three elements are described in the sections that follow.</p>

</section>

<section id="keyexchange">

<title>Key Exchange Method</title>

<p>The key exchange method defines how the shared secret symmetric

cryptography key used for application data transfer will be agreed

upon by client and server. SSL 2.0 uses RSA key exchange only, while

SSL 3.0 supports a choice of key exchange algorithms including

RSA key exchange (when certificates are used), and Diffie-Hellman key

exchange (for exchanging keys without certificates, or without prior

communication between client and server).</p>

<p>One variable in the choice of key exchange methods is digital

signatures -- whether or not to use them, and if so, what kind of

signatures to use. Signing with a private key provides protection

against a man-in-the-middle-attack during the information exchange

used to generating the shared key [<a href="#AC96">AC96</a>, p516].</p>

</section>

<section id="ciphertransfer">

<title>Cipher for Data Transfer</title>

<p>SSL uses conventional symmetric cryptography, as described earlier,

for encrypting messages in a session.

There are nine choices of how to encrypt, including the option not to

encrypt:</p>

<ul>

<li>No encryption</li>

<li>Stream Ciphers

<ul>

<li>RC4 with 40-bit keys</li>

<li>RC4 with 128-bit keys</li>

</ul></li>

<li>CBC Block Ciphers

<ul><li>RC2 with 40 bit key</li>

<li>DES with 40 bit key</li>

<li>DES with 56 bit key</li>

<li>Triple-DES with 168 bit key</li>

<li>Idea (128 bit key)</li>

<li>Fortezza (96 bit key)</li>

</ul></li>

</ul>

<p>"CBC" refers to Cipher Block Chaining, which means that a

portion of the previously encrypted cipher text is used in the

encryption of the current block. "DES" refers to the Data Encryption

Standard [<a href="#AC96">AC96</a>, ch12], which has a number of

variants (including DES40 and 3DES_EDE). "Idea" is currently one of

the best and cryptographically strongest algorithms available,

and "RC2" is a proprietary algorithm from RSA DSI [<a href="#AC96"

>AC96</a>, ch13].</p>

</section>

<section id="digestfuntion">

<title>Digest Function</title>

<p>The choice of digest function determines how a digest is created

from a record unit. SSL supports the following:</p>

<ul>

<li>No digest (Null choice)</li>

<li>MD5, a 128-bit hash</li>

<li>Secure Hash Algorithm (SHA-1), a 160-bit hash</li>

</ul>

<p>The message digest is used to create a Message Authentication Code

(MAC) which is encrypted with the message to verify integrity and to

protect against replay attacks.</p>

</section>

<section id="handshake">

<title>Handshake Sequence Protocol</title>

<p>The handshake sequence uses three protocols:</p>

<ul>

<li>The <dfn>SSL Handshake Protocol</dfn>

for performing the client and server SSL session establishment.</li>

<li>The <dfn>SSL Change Cipher Spec Protocol</dfn> for actually

establishing agreement on the Cipher Suite for the session.</li>

<li>The <dfn>SSL Alert Protocol</dfn> for conveying SSL error

messages between client and server.</li>

</ul>

<p>These protocols, as well as application protocol data, are

encapsulated in the <dfn>SSL Record Protocol</dfn>, as shown in

<a href="#figure2">Figure 2</a>. An encapsulated protocol is

transferred as data by the lower layer protocol, which does not

examine the data. The encapsulated protocol has no knowledge of the

underlying protocol.</p>

<p class="figure">

<img src="/images/ssl_intro_fig2.gif" alt="" width="428"

height="217" /><br />

<a id="figure2" name="figure2"><dfn>Figure 2</dfn></a>: SSL Protocol Stack

</p>

<p>The encapsulation of SSL control protocols by the record protocol

means that if an active session is renegotiated the control protocols

will be transmitted securely. If there was no previous session,

the Null cipher suite is used, which means there will be no encryption and

messages will have no integrity digests, until the session has been

established.</p>

</section>

<section id="datatransfer">

<title>Data Transfer</title>

<p>The SSL Record Protocol, shown in <a href="#figure3">Figure 3</a>,

is used to transfer application and SSL Control data between the

client and server, where necessary fragmenting this data into smaller units,

or combining multiple higher level protocol data messages into single

units. It may compress, attach digest signatures, and encrypt these

units before transmitting them using the underlying reliable transport

protocol (Note: currently, no major SSL implementations include support

for compression).</p>

<p class="figure">

<img src="/images/ssl_intro_fig3.gif" alt="" width="423"

height="323" /><br />

<a id="figure3" name="figure3"><dfn>Figure 3</dfn></a>: SSL Record Protocol

</p>

</section>

<section id="securehttp">

<title>Securing HTTP Communication</title>

<p>One common use of SSL is to secure Web HTTP communication between

a browser and a webserver. This does not preclude the use of

non-secured HTTP - the secure version (called HTTPS) is the same as

plain HTTP over SSL, but uses the URL scheme <code>https</code>

rather than <code>http</code>, and a different server port (by default,

port 443). This functionality is a large part of what <module

>mod_ssl</module> provides for the Apache webserver.</p>

</section>

</section>

<section id="references">

<title>References</title>

<dl>

<dt><a id="AC96" name="AC96">[AC96]</a></dt>

<dd>Bruce Schneier, <q>Applied Cryptography</q>, 2nd Edition, Wiley,

1996. See <a href="http://www.counterpane.com/"

>http://www.counterpane.com/</a> for various other materials by Bruce

Schneier.</dd>

<dt><a id="ASN1" name="ASN1">[ASN1]</a></dt>

<dd>ITU-T Recommendation X.208, <q>Specification of Abstract Syntax Notation

One (ASN.1)</q>, last updated 2008. See <a href="http://www.itu.int/ITU-T/asn1/"

>http://www.itu.int/ITU-T/asn1/</a>.

</dd>

<dt><a id="X509" name="X509">[X509]</a></dt>

<dd>ITU-T Recommendation X.509, <q>The Directory - Authentication

Framework</q>. For references, see <a

>http://en.wikipedia.org/wiki/X.509</a>.

</dd>

<dt><a id="PKCS" name="PKCS">[PKCS]</a></dt>

<dd><q>Public Key Cryptography Standards (PKCS)</q>,

RSA Laboratories Technical Notes, See <a

>http://www.rsasecurity.com/rsalabs/pkcs/</a>.</dd>

<dt><a id="MIME" name="MIME">[MIME]</a></dt>

<dd>N. Freed, N. Borenstein, <q>Multipurpose Internet Mail Extensions

(MIME) Part One: Format of Internet Message Bodies</q>, RFC2045.

See for instance <a href="http://tools.ietf.org/html/rfc2045"

>http://tools.ietf.org/html/rfc2045</a>.</dd>

<dt><a id="SSL3" name="SSL3">[SSL3]</a></dt>

<dd>Alan O. Freier, Philip Karlton, Paul C. Kocher, <q>The SSL Protocol

Version 3.0</q>, 1996. See <a

>http://www.netscape.com/eng/ssl3/draft302.txt</a>.</dd>

<dt><a id="TLS1" name="TLS1">[TLS1]</a></dt>

<dd>Tim Dierks, Christopher Allen, <q>The TLS Protocol Version 1.0</q>,

1999. See <a href="http://ietf.org/rfc/rfc2246.txt"

>http://ietf.org/rfc/rfc2246.txt</a>.</dd>

<dt><a id="TLS11" name="TLS11">[TLS11]</a></dt>

<dd><q>The TLS Protocol Version 1.1</q>,

2006. See <a href="http://tools.ietf.org/html/rfc4346"

>http://tools.ietf.org/html/rfc4346</a>.</dd>

<dt><a id="TLS12" name="TLS12">[TLS12]</a></dt>

<dd><q>The TLS Protocol Version 1.2</q>,

2008. See <a href="http://tools.ietf.org/html/rfc5246"

>http://tools.ietf.org/html/rfc5246</a>.</dd>

</dl>

</section>

</manualpage>