Mercurial Mercurial > oss > FCL > sf > os > security / diff
summary | shortlog | changelog | graph | tags | bookmarks | branches | files | changeset | file | latest | revisions | annotate | diff | comparison | raw | help
Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
cryptomgmtlibs/securitydocs/Security_Glossary.html
changeset 8 35751d3474b7
parent 0 2c201484c85f 
--- a/cryptomgmtlibs/securitydocs/Security_Glossary.html	Tue Jul 21 01:04:32 2009 +0100
+++ b/cryptomgmtlibs/securitydocs/Security_Glossary.html	Thu Sep 10 14:01:51 2009 +0300
@@ -1,718 +1,718 @@
-<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>
+<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>
FCL/sf/os/security