--- a/cryptomgmtlibs/securitydocs/doxygen_docs/Security_glossary.dox Fri Apr 16 16:52:34 2010 +0300
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,615 +0,0 @@
-/**
-@page security_glossary Security glossary
-\n
-A glossary of security terms (mostly non-Symbian specific).
-\n\n
-@ref A, @ref B, @ref C, @ref D, @ref E, @ref F, @ref G, @ref H, @ref I, @ref J, @ref K, @ref L, @ref M, @ref N, @ref O,
-@ref P, @ref Q, @ref R, @ref S, @ref T, @ref U, @ref V, @ref W, @ref X, @ref Y, @ref Z
-\n @anchor A \n
-
-<table>
-
-<tr><td><b>A</b></td><td></td></tr>
-
-<tr><td>@anchor AES AES</td>
- <td>Advanced Encryption Standard -- The new conventional symmetric @ref block_cipher "block cipher" chosen by NIST as a
- replacement for @ref DES. It can process 128-bit data blocks using
- cipher keys with lengths of 128, 192, or 256 bits.</td></tr>
-
-<tr><td>@anchor ASN ASN.1</td>
- <td>Abstract Syntax Notation 1 (See: <A HREF="http://asn1.elibel.tm.fr/en/introduction/index.htm">ASN.1</A>,
- ISO/IEC 8824, and ISO/IEC 8825.) -- A data specification meta-language widely used in @ref public_key_cryptography "public key cryptography"
- standards. (Also of interest: <A HREF="ftp://ftp.rsasecurity.com/pub/pkcs/doc/layman.doc">A Layman's Guide to
- a Subset of ASN.1, BER, and DER</A>.)</td></tr>
-
-<tr><td>@anchor asymmetric @anchor Asymmetric Asymmetric Cryptography</td>
- <td>A form of cryptography in which the 'key' is generated as a key pair: if one key is used for @ref encryption only the
- other can be used to decrypt, and vice versa. \n\n
- Using asymmetric cryptography, the problem of key distribution becomes one of @ref authentication; i.e. how to make sure
- that a given key really does belong to the entity that claims to own it. See:
- @li @ref asymmetric_cryptography
- @li @ref SS_Cryptalg_asymmetric_ciphers.</td></tr>
-
-<tr><td>@anchor attribute_cert 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>@anchor authentication @anchor Authentication 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>
-
-
-
-</table>\n @anchor B \n<table>
-
-<tr><td><b>B</b></td><td></td></tr>
-
-<tr><td>@anchor BER BER</td>
- <td>Basic Encoding Rules for @ref ASN "ASN.1", as defined in X.690. (Also of interest:
- <A HREF="ftp://ftp.rsasecurity.com/pub/pkcs/doc/layman.doc">A Layman's Guide to a Subset of ASN.1, BER, and DER</A>.)
- </td></tr>
-
-<tr><td>@anchor block_cipher Block Cipher</td>
- <td>A class of symmetric algorithm 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 @ref plaintext is split up into appropriately-sized
- blocks and each block is fed into the cipher. </td></tr>
-
-
-
-</table>\n @anchor C \n<table>
-
-<tr><td><b>C</b></td><td></td></tr>
-
-<tr><td>@anchor CA CA</td>
- <td>Certification Authority -- An organisation that performs the following functions in a hierachical @ref PKI:
- @li providing trusted @ref root_certificate "'root' certificates" to users (@ref EE "End Entities"), by supplying them with the CA's @ref public_key "public key" via
- out-of-band means.
- @li certifying End Entities (@ref EE "EE"s) by generating and distributing certificates for them. The certified @ref EE is the
- subject of the @ref certificate; the CA is the issuer. The CA validates the certificate holder's identity and 'signs'
- the @ref certificate so that it cannot be tampered with or forged. The @ref certificate issued by the CA binds a particular
- @ref public_key "public key" to the name of the @ref EE the @ref certificate identifies.
- @li supporting certificate revocation and revocation checking: if an @ref EE suspects that their key has been compromised,
- they can contact the CA that issued it, who will then revoke their @ref certificate.
-
- A CA will always have a root certificate-signing key pair that must be authenticated to End Entities via @ref out_of_band "out of band"
- channels. This key pair is not logically certified by anything, but it is usually distributed inside a self-signed
- @ref certificate to afford some degree of tamper evidency. \n\n
- 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 that in turn are used to certify End Entities. Also, CAs may certify the signing keys
- of other CAs by issuing cross certificates, which enable interoperation between two distinct @ref PKI "PKI"s.</td></tr>
-
-<tr><td>@anchor CA_certificate CA Certificate
- <td>A @ref certificate held by a @ref CA: the key pair associated with it is used for signing certificates issued by that
- @ref CA. May or may not be self-signed.</td></tr>
-
-<tr><td>@anchor CBC CBC</td>
- <td>Cipher Block Chaining -- A cryptographic mode for @ref block_cipher "block ciphers". It is an @ref encryption method that protects
- against block replay attacks by making the encryption of a cipher block dependent on all blocks that precede it.
- Before it is encrypted, the @ref plaintext is XORed with the previous @ref ciphertext block (which has been stored in a
- feedback register). After the encryption, the resulting ciphertext is again stored in the feedback register, to
- be XORed with the next plaintext block, and so on until the end of the message.</td></tr>
-
-<tr><td>@anchor certificate @anchor certificates Certificate</td>
- <td>For our purposes, this is the same thing as a @ref public_key_certificate "public key certificate".</td></tr>
-
-<tr><td>@anchor ciphermode Ciphermode</td>
- <td> description</td></tr>
-
-<tr><td>@anchor ciphertext Ciphertext</td>
- <td>The output of an @ref encryption operation, or the input to a @ref decryption operation.</td></tr>
-
-<tr><td>@anchor CLDC CLDC</td>
- <td><A HREF="http://java.sun.com/products/cldc/">J2ME Connected Limited Device Configuration</A> -- Serves the market consisting of personal, mobile, and
- connected information devices. This configuration includes some new classes designed specifically to fit the
- needs of small-footprint devices.</td></tr>
-
-<tr><td>@anchor client_authentication Client Authentication</td>
- <td>In a secure client-server protocol such as @ref TLS, the process in which the client authenticates itself to
- the server, so the server knows who it's talking to. \n See @ref WTLS_client_authentication "client authentication in WTLS". </td></tr>
-
-<tr><td>Client/User/End Entity Certificate</td>
- <td>A @ref certificate issued by a @ref CA to an end entity, @ref EE, who may use it to demonstrate their
- ownership of the key pair associated with it.</td></tr>
-
-<tr><td>@anchor CRL CRL</td>
- <td>Certificate Revocation List -- A list of (identifiers for) @ref certificates that have been revoked by a
- particular @ref CA. The use of CRLs is for maintaining access to servers in a network, in a @ref PKI; in some cases,
- @ref OCSP has superseded CRL. See:
- @li <A HREF="http://www.ietf.org/rfc/rfc2459.txt">RFC2459</A>
- -- Internet @ref X509 "X.509" @ref PKI Certificate and CRL Profile
- @li <A HREF="http://www.ietf.org/rfc/rfc3279.txt">RFC3279</A>
- -- Algorithms and Identifiers for the Internet @ref X509 "X.509" @ref PKI Certificate and Certificate Revocation List
- (@ref CRL) Profile
- @li <A HREF="http://www.ietf.org/rfc/rfc3280.txt">RFC3280</A>
- -- Internet @ref X509 "X.509" @ref PKI Certificate and Certificate Revocation List (@ref CRL) Profile.
- </td></tr>
-
-<tr><td>@anchor cross_certificate Cross Certificate</td>
- <td>A @ref certificate issued by a @ref CA which certificates another @ref CA's @ref root_certificate "root certificate". This is way of uniting two distinct
- certification hierarchies.</td></tr>
-
-
-
-</table>\n @anchor D \n<table>
-
-<tr><td><b>D</b></td><td></td></tr>
-
-<tr><td>@anchor decryption Decryption</td>
- <td>The process of turning encrypted data (called @ref ciphertext) into the original information (called
- @ref plaintext) using a cryptographic algorithm parameterised with a key.</td></tr>
-
-<tr><td>@anchor DER DER</td>
- <td>Distinguished Encoding Rules -- A set of rules for encoding @ref ASN "ASN.1" data structures as a byte stream, which
- has the property that any given @ref ASN "ASN.1" data structure will always encode to the same byte stream. DER is a
- subset of @ref BER. (Also of interest:
- <A HREF="ftp://ftp.rsasecurity.com/pub/pkcs/doc/layman.doc">A Layman's Guide to a Subset of ASN.1, BER, and DER</A>.)
- </td></tr>
-
-<tr><td>@anchor DES DES</td>
- <td>Data Encryption Standard -- A symmetric @ref block_cipher "block cipher" (that is the U.S. and international standard) used for
- @ref encryption and @ref decryption. A 64-bit block cipher with a 56-bit key organized as 16 rounds of operations. </td></tr>
-
-<tr><td>@anchor digital_signature Digital Signature</td>
- <td>A structure linking some data and a @ref private_key "private key". A digital signature may be generated by the application of a
- private key to some piece of data. The original data may be reconstructed by applying the corresponding @ref public_key "public key",
- demonstrating that the signature could only have been generated by someone with access to the private key.\n\n
- Digital signatures have two primary uses: to demonstrate someone's identity by signing some challenge, as in
- @ref client_authentication "client authentication" in @ref TLS, in which the client signs a @ref hash 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 @ref WMLScript Crypto API SignText function.\n\n
- See: an introduction to @ref Security_signatures.</td></tr>
-
-<tr><td>@anchor DN DN</td>
- <td>Distinguished Name -- An @ref ASN "ASN.1" structure containing various attributes (name-value pairs) that together
- uniquely identify the entity for certification purposes. \n\n
- The name used in @ref X509_certificate "X.509 certificates" is the X.500 Distinguished Name, which describes a path
- through an X.500 Directory Information Tree. Conventionally, a DN comprises <i> at least </i> three attributes: a user's
- name/ID (e.g., \c cn=Fred \c Bloggs), an organization name (e.g., \c o=Symbian \c UK \c Ltd), and a country designation
- (e.g., \c c=GB ).
- </td></tr>
-
-<tr><td>@anchor DSA DSA</td>
- <td>Digital Signature Algorithm -- A NIST-approved @ref asymmetric algorithm. It can only be used for generating
- and verifying @ref digital_signature "digital signatures", not for @ref encryption.
- See: The <A HREF="http://www.itl.nist.gov/fipspubs/fip186.htm">Digital Signature Standard</A>.
- </td></tr>
-
-
-
-</table>\n @anchor E \n<table>
-
-<tr><td><b>E</b></td><td></td></tr>
-
-<tr><td>@anchor ECB ECB</td>
- <td>Electronic Codebook -- A cryptographic mode for @ref block_cipher "block ciphers". It is a mode that encrypts
- blocks of @ref plaintext to corresponding blocks of @ref ciphertext. Given use of the same key, a block of plaintext
- will always encrypt to the same block of ciphertext.</td></tr>
-
-<tr><td>@anchor ECC ECC</td>
- <td>Elliptical Curve Cryptography -- An @ref asymmetric @ref encryption technique based on elliptic curve theory that
- can be used to create faster, smaller, and more efficient cryptographic keys.</td></tr>
-
-<tr><td>@anchor encryption Encryption</td>
- <td>The process of turning meaningful data (called @ref plaintext) into meaningless gibberish (called @ref ciphertext)
- using a cryptographic algorithm parameterised with a key.</td></tr>
-
-<tr><td>@anchor EE EE</td>
- <td>End Entity -- A leaf node in a certification hierarchy: any entity in a @ref PKI which has a @ref certificate, but is
- not allowed to issue its own certificates.</td></tr>
-
-
-
-</table>\n @anchor F \n<table>
-
-<tr><td><b>F</b></td><td></td></tr>
-
-
-
-</table>\n @anchor G \n<table>
-
-<tr><td><b>G</b></td><td></td></tr>
-
-
-
-</table>\n @anchor H \n<table>
-
-<tr><td><b>H</b></td><td></td></tr>
-
-<tr><td>@anchor hash 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 that produce the same output. See:
- @li @ref cryptographic_hash
- @li @ref SS_Cryptalg_hash_algorithms.</td></tr>
-
-<tr><td>@anchor HMAC HMAC</td>
- <td>Keyed-Hashing for Message Authentication -- A mechanism for message @ref authentication using cryptographic hashes. It
- can be used with any iterative cryptographic @ref hash function, e.g., @ref MD5, @ref SHA "SHA-1", in combination with a secret
- shared key. The cryptographic strength of HMAC depends on the properties of the underlying @ref hash function.</td></tr>
-
-
-
-</table>\n @anchor I \n<table>
-
-<tr><td><b>I</b></td><td></td></tr>
-
-<tr><td>@anchor ICC ICC</td>
- <td>Integrated Circuit Card -- A removable card with at least data storage and sometimes processing.</td></tr>
-
-<tr><td>@anchor IPSec IPSec</td>
- <td>IP Security Protocol -- A standard providing @ref secrecy and @ref authentication at the network or
- datagram layer of network communication. IPSec is mandatory in IPv6. \n
- See: <A HREF="http://www.ietf.org/html.charters/ipsec-charter.html">IPSec Working Group</A>.</td></tr>
-
-
-
-</table>\n @anchor J \n<table>
-
-<tr><td><b>J</b></td><td></td></tr>
-
-
-
-</table>\n @anchor K \n<table>
-
-<tr><td><b>K</b></td><td></td></tr>
-
-
-
-</table>\n @anchor L \n<table>
-
-<tr><td><b>L</b></td><td></td></tr>
-
-
-
-</table>\n @anchor M \n<table>
-
-<tr><td><b>M</b></td><td></td></tr>
-
-<tr><td>@anchor MD2 MD2</td>
- <td>Legacy @ref hash algorithm. Considered insecure.</td></tr>
-
-<tr><td>@anchor MD5 MD5</td>
- <td>Legacy @ref hash algorithm. Considered vulnerable.</td></tr>
-
-<tr><td>@anchor message_digest_algorithm Message Digest Algorithm</td>
- <td>Same as a @ref hash algorithm. </td></tr>
-
-<tr><td>@anchor MIDP MIDP</td>
- <td><A HREF="http://www.jcp.org/en/jsr/detail?id=118">Mobile Information Device Profile (JSP-118)</A>.
- -- A set of Java APIs that is generally implemented on the @ref CLDC "Connected Limited Device Configuration" (CLDC).
- It provides a basic J2ME application runtime environment targeted at mobile information devices, such as
- mobile phones and two-way pagers. The MIDP specification addresses issues such as user interface, persistent storage,
- networking, and application model.</td></tr>
-
-
-
-</table>\n @anchor N \n<table>
-
-<tr><td><b>N</b></td><td></td></tr>
-
-<tr><td>@anchor nonrepudiation Non-repudiation</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>
-
-
-
-</table>\n @anchor O \n<table>
-
-<tr><td><b>O</b></td><td></td></tr>
-
-<tr><td>@anchor OAEP OAEP</td>
- <td>Optimal Asymmetric Encryption Padding -- OAEP is a method for encoding messages, and addresses a potential
- vulnerability in <A HREF="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html">PKCS#1</A>. Padding means extra
- bits concatenated with a key, password, or @ref plaintext. @ref Padding helps against dictionary attacks.</td></tr>
-
-<tr><td>@anchor OCSP OCSP</td>
- <td>@ref X509 "X.509" Internet Public Key Infrastructure Online Certificate Status Protocol -- A simple request/response
- protocol. To establish whether a given @ref certificate or list of certificates has/have been revoked, a client forms an
- OCSP request and sends this to an OCSP server. The server maintains revocation information in the form of, say,
- Certificate Revocation Lists (@ref CRL "CRL"s). The server replies to the client with a signed OCSP response, stating for
- each certificate whether the status is Good, Revoked, or Unknown. This response in turn is checked to ensure that it
- is valid, and that it is from an entity trusted for performing revocation checking.
- See:
- @li <A HREF="http://www.ietf.org/rfc/rfc2560.txt">RFC2560</A>
- -- @ref X509 "X.509" Internet @ref PKI Online Certificate Status Protocol - OCSP
- @li @ref overview_OCSP overview. </td></tr>
-
-<tr><td>@anchor OID OID</td>
- <td>Object Identifier -- A universal constant uniquely associated with an object type used in @ref ASN "ASN.1".</td></tr>
-
-<tr><td>@anchor OS OS Element</td>
- <td>A discrete, identifiable entity within a ROM file that implements a set of interfaces. Examples of
- OS Elements include independently instantiable classes within DLLs, bitmaps within an MBM file, resource
- entries within a resource file. An OS Element identifies a part of a ROM file that could in principle be
- factored out or removed if it becomes architecturally advisable.</td></tr>
-
-<tr><td>@anchor out_of_band Out Of Band</td>
- <td>A channel of communication that 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.
- A common example of an out of band channel is a motorcycle courier.
- </td></tr>
-
-
-</table>\n @anchor P \n<table>
-
-<tr><td><b>P</b></td><td></td></tr>
-
-<tr><td>@anchor Padding @anchor padding Padding</td>
- <td>Extending the size of a block of @ref plaintext to, say, a 64-bit block by addition of a regular or random pattern.
- For example, for use with @ref ECB. See:
- @li @ref rsa_padding
- @li @ref symmetric_ciphers.</td></tr>
-
-<tr><td>@anchor PKCS PKCS</td>
- <td><A HREF="http://www.rsasecurity.com/rsalabs/pkcs/index.html">Public-Key Cryptography Standards</A>.</td></tr>
-
-<tr><td><A HREF="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/index.html">PKCS#10</A></td>
- <td>@ref PKI standard that describes how to construct @ref certificate requests.</td></tr>
-
-<tr><td>@anchor PKG PKG file</td>
- <td>A text file that defines a @ref SIS file. The PKG file is passed to the MAKESIS tool to produce the
- @ref SIS file.</td></tr>
-
-<tr><td>@anchor PKI PKI</td>
- <td>Public Key Infrastructure -- A way of modelling real-world trust relationships that enables users of
- @ref public_key_cryptography "public key cryptography" to have confidence in the ownership of the @ref public_key "public keys" they are using. A PKI consists of:
- @li a trusted third party (@ref TTP)
- @li an @ref out_of_band "out of band" means of distributing the @ref TTP's @ref public_key_certificate "public key certificate" to @ref relying_party "relying parties"
- @li a means of distributing other certificates to @ref relying_party "relying parties"
- @li arrangements for the @ref revocation and renewal of these certificates
- @li certificate management and validation software on the @ref relying_party "relying party's" computer
-
- The TTP uses its signing key pair to create certificates for other entities, which relying parties can use to
- authenticate these other entities.
-
- We can classify PKIs according to whether they are hierachical or flat. In hierachical PKIs, such as the one defined
- in the PKIX set of standards, there is a distinction between users of the PKI such as End Entities (@ref EE "EE"s) and
- @ref relying_party "relying parties", and entities responsible for issuing and distributing certificates such as @ref CA "CA"s and
- @ref RA "RA"s. In a flat PKI such as the @ref web_of_trust "web of trust" underpinning @ref PGP, there are no entities whose sole role is
- to issue certificates; instead users of the PKI certify each other. </td></tr>
-
-<tr><td>@anchor PKIX PKIX</td>
- <td>Public-Key Infrastructure (X.509) -- A profile of @ref X509 "X.509" for the internet. See:
- @li @ref Certman_X509_Certificate_Validation
- @li <A HREF="http://www.ietf.org/rfc/rfc2459.txt">RFC2459</A>
- -- Internet X.509 Public Key Infrastructure Certificate and CRL Profile.)</td></tr>
-
-<tr><td>@anchor plaintext Plaintext</td>
- <td>The output of an @ref decryption operation, or the input to a @ref encryption operation.</td></tr>
-
-<tr><td>@anchor PGP PGP</td>
- <td>Pretty Good Privacy -- A very widely-used @ref encryption and digital signing program.</td></tr>
-
-<tr><td>@anchor private_key Private Key</td>
- <td>In the context of @ref public_key_cryptography "public key cryptography", the private half of the key pair.</td></tr>
-
-<tr><td>@anchor public_key Public Key</td>
- <td>In the context of @ref public_key_cryptography "public key cryptography", the public half of the key pair.</td></tr>
-
-<tr><td>@anchor public_key_certificate Public Key Certificate</td>
- <td>A digitally signed structure including at least an identifier for an individual entity and a @ref public_key "public key", whose
- function is to bind the entity with the key. </td></tr>
-
-<tr><td>@anchor public_key_cryptography Public Key Cryptography</td>
- <td>A common application of @ref asymmetric cryptography in which one half of the key pair is kept secrect
- (the @ref private_key "private key") and the other half is published (the @ref public_key "public key"). See:
- @li @ref asymmetric_cryptography
- @li @ref Security_intro_PKC.</td></tr>
-
-
-
-</table>\n @anchor Q \n<table>
-
-<tr><td><b>Q</b></td><td></td></tr>
-
-
-
-</table>\n @anchor R \n<table>
-
-<tr><td><b>R</b></td><td></td></tr>
-
-<tr><td>@anchor RA Registration Authority</td>
- <td>An organization responsible for registering new @ref certificate users in a @ref PKI, e.g. by gathering and verifying
- information which identifies the @ref certificate applicant.</td></tr>
-
-<tr><td>@anchor revocation Revocation</td>
- <td>The term used for asserting that a @ref certificate is no longer valid: for example, because the @ref private_key "private key"
- associated with it has been compromised.</td></tr>
-
-<tr><td>@anchor relying_party Relying Party</td>
- <td>An entity who relies on the authenticity of a @ref public_key "public key".</td></tr>
-
-<tr><td>@anchor root_certificate Root Certificate</td>
- <td>The @ref certificate of a @ref TTP "trusted third party". A certificate directly trusted by a @ref relying_party "relying party"
- 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 @ref out_of_band "out of band" means. A root certificate may or may not be self signed.\n\n
- See: @ref certman_certstore_root_cert_management.</td></tr>
-
-<tr><td>@anchor RSA <A HREF="http://www.rsasecurity.com/rsalabs/rsa_algorithm/index.html">RSA</A></td>
- <td>A @ref public_key "public key" algorithm used for both @ref encryption and @ref digital_signature "digital signatures", named after its creators:
- Rivest, Shamir, and Adleman.</td></tr>
-
-
-</table>\n @anchor S \n<table>
-
-<tr><td><b>S</b></td><td></td></tr>
-
-<tr><td>@anchor secrecy 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>@anchor SHA SHA-1</td>
- <td>Secure Hash Algorithm 1 -- A widely used @ref hash algorithm, producing a 160-bit digest. </td></tr>
-
-<tr><td>@anchor server_authentication Server Authentication</td>
- <td>In a secure client-server protocol such as @ref TLS, the process in which the server authenticates itself to the
- client, so the client knows to whom it's talking. \n See: @ref WTLS_server_authentication "Server authentication in WTLS".</td></tr>
-
-<tr><td>@anchor SignText SignText</td>
- <td>A function defined in the @ref WMLScript Crypto API that provides application-level @ref authentication and
- @ref nonrepudiation "non-repudiation" for transactions. </td></tr>
-
-
-<tr><td>@anchor SIS SIS file</td>
- <td>A binary package file containing all the files for an installation, as well as metadata describing which
- directory to install them into, dependencies, etc..\n
- See: @ref overview_SWI overview.</td></tr>
-
-<tr><td>@anchor Stub SIS Stub file</td>
- <td>A @ref SIS file containing only the metadata, and not the files. After the installation, this file is archived
- on the device for uninstallation purposes, etc..</td></tr>
-
-<tr><td>@anchor SMIME S/MIME</td>
- <td><A HREF="http://www.ietf.org/html.charters/smime-charter.html">Secure/Multipurpose Internet Mail Extensions</A>
- -- Provides a consistent way to send and receive secure MIME data. S/MIME provides the following cryptographic
- security services for electronic messaging applications: @ref authentication, message integrity and @ref nonrepudiation "non-repudiation" of
- origin (using @ref digital_signature "digital signatures") and privacy and data security (using @ref encryption); see
- <A HREF="http://www.ietf.org/rfc/rfc2633.txt">RFC2633</A> -- S/MIME Version 3 Message Specification.
- </td></tr>
-
-<tr><td>@anchor SSL SSL</td>
- <td>Secure Sockets Layer -- A protocol for securing network connections that provides @ref authentication, @ref encryption, and
- data integrity using @ref PKI "Public Key Infrastructure" (PKI). Precursor to @ref TLS. SSL has been through three versions:
- the first two are considered insecure, and the third is almost identical to @ref TLS.</td></tr>
-
-<tr><td>@anchor stream_cipher Stream Cipher</td>
- <td>A class of symmetric algorithm that is initialised with a key, then outputs a stream of pseudorandom bits.
- This 'keystream' is typically XOR-ed with the @ref plaintext to generate the @ref ciphertext. So they encrypt a bit of
- plaintext at a time. </td></tr>
-
-<tr><td>@anchor symmetric_cryptography Symmetric Cryptography</td>
- <td>A form of cryptography in which the same key is used for @ref encryption and @ref decryption.\n\n
- Symmetric cryptography is fast, but suffers from the problem of how to distribute the key privately. @ref Asymmetric
- cryptography is an attempt to alleviate the key distribution problem, by reducing the requirement for the distributed
- key from one of privacy to one of @ref authentication. See:
- @li @ref symmetric_ciphers
- @li @ref SS_Cryptalg_symmetric_ciphers.</td></tr>
-
-
-</table>\n @anchor T \n<table>
-
-<tr><td><b>T</b></td><td></td></tr>
-
-<tr><td>@anchor TLS TLS</td>
- <td>Transport Layer Security -- A protocol that provides communications secrecy, and optionally @ref authentication,
- over the Internet TCP/IP. The protocol allows client/server applications to communicate in a way that is designed to
- prevent eavesdropping, tampering, or message forgery.
-
- In this protocol a client connects to a server; the two then perform a handshake in which they exchange a
- symmetric key by using @ref asymmetric cryptography, which is then used to encrypt their communications,
- providing the @ref secrecy element. Without the @ref authentication element, @ref 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 @ref WTLS_server_authentication "server authentication", in which the client establishes who the server is, and
- @ref client_authentication "client authentication" in which the server establishes who the client is. \n\n
- See: <A HREF="http://www.ietf.org/rfc/rfc2246.txt">RFC2246</A> --
- The TLS Protocol). TLS is the successor to the @ref SSL "Secure Sockets Layer" (SSL). (Also, see: @ref WTLS.)</td></tr>
-
-<tr><td>@anchor TTP TTP</td>
- <td>Trusted Third Party -- An entity whose @ref public_key "public key" is known to a @ref relying_party "relying party" due to its having been received
- via @ref out_of_band "out of band" means, and which is trusted to issue @ref public_key_certificate "public key certificates" for other entities not directly
- known to the relying party. A @ref CA is a type of TTP. </td></tr>
-
-
-</table>\n @anchor U \n<table>
-
-<tr><td><b>U</b></td><td></td></tr>
-
-<tr><td>@anchor URI URI</td>
- <td>Uniform Resource Identifier -- A way to identify some content on the Internet, typically through the use of an
- identifier for the scheme (e.g. HTTP) through which the content may be accessed, and an identifier for the
- content that makes sense within that scheme.
- The most common form of URI is a Web page address, which is a particular form or subset of URI called a Uniform
- Resource Locator (URL).</td></tr>
-
-
-
-</table>\n @anchor V \n<table>
-
-<tr><td><b>V</b></td><td></td></tr>
-
-
-
-</table>\n @anchor W \n<table>
-
-<tr><td><b>W</b></td><td></td></tr>
-
-<tr><td>@anchor WAP WAP</td>
- <td></td><A HREF="http://www.wapforum.org/index.htm">Wireless Application Protocol</A> -- A secure specification
- that enables users to access information instantly using devices such as mobile phones, pagers, two-way radios,
- smartphones and communicators. The WAP defines a set of protocols in transport, security, transaction, session, and
- application layers to enable the creation of advanced mobile services.</td></tr>
-
-<tr><td>@anchor web_of_trust Web of Trust</td>
- <td>The set of social relationships between users of @ref PGP that enables them to sign each others' keys, essentially
- providing a @ref PKI for this technology.</td></tr>
-
-<tr><td>@anchor WIM WIM</td>
- <td><A HREF="http://www.wmlclub.com/docs/especwap2.0/WAP-260-WIM-20010712-a.pdf">Wireless Identity Module</A>
- -- Used in performing @ref WTLS and application level security functions, and especially, to store and process
- information needed for user identification and @ref authentication. Examples of WIM implementations are a Subscriber
- Identity Module (SIM) card or an external smart card.</td></tr>
-
-<tr><td>@anchor WMLScript WMLScript Crypto API</td>
- <td>A @ref WAP Forum standard that defines cryptographic functions in WML, the scripting language used in @ref WAP.
- It defines a function for creating signed objects called @ref SignText.</td></tr>
-
-<tr><td>@anchor WTLS WTLS</td>
- <td><A HREF="http://www.wmlclub.com/docs/especwap2.0/WAP-261-WTLS-20010406-a.pdf">Wireless Transport Layer Security</A>
- -- The security layer of the @ref WAP, providing privacy, data integrity and @ref authentication for WAP services.
- It is a @ref WAP variant of @ref TLS and defines its own lightweight @ref certificate format. \n\n
- See: @ref overview_WTLS overview. </td></tr>
-
-<tr><td>@anchor WTLS_certificate WTLS certificate</td>
- <td>@ref WAP variant of @ref X509_certificate "X.509 certificates".\n\n
- See: @ref overview_WTLS overview.</td></tr>
-
-
-</table>\n @anchor X \n<table>
-
-<tr><td><b>X</b></td><td></td></tr>
-
-<tr><td>@anchor X509 X.509</td>
- <td>A widely used standard for digital certificates. See:
- @li @ref Certman_X509_Certificate_Validation
- @li <A HREF="http://www.ietf.org/rfc/rfc2459.txt">RFC2459</A>
- -- Internet @ref X509 "X.509" @ref PKI Certificate and @ref CRL Profile
- @li <A HREF="http://www.ietf.org/rfc/rfc3280.txt">RFC3280</A>
- -- Internet @ref X509 "X.509" @ref PKI Certificate and @ref CRL "Certificate Revocation List" Profile.
- </td></tr>
-
-<tr><td>@anchor X509_certificate X.509 certificate</td>
- <td>A widely used type of @ref public_key_certificate "public key certificate", part of the now largely moribund X.500 series of standards.\n\n
- An X.509 certificate is a person's/company's @ref public_key "public key" digitally signed by a trusted third party and wrapped with
- attribute data such as identifying names. A hierarchy of certificates is often used tracing back to a single root
- @ref CA_certificate "CA certificate". If a user trusts the @ref CA, then they can trust that the @ref certificate belongs to the
- person/company given within the certificate. Using the public key within the certificate, they can then verify that
- other data has originated from the certificate owner via the use of @ref digital_signature "digital signatures" created using the corresponding
- @ref private_key "private key". @ref X509 "X.509" basically defines the certificate format.</td></tr>
-
-
-
-</table>\n @anchor Y \n<table>
-
-<tr><td><b>Y</b></td><td></td></tr>
-
-
-</table>\n @anchor Z \n<table>
-
-<tr><td><b>Z</b></td><td></td></tr>
-
-<tr><td>@anchor zlib zlib</td>
- <td>zlib is designed to be a free, general-purpose, legally unencumbered (i.e., not covered by any patents) lossless
- data-compression library for use on virtually any computer hardware and operating system. zlib was written by
- Jean-loup Gailly (compression) and Mark Adler (decompression). See:
- @li <A HREF="http://www.ietf.org/rfc/rfc1950.txt">RFC1950, zlib format</A>
- @li <A HREF="http://www.ietf.org/rfc/rfc1951.txt">RFC1951, deflate format</A>
- @li <A HREF="http://www.ietf.org/rfc/rfc1952.txt">RFC1952, gzip</A>.</td></tr>
-
-</table>
-*/