<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-A636C1B3-8AB2-52D7-BB19-4CC93F4BDD97" xml:lang="en"><title>WTLS

Certificates</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>Wireless Transport Layer Security (WTLS) certificates are used for authenticating

entities in WTLS, the security layer protocol in the WAP architecture. The

WTLS specification [WTLS 1.0], defines the certificate and its use, as well

as the protocol itself. </p>

<p>The WTLS protocol is heavily based on TLS [RFC 2246], which is widely used

to provide privacy and data integrity between two applications communicating

using the Internet. In turn, TLS is heavily based on SSL version 3.0. </p>

<p>All these protocols use <xref href="GUID-FB2CAA46-8EBB-5F76-847C-F3B953C9D31C.dita">Public

Key Cryptography</xref> to achieve the goals of privacy and data integrity.

Public Key Cryptography is used to reduce the problem of how to achieve these

goals from a secrecy requirement to a requirement of authentication. That

is, given two entities A and B, if A can demonstrate possession of the private

key corresponding to the public key which it supplies, and B can do the same,

then the use of Public Key Cryptography will enable them to communicate privately. <xref href="GUID-911E9F7E-D0AD-55EC-A3F4-1D427F803780.dita">Certificates</xref> are used

to demonstrate this possession: the prover will supply a set of certificates

beginning with their own, and the verifier will attempt to construct and validate

a chain beginning with the prover's own certificate and terminating in a certificate

already trusted by the verifier. </p>

<p>Three levels of security are provided by WTLS: </p>

<ul>

<li id="GUID-2C63B01D-00D9-5389-904B-FAA13D2EE40D"><p>no authentication: anonymous

key exchange is used for creation of an encrypted channel between server and

client; no authentication takes place, so no certificate management is required. </p> </li>

<li id="GUID-BCAF0499-50FA-5B05-A510-399D0EF855DD"><p>server authentication:

the server provides a certificate mapping back to an entity trusted by the

client, enabling the client to authenticate the server. This is often all

the authentication that is required; for online shopping, for example, the

client will generally authenticate the server but the reverse will often not

be necessary since the client will supply their credit card number to pay

for the stuff, which is all the server usually cares about. </p> </li>

<li id="GUID-48DBD5E5-C833-5FFC-BA2F-DBE1BEB7A84C"><p>client authentication:

the client possesses its own private key and associated public key certificate

which it may use to identify itself to other entities in the network. </p> </li>

</ul>

<p>For server authentication WTLS certificates are used: thus, WAP clients

do not have to deal with X.509 certificates. However, for client authentication

X.509 certificates are used to leverage existing PKIs. </p>

<p>The Symbian platform support for TLS/SSL and WTLS certificate

management only includes server authentication. Thus, the WTLS certificate

management only offers support for the validation of chains composed exclusively

of WTLS certificates, and the storage of WTLS certificates. </p>

<p>The Certificate and Key Management component offers the following functionality

for processing WTLS certificates: </p>

<ul>

<li id="GUID-848C67F6-3B12-535E-AF88-A140DE35E2DE"><p>parses a set of WTLS

certificates sent from the server from their binary encoded form into a form

in which they are useful, and in which client code can extract interesting

information (for example name information). </p> </li>

<li id="GUID-AABA31C8-AD82-526E-B826-205D017B067A"><p>uses these certificates

to construct a chain back to a locally stored trusted root certificate. </p> </li>

<li id="GUID-406CAF57-BDF8-5CC1-A467-59B5568E8732"><p>validates this chain:

this would include verifying the signature and validity dates on each certificate. </p> </li>

<li id="GUID-AF72A928-D50C-585B-8E98-60ED89F78F92"><p>maintains a local store

of certificates, with trust settings for each one, and offering an API to

edit these trust settings, and add and delete certificates. </p> </li>

</ul>

</conbody></concept>