12 <concept xml:lang="en" id="GUID-A636C1B3-8AB2-52D7-BB19-4CC93F4BDD97"><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>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>

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

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

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

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

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

    17 as the protocol itself. </p>

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

    19 to provide privacy and data integrity between two applications communicating

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

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

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

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

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

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

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

    27 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

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

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

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

    31 already trusted by the verifier. </p>

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

    33 <ul>

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

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

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

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

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

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

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

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

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

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

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

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

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

    47 </ul>

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

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

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

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

    52 management only includes server authentication. Thus, the WTLS certificate

    53 management only offers support for the validation of chains composed exclusively

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

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

    56 for processing WTLS certificates: </p>

    57 <ul>

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

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

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

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

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

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

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

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

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

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

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

    69 </ul>

    70 </conbody></concept>