Got rid of some trivial warnings (nested comments and tokens after #endif).
<HTML>
<HEAD>
<TITLE>Security Glossary</TITLE>
</HEAD>
<BODY>
<H1><CENTER><b>Security Glossary</b></CENTER></H1>
<P><center><TABLE WIDTH="90%" BORDER="1" CELLSPACING="1" CELLPADDING="2"><TR
HEIGHT=0>
<TD WIDTH="25%"></TD><TD WIDTH="75%"></TD></TD>
</TR>
<TR>
<TD>
Security Classification
</td>
<td>
Internal
</td>
</tr>
<TR>
<TD>
Document Reference
</td>
<td>
SGL.GT0128.56
</td>
</tr>
<TR>
<TD>
Status
</td>
<td>
Draftversion
</td>
</tr>
<TR>
<TD>
Version
</td>
<td>
0.1
</td>
</tr>
<TR>
<TD>
Team/Department
</td>
<td>
Security Team
</td>
</tr>
<TR>
<TD>
Author
</td>
<td>
William Bamberg
</td>
</tr>
<TR>
<TD>
Owner
</td>
<td>
Security Team
</td>
</tr>
<TR HEIGHT=0><TD WIDTH="35%"></TD><TD
WIDTH="65%"></TD></TR></TABLE></P></center>
<P><center><TABLE WIDTH="90%" BORDER="1" CELLSPACING="1" CELLPADDING="2"><TR
HEIGHT=0>
<TD WIDTH="25%"></TD><TD WIDTH="75%"></TD></TD>
</TR>
<TR>
<TD>
<A name="Asymmetric Cryptography"></A>Asymmetric Cryptography
</td>
<td>
A form of cryptography in which the 'key' is generated as a key pair: if one key is used for encryption
only the other can be used to decrypt, and vice versa.
<p>
Using asymmetric cryptography, the problem of key distribution becomes one of authentication; i.e. how to make sure
that a given key really does belong to the entity that claims to own it.
</td>
</tr>
<TR>
<TD>
Attribute Certificate
</td>
<td>
A digitally signed data structure including at least an identifier for an individual entity
and a set of attributes, whose function is to bind the entity with the attributes, usually for the
purpose of authorisation.
</td>
</tr>
<TR>
<TD>
<A name="Authentication"></A>Authentication
</td>
<td>
Usually used to refer to a property of a communication; that the receiver of a message is able to ascertain its origin,
so an attacker cannot successfully impersonate the sender.
</td>
</tr>
<TR>
<TD>
<A name="Block Cipher"></A>Block Cipher
</td>
<td>
A class of <A HREF="#Symmetric Cryptography">symmetric algorithm</A> in which several bits of the input data
are encrypted at once in a fixed-size block.
The cipher and its mode of operation define the block size:
the plaintext is split up into appropriately-sized blocks and each block is fed into the cipher.
</td>
</tr>
<TR>
<TD>
CA Certificate
</td>
<td>
A certificate held by a <A HREF="#Certification Authority">CA</A>: the key pair associated with it is used for
signing certificates issued by that CA. May or may not be self-signed.
</td>
</tr>
<TR>
<TD>
<A name="Certificate"></A>Certificate
</td>
<td>
For our purposes, this is the same thing as a <A HREF="#Public Key Certificate">
public key certificate</A>
</td>
</tr>
<TR>
<TD><A name="Certification Authority"></A>Certification Authority (CA)
</td>
<td>
An organization which perform the following functions in a hierachical <A HREF="#Public Key Infrastructure">PKI</A>:
<ul>
<li>
providing trusted ‘root’ certificates to users (<A HREF="#End Entities">End Entities</A>), by
supplying them with the CA’s public key via out-of-band means.
</li>
<li>
certifying End Entities by generating and distributing certificates for them.
The certified EE is the subject of the certificate: the CA is the issuer.
</li>
<li>
supporting certificate <A HREF="#Revocation">revocation</A> and revocation checking: if an EE suspects that their key has
been compromised, they contact the CA which issued it, who should revoke their certificate.
</li>
</ul>
<p>A CA will always have a root certificate-signing key pair, which must be authenticated to End Entities via
out of band channels. This key pair is not logically certified by anything, but it is usually distributed inside
a <A HREF="#Self-signed Certificate">self-signed certificate</A> to afford some degree of <A HREF="#Tamper Evidency">tamper evidency</A>.
<p>However, CAs do not have to use their root key pair to issue certificates directly to End Entities. For organizational
reasons and to reduce the exposure of keys, a CA may have a single root signing key pair, which it uses to certify a
set of subordinate key pairs, which in turn are used to certify End Entities. Also, CAs may certify the
signing keys of other CAs by issuing <A HREF="#Cross Certificate">cross certificates</A>, which enable interoperation
between two distinct PKIs.
</td>
</tr>
<TR>
<TD>
<A name="Ciphertext"></A>Ciphertext
</td>
<td>
The output of an <A HREF="#Encryption">encryption</A> operation, or
the input to a <A HREF="#Decryption">decryption</A> operation.
</td>
</tr>
<TR>
<TD>
<A name="Client Authentication"></A>Client Authentication
</td>
<td>
In a secure client-server protocol such as <A HREF="#Transport Layer Security">TLS</A>, the process in which the client
<A HREF="#Authentication">authenticates</A> itself to the server, so the server knows who it's talking to.
</td>
</tr>
<TR>
<TD>
Client/User/End Entity Certificate
</td>
<td>
A <A HREF="#Certificate">certificate</A> issued by a <A HREF="#Certification Authority">CA</A> to an
<A HREF="#End Entity">end entity</A> (for example the user of a WID) who may use it
to demonstrate their ownership of the key pair associated with it
</td>
</tr>
<TR>
<TD>
<A name="Cross Certificate"></A>Cross Certificate
</td>
<td>
A <A HREF="#Certificate">certificate</A> issued by a <A HREF="#Certification Authority">CA</A> which certificates another
CA's <A HREF="#Root Certificate">root certificate</A>. This is way of uniting two distinct certification hierarchies.
</td>
</tr>
<TR>
<TD>
<A name="Decryption"></A>Decryption
</td>
<td>
The process of turning encrypted data (called ciphertext) into the original information (called plaintext)
using a cryptographic algorithm parameterised with a key.
</td>
</tr>
<TR>
<TD>
<A name="Digital Signature"></A>Digital Signature
</td>
<td>
A structure linking some data and a private key. A digital signature may be generated by the application of a
<A HREF="#Private Key">private key</A> to some piece of data. The original data
may be reconstructed by applying the corresponding public key, demonstrating that the signature could only have been generated by
someone with access to the private key.
<p>Digital signatures have two primary uses: to demonstrate someone's identity by signing some challenge, as in
<A HREF="#Client Authentication">client authentication</A> in <A HREF="#Transport Layer Security">TLS</A>, in which the client
signs a <A HREF="#Hash">hash</A> of the messages that have been exchanged, and more strongly, for someone to demonstrate their
acceptance of some human-processable information (e.g. 'Please withdraw £10 000 from my bank account') as in the
<A HREF="#WMLScript Crypto API">WMLScript Crypto API</A> <A HREF="#SignText">SignText</A> function.
</td>
</tr>
<TR>
<TD>
<A name="DSA"></A>Digital Signature Algorithm (DSA)
</td>
<td>
NIST-approved <A HREF="#Asymmetric Cryptography">asymmetric algorithm</A>. It can only be used for generating and
verifying <A HREF="#Digital Signature">digital signatures</A>, not for encryption.
</td>
</tr>
<TR>
<TD>
<A name="ECC"></A>Elliptic Curve Cryptography (ECC)
</td>
<td>
Elliptical curve cryptography (ECC) is an <A HREF="#Asymmetric Cryptography">asymmetric algorithm</A>
based on elliptic curve theory that can be used to create faster, smaller, and more efficient cryptographic keys.
Because ECC helps to establish equivalent security with lower computing power and battery resource usage,
it is becoming widely used for mobile applications.
</td>
</tr>
<TR>
<TD>
<A name="Encryption"></A>Encryption
</td>
<td>
The process of turning meaningful data (called plaintext) into meaningless gibberish (called ciphertext)
using a cryptographic algorithm parameterised with a key.
</td>
</tr>
<TR>
<TD>
<A name="End Entity"></A>End Entity
</td>
<td>
A leaf node in a certification hierarchy: any entity in a <A HREF="#Public Key Infrastructure">PKI</A>
which has a certificate, but is not allowed to issue its own certificates.
</td>
</tr>
<TR>
<TD>
<A name="Hash"></A>Hash
</td>
<td>
Hash algorithms take a variable-length input and produce a fixed length output known as a digest, or hash, of the input.
For cryptographic purposes they need to be one-way functions:
it should not be possible to deduce the input from the digest, or even any part of the input.
Also, it should be hard to find collisions: that is, two different inputs which produce the same output.
</td>
</tr>
<TR>
<TD>
<A name="HMAC"></A>HMAC
</td>
<td>
Keyed-Hashing for Message Authentication. A mechanism for message authentication using cryptographic
<A HREF="#Hash">hashes</A>. It can be used with any iterative cryptographic
hash function, e.g., <A HREF="#MD5">MD5</A>, <A HREF="#SHA-1">SHA-1</A>, in combination with a secret shared key.
The cryptographic strength of HMAC depends on the properties of the underlying hash function.
</td>
</tr>
<TR>
<TD>
ICC
</td>
<td>
Integrated Circuit Card: removable card with at least data storage and sometimes processing
</td>
</tr>
<TR>
<TD>
<A name="IPSec"></A>IPSec
</td>
<td>
A standard providing <A HREF="#Secrecy">secrecy</A> and <A HREF="#Authentication">authentication</A> at the network or
packet-processing layer of network communication. Earlier security approaches have inserted security at the
application layer of the communications model. IPsec will be especially useful for implementing virtual
private networks and for remote user access through dial-up connection to private networks. IPSec is mandatory in IPv6.
</td>
</tr>
<TR>
<TD>
<A name="MD2"></A>MD2
</td>
<td>
Legacy <A HREF="#Hash">hash algorithm</A>. Considered insecure.
</td>
</tr>
<TR>
<TD>
<A name="MD5"></A>MD5
</td>
<td>
Legacy <A HREF="#Hash">hash algorithm</A>. Considered vulnerable.
</td>
</tr>
<TR>
<TD>
<A name="Message Digest Algorithm"></A>Message Digest Algorithm
</td>
<td>
Same thing as a <A HREF="#Hash">hash algorithm</A>.
</td>
</tr>
<TR>
<TD>
<A name="Nonrepudiation"></A>Nonrepudiation
</td>
<td>
The process by which it is assured that an entity making a declaration cannot subsequently deny having made it:
so I can't claim that I never wrote that cheque.
</td>
</tr>
<TR>
<TD>
<A name="OCSP"></A>Online Certificate Status Protocol (OCSP)
</td>
<td>
A protocol enabling a <A HREF="#Relying Party">relying party</A> to check that a
<A HREF="#Certificate">certificate</A> has not been <A HREF="#Revocation">revoked</A>. In this protocol the OCSP client
asks the OCSP server about the status of one or more certificates, and receives a
<A HREF="#Digital Signature">digitally signed</A> response.
</td>
</tr>
<TR>
<TD>
<A name="Out Of Band"></A>Out Of Band
</td>
<td>
A channel of communication which is distinct from the channel which we are using cryptography to try to secure,
and which is secure on its own terms; that is, its security is not dependent on the cryptography we are using.
<p>A common example of an out of band channel is a motorcycle courier.
</td>
</tr>
<TR>
<TD>
<A name="Padding"></A>Padding
</td>
<td>
The process of adding bytes to the input to a <A HREF="#Block Cipher">block cipher</A> so that the input matches the
block size.
</td>
</tr>
<TR>
<TD>
<A name="Plaintext"></A>Plaintext
</td>
<td>
The output of an <A HREF="#Decryption">decryption</A> operation, or
the input to a <A HREF="#Encryption">encryption</A> operation.
</td>
</tr>
<TR>
<TD>
<A name="PGP"></A>Pretty Good Privacy (PGP)
</td>
<td>
A very widely-used <A HREF="#Encryption">encryption</A> and <A HREF="#Digital Signature">digital signing</A>
program.
</td>
</tr>
<TR>
<TD>
<A name="Private Key"></A>Private Key
</td>
<td>
In the context of <A HREF="#Public Key Cryptography">public key cryptography</A>, the private half of the key pair.
</td>
</tr>
<TR>
<TD>
<A name="Public Key"></A>Public Key
</td>
<td>
In the context of <A HREF="#Public Key Cryptography">public key cryptography</A>, the public half of the key pair.
</td>
</tr>
<TR>
<TD>
<A name="Public Key Certificate"></A>Public Key Certificate
</td>
<td>
A digitally signed structure including at least an identifier for an
individual entity and a public key, whose function is to bind the entity with the key.
</td>
</tr>
<TR>
<TD>
<A name="Public Key Cryptography"></A>Public Key Cryptography
</td>
<td>
A common application of <A HREF="#Asymmetric Cryptography">asymmetric cryptography</A> in which one half of the key pair is
kept secrect (the <A HREF="#Private Key">private key</A>) and the other half is published
(the <A HREF="#Public Key">public key</A>.
</td>
</tr>
<TR>
<TD>
<A name="Public Key Infrastructure"></A>Public Key Infrastructure
</td>
<td>
<p>A way of modelling real-world trust relationships which enables users of <A HREF="#Public Key Cryptography">public key cryptography</A>
to have confidence in the ownership of
the public keys they are using.
A PKI consists of:
<ul>
<li>
a <A HREF="#Trusted Third Party">trusted third party</a>
</li>
<li>
an <A HREF="#Out Of Band">out of band</A> means of distributing the TTP's <A HREF="#Public Key Certificate">public key certificate</A>
to <A HREF="#Relying Party">relying parties</a>
</li>
<li>
a means of distributing other certificates to relying parties
</li>
<li>
arrangements for the <A HREF="#Revocation">revocation</A> and renewal of these certificates
</li>
<li>
certificate management and validation software on the relying party's computer
</li>
</ul>
<p>The TTP uses its signing key pair to create certificates for other entities, which relying parties can use to authenticate these
other entities.
<p>We can classify PKIs according to whether they are hierachical or flat. In hierachical PKIs, such as the one defined in the <A HREF="#PKIX">PKIX</A>
set of standards, there is a distinction between users of the PKI such as <A HREF="#End Entity">End Entities</A> and
<A HREF="#Relying Party">Relying Parties</A>, and entities responsible for issuing and distributing certificates such as
<A HREF="#Certification Authority">CAs</A> and <A HREF="#Registration Authority">RAs</A>. In a flat PKI such as the
<A HREF="#Web of Trust">web of trust</A> underpinning <A HREF="#Pretty Good Privacy">PGP</A>, there are no entities whose
sole role is to issue certificates; instead users of the PKI certify each other.
</td>
</tr>
<TR>
<TD>
<A name="Registration Authority"></A>Registration Authority
</td>
<td>
An organization responsible for registering new certificate users in a
<A HREF="#Public Key Infrastructure">PKI</A>, e.g. by gathering and verifying information which identifies the
certificate applicant.
</td>
</tr>
<TR>
<TD>
<A name="Revocation"></A>Revocation
</td>
<td>
The term used for asserting that a certificate is no longer valid: for example, because the private key
associated with it has been compromised.
</td>
</tr>
<TR>
<TD>
<A name="Relying Party"></A>Relying Party
</td>
<td>
An entity who relies on the authenticity of a <A HREF="#Public Key">public key</a>.
</td>
</tr>
<TR>
<TD>
<A name="Root Certificate"></A>Root Certificate
</td>
<td>
The certificate of a <A HREF="#Trusted Third Party">trusted third party</a>.
A certificate directly trusted by a <A HREF="#Relying Party">relying party</A>: that is, trust in it is not
established by cryptographic means, but trust in it is the prerequisite for establishing trust in the entity
which the relying party is trying to authenticate.
Trust in a root certificate must be established through <A HREF="#Out Of Band">out of band</A> means. A root certificate may or may not be self signed.
</td>
</tr>
<TR>
<TD>
<A name="Secrecy"></A>Secrecy
</td>
<td>
This means that access to information is controlled: for example, it means that two entities
(e.g. people, machines, processes) are able to communicate with one another without any other entities
being able to access the information communicated, or that an entity may store some information and be
assured that only this entity will be able to access it.
</td>
</tr>
<TR>
<TD>
<A name="SHA-1"></A>Secure Hash Algorithm 1(SHA-1)
</td>
<td>
A widely used <A HREF="#Hash">hash algorithm</a>, producing a 160-bit digest.
</td>
</tr>
<TR>
<TD>
<A name="SSL"></A>Secure Sockets Layer (SSL)
</td>
<td>
Precursor to <A HREF="#Transport Layer Security">TLS</a>. SSL has been through three versions:
the first two are considered insecure, and the third is almost identical to TLS.
</td>
</tr>
<TR>
<TD>
<A name="Server Authentication"></A>Server Authentication
</td>
<td>
In a secure client-server protocol such as <A HREF="#Transport Layer Security">TLS</A>, the process in which the server
<A HREF="#Authentication">authenticates</A> itself to the client, so the client knows who it's talking to.
</td>
</tr>
<TR>
<TD>
<A name="SignText"></A>SignText
</td>
<td>
A function defined in the <A HREF="#WMLScript Crypto API">WMLScript Crypto API</A> which provides application-level
<A HREF="#Authentication">Authentication</A> and <A HREF="#Nonrepudiation">Nonrepudiation</A> for transactions.
</td>
</tr>
<TR>
<TD>
<A name="Stream Cipher"></A>Stream Cipher
</td>
<td>
A class of <A HREF="#Symmetric Cryptography">symmetric algorithm</A> which is initialised with a key,
then outputs a stream of pseudorandom bits.
This 'keystream' is typically XOR-ed with the plaintext to generate the ciphertext.
So they encrypt a bit of plaintext at a time.
</td>
</tr>
<TR>
<TD>
<A name="Symmetric Cryptography"></A>Symmetric Cryptography
</td>
<td>
A form of cryptography in which the same key is used for encryption and decryption
<p>
Symmetric cryptography is fast, but suffers from the problem of how to distribute the key privately.
<A HREF="#Asymmetric Cryptography">Asymmetric cryptography</a> is an attempt to alleviate the key
distribution problem, by reducing the requirement for the distributed key from one of privacy to one of
authentication.
</td>
</tr>
<TR>
<TD>
<A name="Transport Layer Security"></A>Transport Layer Security (TLS)
</td>
<td>
A client-server security protocol providing <A HREF="#Secrecy">secrecy</a> and optionally <A HREF="#Authentication">authentication</a>, and
running over TCP/IP.
<p>In this protocol a client connects to a server; the two then perform a handshake in which they exchange a
<A HREF="#Symmetric Cryptography">symmetric</a> key by using <A HREF="#Asymmetric Cryptography">asymmetric cryptography</a>,
which is then used to encrypt their communications, providing the secrecy element.
<p>Without the authentication element secrecy is not very useful; although only client and server can understand the data
exchanged, the client doesn't know who the server is or vice versa. TLS provides the capability for
<A HREF="#Server Authentication">server authentication</a>, in which the client establishes who the server is, and
<A HREF="#Client Authentication">client authentication</a> in which the server establishes who the client is.
</td>
</tr>
<TR>
<TD>
<A name="Trusted Third Party"></A>Trusted Third Party (TTP)
</td>
<td>
An entity whose public key is known to a <A HREF="#Relying Party">relying party</a> due to its having been
received via <A HREF="#Out Of Band">out of band</A> means, and which is trusted to issue <A HREF="#Public Key Certificate">
public key certificates</A> for other entities not directly known to the relying party.
<p>A <A HREF="#Certification Authority">CA</a> is a type of TTP.
</td>
</tr>
<TR>
<TD>
<A name="Web of Trust"></A>Web of Trust
</td>
<td>
The set of social relationships between users of <A HREF="#PGP">PGP</a> that enables them to sign each others' keys,
essentially providing a <A HREF="#PKI">PKI</a> for this technology.
</td>
</tr>
<TR>
<TD>
<A name="WMLScript Crypto API"></A>WMLScript Crypto API
</td>
<td>
A WAP Forum standard which defines cryptographic functions in WML, the scripting language used in WAP.
It defines a function for creating signed objects called <A HREF="#SignText">SignText</a>
</td>
</tr>
<TR>
<TD>
<A name="WTLS"></A>WTLS
</td>
<td>
A client-server security protocol providing <A HREF="#Secrecy">secrecy</a> and optionally <A HREF="#Authentication">authentication</a>,
running at the transport layer of the WAP stack. WTLS is closely modelled on <A HREF="#Transport Layer Security">TLS</a>,
and defines its own lightweight <A HREF="#Public Key Certificate">certificate</a> format.
</td>
</tr>
<TR>
<TD>
<A name="X.509 Certificate"></A>X.509 Certificate
</td>
<td>
A widely used type of <A HREF="#Public Key Certificate">public key certificates</A>, part of the
now largely moribund X.500 series of standards.
</td>
</tr>
<!--
<TR><TD><A HREF="/rfc2459">RFC 2459</a></td>
<td>PKIX Certificate and CRL Profile<br>
<b>This RFC is being updated by two new Internet draftversions,
<a href="/draftversion-ietf-pkix-new-part1">draftversion-ietf-pkix-new-part1</a>
and <a href="/draftversion-ietf-pkix-ipki-pkalgs">draftversion-ietf-pkix-ipki-pkalgs</a>.</b>
</td>
</tr>
-->
<!--
<TR><TD><A
HREF="/draftversion-ramsdell-role-names">draftversion-ramsdell-role-names</A></TD><TD>Role
Names in X.509 Certificates</TD>
<TD>Expired</TD></TR>
-->
<TR HEIGHT=0><TD WIDTH="35%"></TD><TD
WIDTH="65%"></TD></TR></TABLE></P></center>
</BODY></HTML>