BACKGROUND OF THE INVENTION In operations requiring security, e. g. vari- ous electronic business transactions, it is necessary that the parties be able to electrically verify their identity in order to use selected services. This veri- fication of identity can be implemented e. g. by em- ploying a user identifier and an associated password or by using a special certificate. To enable the veri- fication of identity, the user must first register himself in order to obtain a certificate as described above.

'Digital certificate'or'electronic iden- tity'refers to data or a file that is unambiguously used for the identification of people and various re- sources via a telecommunication network, such as the Internet. When electronic mail applications are used, certificates are typically transmitted as an attach- ment to an e-mail message. However, the digital cer- tificate is not signed even if the e-mail message is additionally provided with a digital signature. Digi- tal certificates also enable a secure and confidential connection between two parties. Digital certificates are issued by a trusted third party (TTP, Trusted Third Party), such as e. g. a Certificate Authority (CA). The function of the trusted third party is to verify the identity of certificate holders and to sign the certificate so that it cannot be altered without the change being discovered. After the trusted third

party has signed the certificate, the owner of the certificate can present it to other people or parties to prove-his identity and to establish encrypted tele- communication connections.

Typically, the certificate contains informa- tion relating to its owner and to the party having is- sued the certificate. The certificate contains e. g. the following information. Name of the owner and other possible information identifying the owner, electronic mail address and public key. A public signing key con- tained in the certificate can be used for the verifi- cation of signatures. Moreover, the certificate con- tains e. g. the name and identification number of the party having publicized the certificate and time data defining the period of validity of the certificate.

To create a digital certificate, the trusted third party signs it digitally. The signature makes it impossible to alter the contents of the certificate without the change being discovered. Digital certifi- cates are generally based on Public Key Cryptography (PKC), which is based on the use of a public key and a secret key. In the public key method, the use of the public key and the use of the secret key are heavily interdependent. Using a public signing key, it is pos- sible to verify a digital signature which has been made by utilizing a secret signing key.

The public key can be freely publicized and distributed to any parties that may desire to have it, but the secret key has to be kept in a safe place that cannot be accessed by any other parties. A digital certificate links the public key with the identity verified by a trusted third party.

Theoretically, the certificates are not con- text-dependent, but in practice different certificates are needed for different uses. For example, a standard X. 509 certificate contains no e-mail address data, which is needed for secure transmission of e-mail mes-

sages (e. g. PGP or S/MIME). Similarly, certain appli- cations may require the inclusion of specific attrib- utes in the certificate.

In existing PKI (Public Key Infrastructure) applications, the end user's digital signature and the verification of this signature often occur at differ- ent times and at different locations. The end user signs messages which do not reveal the signer's iden- tity. The end user identity associated with the signa- ture is only interpreted after the message has been received in the data system of a service producer. The end user cannot be completely certain about which cer- tificate is used to verify his identity even if a cer- tificate verified with a signature has been attached to the message sent to the service producer. It is possible that the same public key has been certified with more than one certificate by more than one CA.

However, there is no statutory obligation that would compel the service producer to use expressly that cer- tificate which was sent as an attachment. In addition, there are PKI applications in which it is not possible to send a digital certificate along with a message to a service producer. Thus, the message can be after- wards interpreted in several ways differing from each other. Below is a list of problematic situations cur- rently encountered.

1. If the end user's public key has been cer- tified with certificates issued by more than one CA, then it is impossible to know which one of them should be used to prove the end user's identity. One certificate may be used on one day and another'certifi- cate on the next day. Thus, the message is not unambiguous.

2. If the end user's public key has been cer- tified with several certificates issued by different CA's, then there is no way to

know which CA should be held liable to com- pensate for a loss.

3. If a new certificate for public keys is created afterwards for the time at which a transaction took place, then the message can be interpreted according to this new certificate.

4. If the end user's public key has been cer- tified with several, conflicting role- specific certificates (e. g. work, private and anonymous certificates), then his iden- tity may be later confused.

5. The end user's public key has been certi- fied with several digital certificates. One of them is revoked while the other certifi- cates remain valid. The problem is whether a service provider can use one of the valid certificates instead of the revoked one if he originally intended to use the revoked certificate.

6. In principle, it is possible for anyone to assume the role of a CA and award certifi- cates.

In short, the problem is that the end user cannot be totally confident about which certificate is used to verify his identity.

A further problem is that the customer soft- ware applications in all terminals, especially port- able and wireless terminals, do not necessarily have sufficient resources for generating and maintaining several key pairs.

The present system does not allow the same user to have several different roles when the same key is used in the services provided by the same service provider.

There are systems in which the keys are gen- erated to a data medium (e. g. a smart card) by another

party before the data medium comes into the end user's possession. In such systems, the secret signing key cannot be activated before its public counterpart has been verified with a certificate. Otherwise there is a theoretical risk that an unreliable party might use the signature before a certificate has been created and that these signatures could be later regarded as having been made by the party that acquired the cer- tificate.

OBJECT OF THE INVENTION The object of the present invention is to eliminate the drawbacks referred to above or at least to significantly alleviate them. A specific object of the invention is to disclose a new type of method that will make it possible to define for an entity a cer- tificate to be used for the interpretation of the identity of the entity.

BRIEF DESCRIPTION OF THE INVENTION The present invention relates especially to applications which do not have sufficient resources for maintaining and processing user certificates and the associated public keys in conjunction with digital signatures.

The invention concerns a method for limiting the interpretation of the identity of an entity. Ac- cording to the invention, one or more digital certifi- cates are defined for the public key of the entity.

The validity of the certificate may be limited accord- ing to the number of times the certificate is used or according to the length of time it is used. Thus, it is possible to define certificates that are valid for a very short time, e. g. a few seconds or a few hours, or certificates that can be used e. g. only once.

'Entity'preferably refers to a juridical person. However, this term may also be used to refer to something else than a juridical person, e. g. to a device or a computer program. There are preferably several certificates defined for the same public key of the entity. Each certificate may represent a given identity or role defined for the entity. Two or more certificates may also represent the same identity or role. The entity's digital certificate or data indi- cating the digital certificate to be used is attached to a digital document generated by the entity. The data indicating the digital certificate to be used preferably is a hash code generated from an actual certificate.

The digital document is signed digitally, said digital document comprising at least a digital certificate of the entity or data indicating the digi- tal certificate to be used. This is to say that the certificate used or the data indicating the certifi- cate used is included in the digital signature. How- ever, the digital document is not signed in the event that the certificate in the digital document is false or the data indicating the certificate in the message refers to a wrong certificate. The entity is verified by the aid of the certificate indicated by the digital document bearing a digital signature. As there may be several certificates defined for the entity, the digi- tal document unambiguously indicates which certificate is to be used for verifying the entity. To allow the entity to ascertain that the digital document contains the right certificate, it can be shown to the entity before the digital signature is made. To the digital document signed by the entity, it is possible to add a time stamp and/or certificate and/or digital signature given by a trusted third party.

In an embodiment of the invention, a time stamp and/or certificate and/or digital signature

given by a trusted third party is added to the digital document before the document is signed by the entity.

In an embodiment of the invention, the en- tity's actions are carried out by means of a mobile station and/or a subscriber identity module connected to a mobile station.

The invention also concerns a method for lim- iting the interpretation of the identity of an entity between contracting parties, in which method two or more entities establish a service relationship and de- cide about the structure and content of messages to be used during the service relationship.'Service rela- tionship'may refer e. g. to a service relationship that only comprises a single transaction.

According to the invention, one or more digi- tal certificates are defined for the public key of the entity. The validity of the certificate may be limited according to the number of times the certificate is used or according to its utilization time. Thus, it is possible to define certificates having a very short validity period, e. g. a few seconds or a few hours, or certificates that can be used e. g. only once.'Entity' preferably refers to a juridical person, but it may also refer to something else than a juridical person, e. g. to a device or a computer program. Preferably there are several certificates defined for the entity and the same public key. Each certificate may repre- sent an identity or role defined for the entity. Two or more certificates may also represent the same iden- tity or role. The contracting parties have previously decided which digital certificate is to be used for verifying the identity of the entity. This decision may be made jointly or separately. The decision re- garding the certificate to be used for the verifica- tion is made e. g. in conjunction with the establish- ment of the service relationship. Thus, it will be

possible to eliminate any attempts to verify the iden- tity of the entity using a wrong certificate.

For each contracting party signing the agree- ment, a digital certificate or data indicating the digital certificate to be used is added to every agreement message consistent with the message struc- ture used between the entity and the receiver of the agreement message.'Receiver of the agreement message' preferably refers to another entity.'Data indicating the digital certificate to be used'preferably refers to a hash code generated from the actual certificate.

The service relationship may require that one of the entities sends to another entity an agreement message consistent with the message structure defined in the agreement. The message structure contains for each signing party a certificate or data indicating the digital certificate to be used. If the entity is a de- vice, it may still desire to make sure about its own certificate or the certificates of the other parties.

The certificate or certificates can be displayed to the entity before the digital signature is made. Thus, the entity can make sure that the right certificate is used to verify his identity. At the same time, the en- tity can check and accept the certificates of the other entities signing the agreement that are added to the agreement message.

The agreement message is signed digitally be- fore being sent to the receiver of the agreement mes- sage, which, for each contracting party signing the agreement, comprises at least a digital certificate or data indicating the digital certificate to be used.

This is to say that the certificate used or the data indicating the digital certificate used is within the digital signature. However, the agreement is not signed if it contains the wrong certificate or no cer- tificate at all.

The entity is verified by the aid of the cer- tificate indicated by the digitally signed agreement message. As there may be several certificates defined for the entity, the agreement message unambiguously indicates which certificate is to be used for the verification of each entity. A time stamp and/or cer- tificate and/or digital signature given by a trusted third party can be added to the agreement message signed by the contracting parties.

In an embodiment of the invention, a time stamp and/or certificate and/or digital signature given by a trusted third party is added to the agree- ment message before the agreement message is sent to the contracting parties.

In an embodiment of the invention, the mes- sage received is rejected if it does not contain a predetermined certificate or data indicating a prede- termined certificate. Further, the agreement message can be rejected if it has been signed using a differ- ent key than the key indicated by the certificate.

In an embodiment of the invention, a confir- mation message concerning the agreement made is sent to the contracting parties.

In an embodiment of the invention, they en- tity's actions are carried out by means of a mobile station and/or a subscriber identity module connected to a mobile station. The communication between the en- tity and the service provider is preferably transmit- ted in a short message in a mobile communication net- work.

The present invention makes it possible for a contracting party to ascertain which other parties are going to sign the agreement. The contracting party can also ascertain who is going to be used as a certifier of the agreement (notary).

The present invention enables the user to make sure that the right certificate is used for the

verification of his identity, because the data indi- cating the certificate to be used is included in the message between the user and the receiver of the agreement message. As a decision is made beforehand as to the certificate to be used to verify the user's identity, the message sent will only be valid accord- ing to a given certificate even if alternative cer- tificates should be available. The invention makes it possible to define the responsibilities and obliga- tions associated with the certificate so that they only pertain to a single CA even if the same key has been certified by more than one CA.

The invention makes it possible to specify in advance which trusted third party is to be used to certify the agreement.

The invention makes it possible to use a plu- rality of identities or roles with the same public key in the services provided by the same service provider.

LIST OF ILLUSTRATIONS In the following, the invention will be de- scribed in detail by the aid of a few examples of its embodiments, wherein Fig. la represents a method according to the invention, Fig. 1b represents a method according to the invention, and Fig. 2a and 2b present a preferred example of a signal flow diagram in which the method of the in- vention is used.

DETAILED DESCRIPTION OF THE INVENTION Fig. la describes the operation of the method of the invention. The required actions are preferably carried out using a mobile station (MS) and/or a sub- scriber identity module (SIM) connected to the mobile

station. The choice of the terminal to be used is in no way restricted to a mobile station; instead, the terminal may be any other device that comprises the properties required by the invention.

According to block 1, one or more digital certificates are have been defined for the public key of an entity.'Entity'preferably means a juridical person. However,'entity'may be also be used to refer to something else than a juridical person, e. g. a de- vice or a computer program. Each digital certificate defined for the entity may represent an identity or role of the entity (e. g. company identity, personal identity). Two or more certificates may also represent the same identity or role. Creating different digital certificates for the same public key obviates the ne- cessity to create a new public key for each certifi- cate. Some of the digital certificates created may be very short-lived as regards the validity period or the number of times they can be used (e. g. certificate us- able only once or valid for only a few seconds or hours). Therefore, it would not be very practical to create a separate public key for each digital certifi- cate.

The digital certificate or data indicating the digital certificate to be used is added to each digital document generated by the entity, block 2.

'Data indicating the digital certificate to be used' preferably refers to a hash code generated from the actual certificate. Such a hash code is generated by using a special function, e. g. SHA1 (SHA, Secure Hash Algorithm). The hash code contains an unambiguous string of characters that is considerably shorter than the original input data. The generation of the hash code is a one-way operation, so it is not possible to make any conclusions about the original input data from the hash code.

According to block 3, the digital document generated by the entity is signed digitally. For digi- tal signature, e. g. the public key method (PKI, Public Key Infrastructure) and the RSA algorithm (RSA, Rivest, Shamir, Adleman) are used. The RSA algorithm may be replaced with any other algorithm that can be used in the public key method. In the case of a human entity, the certificate can be presented to the user before the digital signature is made. In this way it is possible to ensure that the right digital certifi- cate is used for the verification of the user's iden- tity. A time stamp and/or certificate and/or digital signature given by a trusted third party can be added to the digital document before the entity signs the digital document. A time stamp and/or certificate and/or digital signature given by a trusted third party can also be added to the digital document after the digital document has been signed by the entity.

According to block 4, the entity is verified by means of the digital certificate indicated by the digital document signed with a digital signature.

Fig. 1b describes the operation of the method of the invention. In the example in Fig. lb, it is as- sumed that two or more entities have entered into a service relationship and decide about the message structure and content to be used during the service relationship. In this example, the entity is a person who uses an appropriate terminal. However,'entity' may also refer to something else than a human being, e. g. a device or a computer program. In this example, the words'entity'and'user'mean the same thing.

The actions carried out by the user are pref- erably accomplished using a mobile station and/or a subscriber identity module connected to a mobile sta- tion. User terminals are by no means restricted to a mobile station; instead, the terminal may be any other device that comprises the properties necessary for the

invention. One or more of the entities may be a spe- cific service provider, which preferably is a party that provides services defined in the agreement to the user. The service provider is e. g. a travel agency, a bank or an organ of public administration, but it may also be any other party which has the necessary re- sources for communicating with the user and his termi- nal.

According to block 5, one or more digital certificates have been defined for the public key of the entity. In this example it is assumed that several digital certificates differing from each other have been defined for the user's public key. Each certifi- cate may represent a given identity or role of the user (e. g. company identity, personal identity). Two or more certificates may also represent the same iden- tity or role. As several digital certificates differ- ing from each other are created for the same public key, the necessity of creating a new public key for each certificate is now avoided. The use of a single public key is a considerable advantage especially in small portable terminals that do not have enough re- sources for maintaining and processing the user's digital certificates and the associated keys. Further, some of the digital certificates created may be very short-lived in respect of their validity period or the number of times they can be used (being usable e. g. only once or having a validity period of a few seconds or a few hours). Therefore, it would not be very prac- tical to create a separate public key for each digital certificate.

The contracting parties have previously de- cided which digital certificate is to be used for the verification of the user's identity, block 6. The de- cision regarding the digital certificate to be used for verification is made e. g. in conjunction with the establishment of the service relationship. The deci-

sion may be made jointly or separately. Thus, it is possible to make sure that the user's identity is al- ways verified using the right digital certificate.

The digital certificate or data indicating the digital certificate to be used for each contract- ing party is attached to each agreement message con- sistent with the message structure used between the user and the receiver of the agreement message, block 7. The receiver of the agreement message may be a spe- cific service provider. The data indicating the digi- tal certificate to be used is preferably a hash code generated from the actual certificate. Such a hash code is generated using a special function, e. g. the SHA1. The hash code contains an unambiguous string of characters that is considerably shorter than the original input data. The generation of the hash code is a one-way operation, so it is not possible to make any conclusions about the original input data from the hash code. Moreover, a time stamp and a digital signa- ture of the party giving the time stamp may be added to the signed agreement message.

For the service relationship it may be re- quired that the service provider send the user an agreement message consistent with the message struc- ture defined in the agreement. The message structure contains for each contracting party signing the agree- ment a digital certificate or data indicating the digital certificate to be used. Before the digital signature is made, the digital certificate may be pre- sented to the user. Thus, the user can make sure that the right digital certificate is used for the verifi- cation of his identity. At the same time, the entity can verify and accept the certificates of the other entities signing the agreement that are associated with the agreement message.

According to block 8, the user signs the agreement message digitally before the message is sent

to the other entity or to a specific service provider.

The digital signature is made using e. g. the public key method and the RSA algorithm. The RSA algorithm may be replaced with any other algorithm that can be used in the public key method. A time stamp and/or certificate and/or digital signature given by a trusted third party can be added to the agreement mes- sage before the agreement message is sent to the con- tracting parties. Thus, each signer of the agreement message can see that the agreement message containing the digital certificates of the contracting parties has been certified.

The service provider verifies the user by the aid of the digital certificate indicated by the digi- tally signed agreement message, block 9. The service provider can easily verify that the digital signature associated with the message corresponds to the cer- tificate defined in the agreement. If an unreliable party sends a message in which there is a conflict be- tween the signature and the digital certificate, then the message can be automatically rejected. A time stamp and/or certificate and/or digital signature given by a trusted third party can be added to the agreement message signed by the contracting parties.

In an embodiment according to Fig. lb, the certificates of all the signing parties are added to the basic agreement before the signatures. Alterna- tively, data indicating the digital certificate to be used may be added to the basic agreement. Such data is e. g. a hash code generated from the certificate. In this example, the agreement transaction comprises three contracting parties (A, B and C). One or more of the parties (A, B or C) may be a service provider who provides services or products mentioned in the agree- ment to the other parties. However, it is not strictly necessary for any one of the contracting parties to

act as a specific service provider in the agreement transaction.

Before signing the agreement, party A can as- certain who are the other parties whose digital signa- tures will be included in the agreement. Upon receiv- ing the agreement signed by A, party B signs the en- tire document created during the previous stage, com- prising the basic agreement, the certificates of the contracting parties and the signature of the previous party having signed the agreement. Thus, B accepts the signature of A. Party C acts in a corresponding man- ner, signing the agreement already signed by A and B.

The signatures can be made at different times and in different places in a secure manner as the interpreta- tion of the identity of the signatories has been lim- ited beforehand. The agreement will not be considered valid if it has been signed using a key other than the one indicated by the certificate. In addition, the signed agreement can be sent to a trusted third party, e. g. to a notary service, which verifies the signa- tures of the parties and the validity of the certifi- cates. After this, a time stamp and/or the digital signature of the trusted third party can be added to the agreement.

In an embodiment according to Fig. lb, the certificates of all the signing parties entering into agreement are added to the basic agreement before the signatures. Alternatively, data indicating the digital certificate may be added to the basic agreement. Such data is e. g. a hash code generated from the certifi- cate. In this example, the agreement transaction com- prises four contracting parties (A, B, C and D). One or more of the parties (A, B, C or D) may be a service provider who provides services or products mentioned in the agreement to the other parties. However, it is not strictly necessary for any one of the contracting

parties to act as a specific service provider in the agreement transaction.

Before signing the agreement, party A can as- certain who are the other parties whose digital signa- tures will be included in the agreement. An agreement corresponding to that sent to A is also sent to B and C. Likewise, B and C can check the certificates in- cluded in the agreement to see which other parties are going to sign an identical agreement. However, the agreement message sent to B or C is not the agreement message previously signed by A. D signs an agreement message that contains the digital signatures of both A, B and C as well as the digital certificates of all the signatories. The arrangement described above works in a star-like manner. This is to say that each con- tracting party has a separate identical message which is signed by each party. Party D is at the center of the star and receives the signed agreement messages and generates an agreement message that contains the digital certificates and digital signatures of all the contracting parties. In addition, the signed agreement can be sent to a trusted third party, e. g. to a notary service, which verifies the signatures of the parties and the validity of the certificates. After this, a time stamp and/or the digital signature of the trusted third party can be added to the agreement.

An alternative solution regarding the role of D could be that D signs the agreement message just as A, B and C do. After A, B and C have sent the agree- ment messages signed by them to D, D sends all four signed messages to a trusted third party. The latter generates an agreement message containing the digital certificates and signatures of all the contracting parties and finally adds his own certificate and/or a time stamp and/or his own digital signature to the agreement message.

In an embodiment according to Fig. lb, the certificates of all the signing parties are added to the basic agreement before the signatures. Alterna- tively, data indicating the digital certificate may be added to the basic agreement. Such data is e. g. a hash code generated from the certificate. In this example, the agreement transaction comprises four contracting parties (A, B, C and D). One or more of the parties (A, B, C or D) may be a service provider who provides services or products mentioned in the agreement to the other parties. However, it is not strictly necessary for any one of the of the contracting parties to act as a specific service provider in the agreement trans- action.

Before signing the agreement, party A can as- certain who are the other parties whose digital signa- tures are to be included in the agreement. B, C and D have their own agreements corresponding to that sent to A. Likewise, B and C and D can check the certifi- cates included in the agreement to see which other parties are going to sign an identical agreement.

Thus, each contracting party has an identical message, which is signed digitally by each party.

A, B, C and D send the signed agreement mes- sage directly to a trusted third party. The arrange- ment described above works as a star-like structure with the trusted third party at its center. The trusted third party receives the agreement message signed by each contracting party and verifies the sig- natures of the contracting parties and the validity of the certificates of the signatories. The trusted third party generates an agreement message containing the digital certificates and digital signatures of all the contracting parties and adds a time stamp and/or his own digital signature to the agreement message thus generated.

In an embodiment according to Fig. lb, the agreement transaction comprises three contracting par- ties: a payer, a bank and a payee. The payer has a ba- sic agreement form that he can use to pay invoices.

The payer fills in the identification and account data for the payer and the payee, possible bank reference or other additional data as well as the sum payable in the basic agreement form. Moreover, the payer adds his own digital certificate or alternatively data indicat- ing a digital certificate to the basic agreement form.

Such data is e. g. a hash code generated from the digi- tal certificate. The digital certificate or the data indicating a digital certificate may also be included in the basic agreement form beforehand by the bank.

After all the required information has been added to the basic agreement, the payer signs the agreement message thus generated by putting his digital signa- ture to it and sends the signed agreement message to the bank.

The bank verifies the payer by the aid of the certificate indicated by the digitally signed agree- ment message. If this payer verification yields a positive result, then the bank will execute the ac- tions required for the payment of the bill. The bank may send the agreement message signed by the payer to a trusted third party, e. g. a notary service, which adds to the agreement message a time stamp and/or a digital signature of the trusted third party.

In an embodiment according to Fig. lb, before the agreement message is sent to the contracting par- ties for signature, the agreement message is sent to a trusted third party, which adds to the agreement mes- sage his own digital certificate and/or time stamp and/or digital signature. The trusted third party can verify the certificates in the agreement message be- forehand. The procedure described above allows the parties to ascertain that the certificates of all the

parties entering into agreement are valid. This proce- dure also lets the contracting parties know which trusted third party has verified the agreement message and the digital certificates of the parties. If one of the contracting parties does not accept the trusted third party to be used, then that party can refuse to sign the agreement and thus prevent its conclusion.

After the contracting parties have signed the agree- ment message, the trusted third party adds a time stamp and/or a digital signature to the agreement mes- sage. Thus, the final agreement message carries two signatures of a trusted third party. It is not neces- sary to use the same trusted third party for the first and the second signatures to be added to the agreement message. Therefore, it is possible to use a first trusted third party to verify the agreement message before the addition of the signatures of the parties and a second trusted third party to verify the final agreement message containing the digital certificates and digital signatures of all the contracting parties signing the agreement.

In the above examples according to Fig. lb, each contracting party can be sent a copy of the final agreement. Thus, each contracting party can e. g. file the agreement thus concluded or prove if necessary that he has made a given agreement.

Figures 2a and 2b present a preferred example of a signalling flow diagram in which the method of the invention is applied. The example according to Fig. 2a and 2b comprises a PKI party PKI, a user and his terminal ME, a local certificate authority LRA (CA, Certificate Authority) and a service provider SP.

The term ME in this example refers to the user, or to the user and the terminal equipment at his disposal.

The service provider SP may be a mobile communication operator or any other party. In this example,'user's terminal equipment'means a mobile station and the

subscriber identity module connected to the mobile station, but this is by no means intended to limit the application of the invention exclusively to mobile stations; instead, any other terminal may be used.

'PKI party PKI'refers to a party which channels and guarantees PKI services and which helps the user of services to find the desired services and warrants the reliability of many service providers SP by his own signature. The small arrows in Fig. 2a and 2b indicate the order of occurrence of the actions in the proce- dure.

According to block 20, the user ME requests that a certificate be generated. The user's mobile station or the subscriber identity module connected to it contains a predefined public key, for which he now wants to have a new certificate generated. The new certificate is to be generated e. g. as a"company" certificate, whereas a previously generated certifi- cate represents the user's"personal"certificate. The local certificate authority LRA receives the request sent by the user ME, block 21. The local certificate authority LRA checks the user data and the network identity (NID) associated with the user, block 22.

'Network identity'preferably means identity data com- prising encryption and/or signing keys attached to it at the time of its generation.

The local certificate authority LRA generates a writ and encrypts it using the public key indicated by the network identity associated with the user ME, block 23. The user ME receives the writ and decrypts it using his own secret key, block 24. The user ME further signs the writ using his own secret signing key and sends the signed writ back to the local cer- tificate authority LRA, block 25. The local certifi- cate authority LRA receives the signed message and verifies the signature, block 26. If the message is successfully verified, then the local certificate

authority LRA sends to the certificate authority CA a request to generate and publicize a certificate, block 27. The certificate authority receives the request and publicizes the user's certificate, blocks 28 and 29.

The publicized certificate is then sent to the local certificate authority LRA, block 30.

Fig. 2b carries the example presented in Fig.

2a further. According to block 31, the user ME sends a service request (SIR, Service Initialization Request) to the PKI party PKI. The service request may contain a certificate associated with the user or data indi- cating the certificate to be used for the verification of the user in conjunction with the desired service.

The PKI party PKI receives the request and generates a certificate relating to the service provider SP, signs it and sends it to the user ME, blocks 32 and 33. Ac- cording to block 34, the user ME receives the certifi- cate relating to the service provider SP that was sent by the PKI party PKI and stores it in his mobile sta- tion. The PKI party PKI transmits the service request sent by the user further to the service provider SP, block 35.

The service provider SP receives the service request, block 36. The user ME and the service pro- vider SP may have previously decided which digital certificate is to be used for the verification of the user in conjunction with each service. After the serv- ice provider SP has received the service request, it asks the certificate authority CA for a certificate relating to the user ME, incorporates it in the mes- sage to be sent to the user ME and sends the message it has generated to the user ME, blocks 37,38 and 39.

'Message generated'denotes e. g. a kind of blank mes- sage form in which the user ME later fills in the re- quired information.

According to block 40, the user ME receives the message form containing the certificate relating

to the user ME. If the user thinks that the certifi- cate contained in the message form is a false one or the message form contains no certificate at all, then the user ME will reject the message received. The cer- tificate can be presented to the user ME e. g. on the display of his mobile station to allow the user to make sure about the certificate. The user ME fills in the required information in the message form, puts his digital signature to the message generated and sends the service request to the service provider SP, block 41. All acceptable digital signatures are only made on message forms received by the user ME that already contain the certificate to be used for the verifica- tion of the user's ME identity.

The service provider SP receives the message sent by the user ME and compares the digital signature attached to the message, the certificate contained in the message and the certificate obtained from the cer- tificate authority CA to establish whether they are congruent, blocks 42,43 and 44. Based on these, the service provider determines whether the service re- quest received by the service provider SP is accept- able or not, block 45.

The user generates, sends and receives the messages according to the above-described example preferably via a mobile station. The messages gener- ated and received by the user are preferably short messages in a mobile communication network. Thus, the user preferably communicates with the other parties in the example via the mobile communication network. How- ever, this is only one example of a possible terminal and telecommunication network that may be used.

The invention is not restricted to the exam- ples of its embodiments described above; instead, many variations are possible within the scope of the inven- tive idea defined in the claims.