WAP PKI and certification path validation. Cristina Satizábal* Rafael Páez and Jordi Forné

Transcription

1 88 Int. J. Internet Protocol Technology, Vol. 2, No. 2, 2007 WAP PKI and certification path validation Cristina Satizábal* Department of Engineering and Architecture, Pamplona University, Km 1 via Bucaramanga, Pamplona, Colombia isabelcs@entel.upc.edu *Corresponding author Rafael Páez and Jordi Forné Department of Telematics Engineering, Technical University of Catalonia, C/Jordi Girona 1-3 C3, 08034, Barcelona, Spain rpaez@entel.upc.edu jforne@entel.upc.edu Abstract: The fast evolution of mobile communications and their convergence with internet make necessary to adapt the security services to this new environment. WPKI (Wireless Application Protocol Public Key Infrastructure) can provide these services, but the features of the mobile devices make it a difficult task, especially for complex processes such as the certification path validation that requires long time and resources. In this paper, we show the limitations of WPKI from the verifier s point of view and determine the computational cost and storage capacity required by a verifier, with a mobile terminal, to carry out a certification path validation process when different revocation mechanisms are used. Keywords: security services; public key infrastructure; PKI; digital certificates; certification path validation; revocation mechanisms; wireless application protocol PKI; WPKI; computational cost; storage capacity. Reference to this paper should be made as follows: Satizábal, C., Páez, R. and Forné, J. (2007) WAP PKI and certification path validation, Int. J. Internet Protocol Technology, Vol. 2, No. 2, pp Biographical notes: Cristina Satizábal received her Degree in Electronic and Telecommunications Engineering from Cauca University (Colombia) in Currently, she is part of the Department of Engineering and Architecture of Pamplona University (Colombia) and she is carrying out a PhD in Telematics Engineering at the Technical University of Catalonia (Spain). She finished the phases of teaching and research and currently she is in the Thesis development phase. Her research interest includes Public Key Infrastructure (PKI), Privilege Management Infrastructure (PMI) and Intrusion Detection Systems (IDS). Rafael Páez is a Systems Engineer (2001), and he carried out graduate studies in security of data processing networks (2002) at the Catholic University of Colombia. He has surpassed the phase of teaching and research and currently he is in the thesis development phase of the PhD in Telematics Engineering at the Technical University of Catalonia (Spain). His research interest is the security of data processing networks, especially Intrusion Detection Systems (IDS), Public Key Infrastructure (PKI), Privilege Management Infrastructure (PMI) and perimeter security. He has been the author and speaker of national and international papers during his PhD. Jordi Forné received the MS and PhD in Telecommunications Engineering from the Technical University of Catalonia (Spain) in 1992 and 1997, respectively. Currently, he is an Associate Professor at the Telecommunications Engineering School, Technical University of Catalonia, Barcelona, Spain. He has been working in cryptography and information security for the last 15 years. His research interests include network and multimedia security, electronic commerce and Telematics services. Copyright 2007 Inderscience Enterprises Ltd.

2 WAP PKI and certification path validation 89 1 Introduction In the last few years, the boom of telecommunications has had two main protagonists: internet and the mobile communications. Nowadays, it is searched the convergence of these two worlds, so that they can benefit each other. The introduction of Wireless Application Protocol (WAP) (WAP Forum, 2001b) and the technological evolution needed to pass from Global System for Mobile Communications (GSM) to General Packet Radio Service (GPRS) and Enhanced Datarates for GSM Evolution (EDGE) (Olofsson and Furuskar, 1998) have approximated the mobile telephony to internet. But it is necessary to adapt the security services to this new environment, where the limited capacity of mobile devices and the air characteristics are a challenge for the researchers. The results of their efforts are the development of Wireless Markup Language (WML) (WAP Forum, 2001e), Wireless Transport Layer Security (WTLS) (WAP Forum, 2001f), etc. Also, PKI (ITU-T, 2000) has its own interpretation in the wireless world: WPKI (WAP Forum, 2001c). Certification path validation is a complex process in PKI, and therefore in WPKI, because it involves: discovering the certification path, retrieving the certificates, checking the signatures of the certificates and verifying the expiration and revocation status of the certificates. Thus, the verifier must have certain storage and processing capacities that some mobile devices do not have. This paper is centred on WPKI and its limitations from the verifier s point of view when a certification path is validated. In Section 2, we mention the limitations of the wireless communications and the problems that they represent for WPKI. Also we describe the certification path validation process and the standard certificate revocation mechanisms. Section 3 specifies the number of cryptographic operations that take place during a certification path validation and their computational cost. In Section 4, we determine the storage capacity that a verifier must have to validate a certification path. Finally, Section 5 concludes. 2 Background 2.1 Limitations of wireless communications There are serious problems that make the convergence of mobile technology and internet difficult. One is the bandwidth of wireless networks that is narrower than in wired networks. However, this limitation tends to disappear with the arrival of 3G and 4G to the wireless communications. On the other hand, somebody in the coverage area, with the appropriate equipment, can listen to any communication, what is called eavesdropping. Thus, air is less secure than wire. Another problem is the coexistence of two different systems with a big number of users: WAP (WAP Forum, 2001b) and imode ( p_s/imode/). Interoperability requires a solid and popular standard. In any case, the main limitations are imposed by the client terminals. Mobile devices must be small and portable because of their high mobility. Thus, they have little storage and processing capacities and their content must adapt to small screens. In addition, these terminals have an autonomous battery with limited life. An increase in processor load or data to be transmitted over the air reduces the battery life. Also, if a transaction is interrupted because the battery goes flat or the mobile user is out of coverage, the security protocols must support it. 2.2 WPKI (Wireless Application Protocol PKI) WPKI (WAP Forum, 2001c) is an optimised extension of the traditional PKI for the wireless environment. It has optimised: the protocols (they use WML (WAP Forum, 2001e) and WMLScript (WAP Forum, 2001g)), the format of the certificates (WTLS certificates (WAP Forum, 2001f)) and the cryptographic algorithms and keys (Elliptic Curve Cryptography ECC (Certicom Research, 2000). The goal of the WAP PKI is to reuse existing PKI standards where available, and only develop new standards where necessary to support the specific requirements of WAP. The general model adopted in the current version of WPKI is, according to WAP Forum (2001c): WTLS Server and Root CA certificates stored in the device will be according to WTLSCertificate defined in WAP Forum (2001f) client certificates (WTLS and application) and CA Roots stored in servers will be according to X.509 as profiled in Housley et al. (1999) client certificates (WTLS and application) and CA Roots which are to be sent over the air and/or stored in WAP client devices will be according to X.509 as profiled in WAP Forum (2001a) storage of the certificate URL in the device, rather than the full client certificate, is the preferred model, when X.509 format certificates would otherwise be expected to be transferred over the air storage of X.509 client certificates in the device is expected to be the exception, unless they are provisioned on the device, through the WIM (Wireless Identity Module) (WAP Forum, 2001d) for example. WPKI requires the same components used in traditional PKI: Certification Authorities (CAs), Registration Authorities (RAs), End Entities (EEs), PKI Directories (DIRs); and adds a new component, called PKI Portal. The PKI Portal is responsible for translating requests made by the WAP client to the RA and CA in the PKI. The PKI Portal will typically embed the RA functions and interoperate with the WAP devices on the wireless network and the CAs on the wired network (Figure 1).

3 90 C. Satizábal, R. Páez and J. Forné Figure 1 WPKI architecture Verifying the Validity of the Certificates: It is to determine if the certificates have expired or have been revoked. The certificate s validity period is used to verify the expiration, while the revocation status depends on the revocation mechanism used. 2.4 Revocation mechanisms 2.3 Validation of certification paths According to Housley et al. (1999), a Certification Path is a chain of Public Key Certificates (PKCs) through which a user can obtain the public key of another one. The primary goal of a path validation is to verify the binding between an entity and a public key. Then, the verifier must check the signature and validity of each certificate in the path in order to trust the public key of the target entity. A trust anchor is the CA verification key used by the client application as the starting point for all certificate validation. Thus, the path is traced from the verifier s trust anchor to the CA key required to validate the target entity s certificate. The certification path length is equal to the number of certificates in the path that is the number of CAs in the path plus one: a CA certificate per each intermediary CA and the target entity s certificate. Since, the verifier knows and trusts the public key of its trust anchor, the trust anchor s certificate is not included in the path. According to WAP Forum (2001a), certificate-processing clients must support a certification path length of at least three (i.e., two intermediary CA certificates between the trust anchor and the target entity). The path validation process also determines the set of certificate policies that are valid for a path. In general, path validation process involves the following steps: Discovering a certification path: It is to set up a trusted path between the verifier s trust anchor and the target entity based on the trust relationship among the CAs of the PKI. Retrieving the certificates: It is to retrieve each certificate in the path from the directories where they are stored. Verifying the digital signatures: It is to verify the validity of the digital signature of each certificate in the path. It involves: 1 decrypting the signed part of the certificate with its issuer s public key 2 calculating a hash of the certificate s content 3 comparing the results of 1 and 2. If they are the same then the signature is valid. Certificate revocation is the mechanism under which an issuer can revoke the binding between an entity and a public key before the expiration of the corresponding certificate. A certificate can be revoked because of the loss or compromise of the associated private key, in response to a change in the owner s access rights, a change in the relationship with the issuer, etc. The standard certificate revocation mechanisms are CRL (ITU-T, 2000) and OCSP (Myers et al., 1999). CRL (Certificate Revocation List) In 1988, ITU-T introduced CRLs in its X.509 Recommendation (ITU-T, 2000). A CRL is a list of serial numbers of revoked certificates together with their date and reason of revocation. CRLs are periodically issued and signed by a CA. Then, they are published in non-trusted repositories. To obtain the revocation status of a certificate, the verifier must retrieve the corresponding CRL from a repository, validate the issuer s certification path of this CRL and verify the CRL signature. The certificate is revoked if its serial number is found in the CRL. OCSP (Online Certificate Status Protocol) OCSP was adopted by IETF in 1999 (Myers et al., 1999). It specifies a protocol used to determine the current validity status of a certificate online. To obtain the revocation status of one or more certificates, the verifier must send a simple request to a trusted entity called OCSP responder. This request contains: the OCSP protocol version, the type of required service and one or more certificate identifiers. A certificate identifier consists of the hash of the issuer s Distinguished Name (DN), the hash of the issuer s public key and the certificate serial number. In its response, the OCSP responder sends the revocation status of those certificates back to the verifier, with their respective identifiers and the validity period of the response. This response is digitally signed by the OCSP responder. Status good implies the certificate is not revoked, but it may also not be issued yet or even the time at which the response is produced is not within the validity of the certificate. Status revoked means the certificate has been revoked, while status unknown means the server does not have the information available about the required certificate.

4 WAP PKI and certification path validation 91 Before accepting the signed response, the verifier must check the validity of the OCSP responder s certificate and the OCSP response signature. 2.5 WPKI problems One of the WPKI problems is the storage and management of X.509 certificates in the client devices due to the limited capacity of mobile terminals. The size of a X.509 certificate can be very large (up to 2 KB). Therefore, the storage capacity of a SIM or a WIM card can be insufficient for the device. On the other hand, the client must send the whole certificate whenever he or she is authenticated, then it is necessary much bandwidth. A solution is the use of X.509 certificates of limited size (up to 700 bytes) (WAP Forum, 2001a), so that they can be transmitted over the air or stored in a device. Another solution is to pass certificate URLs over the air rather than the client certificates, which saves bandwidth and allows the client certificate to be retrieved by the relying parties. However, denial-of-service attacks are possible if a user voluntarily sends false or non-existent certificate URLs. Also, the limited resources of mobile devices make unfeasible to use the standard certificate revocation mechanisms, based on repositories and responders, because they imply great storage and processing capacities. Thus, WAP technology does not include the revocation concept but it recommends issuing short-lived certificates (48 hours). The management of these certificates can be a problem because there is an overlap period in which a new short-lived certificate and the preceding short-lived certificate are both valid. This requires that the wireless devices have a sufficiently accurate clock and ideally, knowledge of the time zone, since certificates validity is normally expressed relative to UTC time (Universal Time Coordinated). On the other hand, a policy based on the use of short-lived certificates may expose the server to denial-of-service attacks (e.g., if the attacker tries to flood the server) (WAP Forum, 2001c). 3 Computational cost of the verifier In this section, we calculate the computational cost of a verifier, with a mobile terminal, during a certification path validation process, when the standard revocation mechanisms are used. Thus, we determine the processing capacity required by a mobile device to carry out such process and the influence of the revocation mechanisms. Table 1 shows the notation used in this paper from now on. Many types of operations take place in certification path validation (i.e., cryptographic operations, look-up tables operations, transmission operations), but the cryptographic operations require more processing time because of their complexity. We define the computational cost of the verifier like the CPU time consumed by the cryptographic operations in a certification path validation process. Hash and public key encryption operations are cryptographic operations and as we pointed out in Section 2.3, the verifier must carry out this type of operations to check the signature and revocation status of the certificates in the path. Equation (1) shows how the computational cost is calculated. COST = (OP T ) + (OP T ) (1) Table 1 Notation L hash hash pub pub Notation Meaning Certification path length R Number of repositories/responders consulted by the verifier to determine the revocation status of the certificates in the path OP hash Number of hash operations OP pub Number of public key encryption operations T hash Runtime of a hash operation T pub Runtime of a public key encryption operation COST Computational Cost RCert Number of revoked certificates CRL size Size (bytes) of a CRL Cnt CRL Size (bytes) of the CRL content Sig CRL Size (bytes) of the CRL signature ReqOCSP Size (bytes) of an OCSP request Cnt Req Size (bytes) of the OCSP request content RespOCSP Size (bytes) of an OCSP response Cnt Resp Size (bytes) of the OCSP response content Sig Resp Size (bytes) of the OCSP response content OCSP size Size of all OCSP requests and OCSP responses involved in a path validation process ECC algorithms are used to improve the performance of the mobile terminals. However, although ECDSA (Elliptic Curve Digital Signature Algorithm) (ANSI, 1999) is faster than Rivest Shamir Adleman (RSA) (Rivest et al., 1978) to perform digital signatures, RSA is faster to perform signature verifications (Tillich and Grobschädll, 2004). For that reason, we use RSA-1024 as public key algorithm and SHA-1 as hash function. Table 2 shows their runtime obtained from (Argyroudis et al., 2004). These speed benchmarks are from a PDA Compaq ipaq H3630. They ran on a StrongARM 206 MHz processor with 32MB RAM (16MB ROM) and under the operating system Windows CE Pocket PC Table 2 Algorithm SHA-1 RSA-1024 Verification Runtime of cryptographic operations on a PDA Compaq IPAQ H3630 Runtime T hash = 0.19 ms/operation T pub = 5.01 ms/operation In the calculation of the verifier s computational cost, we consider two cases: in the first case, there is not implemented any revocation mechanism so the verifier must

5 92 C. Satizábal, R. Páez and J. Forné not check the revocation status of each certificate in the path, because the CAs issue short-lived certificates, and in the second case, we introduce the standard revocation mechanisms CRL and OCSP in the validation process. 3.1 First case: without revocation In this case, the verifier carries out cryptographic operations to check the digital signature of the certificates in the path. Each signature verification involves a hash and a public key encryption operation. If the path length is L then they are necessary L hash operations and L public key encryption operations to verify all the certificates in the path. Table 3 shows the computational cost of the verifier in this case. We use equation (1) and Table 2 to obtain this cost. Table 3 Number of cryptographic operations and computational cost Revocation Operations mechanism OP hash OP pub Computational cost None L L L CRL L + R L + R L R OCSP 3L + R L + R L R Revocation with OCSP: If an OCSP responder delivers the revocation information of all certificates in the path, the verifier checks the signature of each certificate (L hash operations and L public key encryption operations), and makes two hash operations per certificate (hash of issuer s DN and hash of issuer s public key) to create the OCSP request, that is, 2L hash operations. Also, the verifier must check the signature of the OCSP response that implies a hash and a public key encryption operation (we omit the cryptographic operations derived from the verification of the OCSP responder s certificate validity). The number of hash and public key encryption operations increases when the verifier must consult more than one OCSP responder to determine the revocation status of the certificates in the path. In this case, the verifier must check the signature of several OCSP responses during the validation process. If the verifier sends an OCSP request to R responders, 1 R L, then R hash operations and R public key encryption operations are needed to verify the signature of the OCSP responses. Table 3 shows the computational cost of the verifier in this case. We use equation (1) and Table 2 to obtain this cost. Table 4 shows the computational cost when the certification path length L is increased. We consider the minimum and maximum value of R in each case. 3.2 Second case: with revocation Table 4 Computational cost with and without revocation Now, we evaluate the computational cost of the verifier when the standard certificate revocation mechanisms are used in WPKI. Revocation with CRL: If all the certificates of the path belong to the verifier s trust anchor certification domain, their revocation information is in the CRL retrieved periodically by the verifier. If the certification path validation takes place before the next CRL update, the verifier has already checked the CRL signature when the process starts, so that it only checks the signature of the certificates in the path during the validation process (L hash operations and L public key encryption operations). However, when the certificates do not belong to the verifier s trust anchor certification domain, the verifier must check the signature of several CRLs and also validate the issuers certification paths of such CRLs (for the sake of simplicity, we omit the cryptographic operations derived from the validation of such paths). CRL signature verification implies a hash operation and a public key encryption operation. If the verifier must consult R repositories to obtain the revocation information of all certificates in the path, with L being the maximum number of repositories consulted during the path validation (one per each certificate in the path), 0 R L, then the verifier makes L + R signature verification operations: L operations over the certificates in the path and R operations over the CRLs with the revocation information of the certificates. Table 3 shows the computational cost of the verifier in this case. We use equation (1) and Table 2 to obtain this cost. Path length (L) Computational Cost (ms) Without With CRL With OCSP revocation R = 0 R = L R = 1 R = L According to Table 4, the computational cost with OCSP is greater than with CRL. This is caused mainly by the number of hash operations, since the verifier must carry out more hash operations to create the OCSP requests (Table 3). The difference between the computational cost with OCSP (R = 1) and with CRL (R = 0) is more remarkable than when R = L, where the computational cost with the two revocation mechanisms is very similar. The difference in both cases (minimum and maximum value of R) increases slightly when the path length L goes up. Even so, the calculated computational cost in all the cases is reasonable for the PDA Compaq ipaq H3630 (Argyroudis et al., 2004). Nevertheless, PDAs usually have

6 WAP PKI and certification path validation 93 much more powerful processor and more memory compared with other mobile devices such as smart cards and mobile telephones, of which the runtime of a signature verification operation is much longer, as Table 5 shows (Tillich and Grobschädll, 2004). Table 5 RSA-1937 signature verification execution time in mobile telephones Device First execution (ms) Average (ms) Nokia Nokia Ericsson P Siemens S Storage capacity of the verifier Since the size of the certificates is a problem for the mobile devices in WPKI and the solution is the use of X.509 certificates of limited size, we used this type of certificates to evaluate the storage capacity that a verifier needs to carry out a certification path validation process, with and without revocation. For that reason, we consider the verifier s certificate and the target entity s certificate are like the client certificate of example D.1 in (WAP Forum, 2001a), whose size is 425 bytes. Also, we consider the CAs certificates are like the CA certificate of example D.2 in WAP Forum (2001a), whose size is 473 bytes. In the calculation of the verifier s storage capacity, we consider the same two cases of the Section First case: without revocation A verifier reaches the maximum storage capacity needed during a validation process after retrieving all the certificates in the path. In that moment, the verifier stores the next information: its own certificate: 425 bytes the trust anchor s certificate: 473 bytes the certificates in the path: (L 1) of 473 bytes corresponding to the intermediary CAs and one of 425 bytes corresponding to the target entity. We omit the set of variables needed to carry out the signature and validity verification of the certificates because their size is small. Table 7 shows the storage capacity of the verifier in this case. 4.2 Second case: with revocation Revocation with CRL: In this case, it is added to the information in Section 4.1, the size of the CRL that the verifier retrieves periodically. The size of the CRL content depends on the number of revoked certificates (RCert), as it is showed in Table 6 (CRL size ). We use the CRL of the example C.4 in Housley et al. (2002), whose size is 203 bytes of which 32 bytes correspond to the revocation information of one certificate. The size of this CRL is showed in equation (2). CRL size = (32 RCert) (2) When the certificates of the path do not belong to the verifier s certification domain, several CRLs are retrieved during the validation process. Thus, if each CRL has the size specified in equation (2), the storage capacity of the verifier depends on the number of repositories R consulted by the verifier during the path validation, where 0 R L. Table 7 shows the storage capacity of the verifier in this case. Table 6 Size of the CRL and OCSP data structures Formulas CRL size = (Cnt CRL RCert) + Sig CRL ReqOCSP = Cnt Req L RespOCSP = (Cnt Resp L) + Sig Resp Table 7 Revocation mechanism None CRL OCSP Storage capacity Storage capacity L L R + 32 RCert R L R Revocation with OCSP: Here, in addition to the information specified in Section 4.1, the verifier stores the OCSP request and the OCSP response needed to determine the revocation status of the certificates in the path. Table 6 shows how the size of an OCSP request (ReqOCSP) and an OCSP response (RespOCSP) are calculated. We determined the size of this data structures based on its syntax (Myers et al., 1999) and the fields size of the certificate in example C.2 of (Housley et al., 2002). If the optional fields are omitted, the approximated size of an OCSPRequest with the information of one certificate is 48 bytes, and the approximated size of a BasicOCSPResponse is 189 bytes, of which 74 bytes correspond to the revocation status of one certificate (Cnt Resp ). Therefore, if only one OCSP request is necessary to consult the revocation status of the L certificates in the path, the size of an OCSP request and its OCSP response is: ReqOCSP = 48 L (3) RespOCSP = (74 L) (4) However, sometimes several OCSP requests must be sent to different OSCP responders to determine the revocation status of the certificates. Therefore, the storage capacity needed to store all OCSP requests and responses depends on the number of responders R (1 R L) consulted by the verifier during the validation process as follows: OCSPsize = 48 L+ (115 R+ 74 L) (5) OCSP = 115 R+ 122 L size

7 94 C. Satizábal, R. Páez and J. Forné Table 7 shows the storage capacity of the verifier in this case. Table 8 shows the storage capacity when the certification path length L is increased. The maximum and minimum values of R are considered in each case. Table 8 Storage capacity with and without revocation Storage capacity (KB) With CRL R = L, Rcert = 1000 With OCSP R = L, Rcert = 5000 R = 1 R = L Path Without length (L) revocation R = According to Table 8, the verifier requires more storage capacity with CRL (R = L) than with OCSP (R = L). In addition, this storage capacity is greatly influenced by the CRLs size. Thus, when the amount of revoked certificates is 5000, the storage capacity with CRL is greater than 1 MB for L > 7. These values surpass the current capacity of the SIM cards in the mobile telephones that have to store also the whole operating system and user applications. On the other hand, Table 8 shows that the verifier requires big storage capacity with CRL when the number of revoked certificates is increased, in spite of the use of X.509 certificates of limited size. In addition, the transmission of this great amount of information is difficult because of the limited bandwidth. Also, the storage capacity of the verifier with CRL surpasses 32 KB and this is the capacity of many SIM cards of mobile telephones currently, because today s SIM cards were designed to store text-based data such as phone numbers or SMSs. Then, in the emerging 3G mobile communications world, SIM cards will need to offer greater storage capacity and much faster communication between the SIM card and the mobile phone. In addition, the results suggest that a reduction of the number of public key encryption operations would turn OCSP in the most appropriate revocation mechanism for WPKI, since the great storage capacity needed by CRL make unfeasible its use with the current mobile telephones and smart cards. Future research will be centred on the evaluation of other aspects of the path validation such as the influence of the different PKI architectures in this process. Also, it is important to search efficient mechanisms that decrease the requirements as to the storage and processing capacity of the mobile devices during the certification path validation and introduce some revocation mechanism in WPKI. Thus, PKI technology will adapt to the needs of the mobile users more and more. Acknowledgement This work has been supported by the Spanish Research Council under the project ARPA (TIC C02-02). 5 Conclusions and future research The certification path validation process requires certain storage and processing capacities that can exceed the features of the mobile devices, especially when this process involves the use of some revocation mechanism. The difference between both standard revocation mechanisms in Table 3 is the number of hash operations, but these operations have little influence in the computational cost of the verifier (Table 4) because their runtime is smaller than the runtime of the public key encryption operations (Table 2). Although the calculated computational cost in all the cases is reasonable for the PDA Compaq ipaq H3630 (Argyroudis et al., 2004), PDAs usually have much more powerful processor and more memory compared to mobile telephones and smart cards. Thus, if the cryptographic algorithms are executed on smart cards, as the current security specifications suggest (for example (WAP Forum, 2001d)), the processing capacity may be an issue, since the processor in smart cards cannot handle heavy computations. References ANSI (1999) Public key cryptography for the financial services industry: the elliptic curve digital signature algorithm (ECDSA), ANSI X Argyroudis, P.G., Verma, R., Tewari, H. and O Mahony, D. (2004) Performance analysis of cryptographic protocols on handheld devices, Proceedings of the Third International Symposium on Network Computing and Applications (NCA 04), pp Certicom Research (2000) Standards for Efficient Cryptography SEC 1: Elliptic Curve Cryptography Version 1.0, Certicom Corporation, September. Housley, R., Polk, W., Ford, W. and Solo, D. (1999) Internet X.509 public key infrastructure certificate and CRL profile, RFC 2459, January. Housley, R., Polk, W., Ford, W. and Solo, D. (2002) Internet X.509 public key infrastructure certificate and certificate revocation list (CRL) profile, RFC 3280, April. ITU-T (2000) Information processing systems: open systems interconnection: the directory: authentication framework (technical corrigendum), ITU-T Recommendation X.509, March.

8 WAP PKI and certification path validation 95 Myers, M., Ankney, R., Malpani, A., Galperin, S. and Adams, C. (1999) X.509 internet public key infrastructure online certificate status protocol: OCSP, RFC2560, June. Olofsson, H. and Furuskar, A. (1998) Aspects of introducing EDGE in existing GSM networks, Proceedings of the IEEE 1998 International Conference on Universal Personal Communications (ICUPC 98), Vol. 1, pp Rivest, R.L., Shamir, A. and Adleman, L.M. (1978) A method for obtaining digital signatures and public key cryptosystems, Communications of the ACM, Vol. 21, No. 2, pp Tillich, S. and Grobschädll, J. (2004) A survey of public-key cryptography on J2ME-enabled mobile devices, Proceedings of the 19th International Symposium on Computer an Information Sciences (ISCIS 2004), pp WAP Forum (2001a) WAP certificate and CRL profiles, Specification WAP-211-WAPCert a, May. WAP Forum (2001b) Wireless application protocol architecture specification, Specification WAP-210-WAPArch , July. WAP Forum (2001c) Wireless application protocol public key infrastructure specification, Specification WAP-217-WPKI a, April. WAP Forum (2001d) Wireless identity module part: security, Specification WAP-260-WIM a, July. WAP Forum (2001e) Wireless markup language version 2.0, Specification WAP-238-WML a, September. WAP Forum (2001f) Wireless transport layer security, Specification WAP-261-WTLS a, April. WAP Forum (2001g) WMLScript crypto library, Specification WAP-161-WMLScriptCrypto a, June. Website What s i-mode?,