This document, The Recommended Security Policy for GSM/UMTS Compliant Devices is an addendum to the Mobile Information Device Profile (MIDP) version 2.0 for the JavaTM 2 Platform, Micro Edition (J2METM).
The terminology used herein is defined by that specification except where noted.
The audience for this document is the Java Community Process (JCP) Expert Group that defined the MIDP, implementers of the MIDP, application developers using the MIDP, service providers deploying MIDP applications, and wireless operators deploying the infrastructure to support MIDP devices. This document specifically targets network operators, manufacturers, and service and application providers operating in GSM and UMTS networks.
This addendum is informative. However, all implementations of MIDP 2.0 on GSM/UMTS-compliant devices are expected to comply with this addendum.
MIDP 2.0 defines the framework for authenticating the source of a MIDlet suite and authorizing the MIDlet suite to perform protected functions by granting permissions it may have requested based on the security policy on the device. It also identifies functions that are deemed security-vulnerable and defines permissions for those protected functions. Additionally, MIDP 2.0 specifies the common rules for APIs that can be used together with the MIDP but are specified outside the MIDP. MIDP 2.0 specification does not mandate a single trust model but rather allows the model to accord with the device trust policy.
The purpose of this addendum is to extend the base MIDlet suite security framework defined in MIDP 2.0 and to define the following areas:
This specification is organized as follows:
Sections 2 to 4 establish the relationship between the policy file, different security domains, and requirements concerning certificate storage on smart cards. Section 5 specifies the function groups and identifies the permissions and the APIs that need to be protected using the MIDP 2.0 security framework. Sections 6 and 7 specify rules that must be followed when permissions are granted, and also requirements of user notifications. Finally Section 8 specifies the MIDlet behaviour during roaming and after changing the smart card.
GSM/UMTS-compliant devices MUST follow the security framework specified in the MIDP 2.0. Additionally, devices that support trusted applications MUST follow the PKI-based authentication scheme as defined in MIDP 2.0 specification.
A domain is a way to differentiate between
downloaded MIDlets based on their origin, and to grant or make
available to a MIDlet suite a set of permissions. A domain binds a
root certificate to a set of permissions. The permissions are
specified in the domain policy. A policy file or policy has as many
entries as there are domains available on the device. A domain
can exist only for root certificates that contain the
id-kp-codeSigning extended key usage extension.
Applications that authenticate to a trusted root key are treated as trusted, and assigned to the corresponding protection domain. An application MUST be assigned to only one protection domain. A MIDlet suite cannot belong to more than one protection domain.
The representation of domains in the device is implementation-specific.
This document specifies two different requirements as to how the MIDP permissions framework should be used, depending on the security domain an application executes.
Manufacturer and Operator Domains – Applications are responsible for prompting the user, using the MIDP 2.0 permissions framework when accessing functions for which security policies are specified in Tables 2 through 6 in this document.
Third-Party and Untrusted Domains – The device implementation is responsible for prompting the user according to the security policies specified in Tables 1 through 5 in this document.
The trusted root certificate of the device manufacturer is related to manufacturer applications and MUST have a domain identified in the policy file. If a given device has no Manufacturer domain but is capable of authenticating manufacturer-signed applications (that is, it has a manufacturer root certificate installed) they will be authorized only as untrusted and will belong to the Untrusted domain.
The Manufacturer domain cannot be deleted or modified by the user or any other party, except by a device-provisioned capability. If the manufacturer root certificate is updated, it MUST be mapped onto the same Manufacturer-domain policy file. If the manufacturer root certificate is no longer present on the device, the Manufacturer domain may be removed by a device-provisioned capability.
Permissions in the Manufacturer domain are all marked as Allowed (see MIDP 2.0 for the definition). Permissions granted by the Manufacturer domain as Allowed imply that downloaded and authenticated manufacturer applications perform consistently with applications pre-installed by the manufacturer in terms of security and prompts to the user whenever events that require user acknowledgment occur. Manufacturer applications SHOULD seek permission from the user when accessing security-vulnerable APIs and functions. Permissions defined by MIDP 2.0 and other APIs give the guidelines of which functions are seen as security-vulnerable and need protection. It is expected that manufacturer applications will give prompts and notifications to the user consistently regarding these security-protected functions. The implementation MUST present the user with the Subject field of the root certificate containing the manufacturer root public key whenever a new application is installed in the Manufacturer domain. This user notification MUST take place at application installation.
The Manufacturer domain imposes no restriction on the capabilities specified in the MIDP 2.0 and other JSRs.
The trusted operator root certificate MUST be mapped onto the policy file describing the Operator domain on the device. A device MUST support the policy file describing the Operator domain.
If a given device has no Operator domain but is capable of authenticating operator-signed applications (that is, it is able to obtain an operator root certificate from a smart card) they will be authorized only as untrusted and will belong to the Untrusted domain.
Trusted root certificates are read from the Certificate Directory File (CDF) for trusted certificates [WIM]. Root certificates found in the trustedCertificates file on the WIM are mapped onto the Operator domain or onto the Trusted Third-Party domain, depending on the trustedUsage field in the CommonCertificateAttributes associated with the certificate [PKCS15]:
If the trustedUsage field is present and contains the OID for key usage “Operator Domain” (to be defined), then the certificate is to be mapped onto the Operator domain.
If the trustedUsage field is not present, or does not contain the OID for key usage “Operator Domain,” then the certificate is to be mapped onto the Trusted Third-Party domain.
Operator-trusted root certificates may be placed in the trustedCertificates Certificate Directory File (CDF) of a WIM, SIM, or USIM. If operator root certificates are stored directly on a SIM or USIM, that is, not under the WIM application, then they shall be stored in the EF trustedCertificates CDF located under DF(PKCS#15), as defined by [SCPROV]. Operator root certificates can be obtained only from the trusted CDF or equivalent directory (the card holder can not update this directory) and not from any other directory of the smart card.
As operator root certificates are external to the device itself, and it is not known in advance which root certificates are available for authenticating downloaded operator applications at the time the smart card can be changed, mapping of the operator root certificates onto the Operator domain is implementation-specific. Any operator root certificate MUST, however, be mapped onto the same set of Allowed permissions in the Operator domain. The Operator domain cannot be deleted or modified by the user or any other party, except by a device-provisioned capability.
A signed and authenticated application MUST be authorized to the Operator
domain if the application was authenticated to the operator root public key.
The operator root public key MUST be obtained from the trusted CDF of a currently
inserted and enabled smart card and not from any other location on the smart
card or the device. The implementation MUST present the user with the
Permissions in the Operator domain are all marked as Allowed (see MIDP 2.0 for the definition). Permissions granted by the Operator domain as Allowed imply that downloaded and authenticated operator applications perform consistently with other applications installed by the operator in terms of security and prompts to the user whenever events that require user acknowledgment occur. Operator applications SHOULD seek permission from the user when accessing security-vulnerable APIs and functions. Permissions defined by MIDP 2.0 and other APIs provide guidelines as to which functions are seen as security-vulnerable and need protection. It is expected that operator-trusted applications will give prompts and notifications to the user when accessing these security-protected functions.
The Operator domain imposes no restriction on the capabilities specified in the MIDP 2.0 and other APIs unless stated otherwise.
MIDlets installed in the Operator domain MUST store, along with the application itself, a hash of the root certificate public key under which the signing certificate used to sign the application was issued. The hash algorithm to be used is the following: starting with the root certificate, compute the 20-byte SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits) of that certificate. This method is commonly used to compute key identifiers, especially to accelerate trust-chain building [RFC3280, §4.2.1.2]. The implementation MUST NOT assume for optimization purposes that X.509 key identifiers or PKCS#15 labels are the correct value; however, and MUST compute the hash themselves. This hash MUST be used by the device to decide when a given program should be deactivated, as specified in Section 8.
There is no explicit limitation on the number of domains available in a given device. Applications that authenticate to a trusted third-party root certificate MUST belong to a Third-Party domain. If a given device has no Third-Party domain in the policy file, then a third-party application MUST be authorized and installed only as untrusted and MUST belong to the Untrusted domain.
Third-party root certificates downloaded after device manufacture MUST NOT be used for authentication of MIDlets.
The implementation MUST present the user with the Subjectfield of the signing certificate of a MIDlet whenever a new MIDlet is installed in the Third-Party domain. This user notification MUST take place at MIDlet installation. When the user is prompted to grant permissions to an application, the prompt MUST identify the trusted source with the Subject field of the signing certificate.
The user must be able to delete or disable trusted third-party certificates. If a third-party root certificate is to be deleted, the implementation SHOULD warn the user of the consequence of the deletion adequately. The user MUST be able to enable a disabled third-party root certificate. A disabled third-party root certificate MUST NOT be used to verify downloaded MIDlets. Furthermore, if a third-party root certificate is deleted or disabled (for example, revoked, deleted, or disabled by the user) the Third-Party domain must no longer be associated with this root certificate. If the user chooses to delete the root certificate, implementation may provide an option to delete the applications authenticated to it.
Trusted third-party applications are not granted any permissions Allowed by the Third-Party domain. All permissions granted by the Third-Party domain are User permissions, that is, user interaction is required for permission to be granted. Table 1 specifies the function groups and the available user permission types for applications in the Third-Party domain. Tables 2 through 6 specify the mapping of permissions and APIs onto different function groups.
MIDlets that are unsigned will belong to the Untrusted domain.
The implementation MUST inform the user whenever a new MIDlet is installed in the Untrusted domain. The notification MUST indicate that the application does not come from a trusted source. The user must be able to make an informed decision based on the available information before granting permissions to an application.
When the user is prompted to grant permissions to an application the prompt MUST indicate that the application does not come from a trusted source.
Untrusted applications MUST NOT gain read access directly to PIM data through the API defined in JSR 75 (see Table 1 in Section 5). Interactions between an untrusted application and the PIM data can be enabled, however, by implementations of the javax.microedition.lcdui package: when the application programmer sets the constraint TextField.PHONENUMBER, an implementation of the TextField class MAY propose that the user look up a number in his or her phone book and copy it to the TextField item. For example, when the TextField item has input focus, the user can access a menu to enter the phone book; when the user selects an entry in the phone book, the contents of the selected entry are "copied and pasted" into the TextField item.
Table 1 specifies the function groups and the available user permissions for applications in the Untrusted domain. Tables 2 through 6 specify the mapping of permissions and APIs onto different function groups.
The MIDP 2.0 specification defines the generic format for the policy file that can be read from removable media. GSM/UMTS-compliant devices are not expected to use it in the first phase, but rather to use a single policy file resident on the device. The possibility of remotely located policy files is left for further consideration.
Mapping MIDP 2.0 Permissions onto Function Groups in Protected Domains
A device with a small display may not be able to present all permissions to the user in a single configuration settings menu in a user-friendly manner. Therefore the device is not required to present all individual permissions for user confirmation. Rather, a certain higher-level action triggered by the protected function should be brought to the user for acceptance. The high-level functions presented to the user essentially capture and reflect the actions and consequences of the underlying individual permissions. The function groups are as follows:
Network/cost-related groups:
Phone Call – the group represents permissions to any function that results in a voice call.
Net Access – the group represents permissions to any
function that results in an active network data connection (for
example GSM, GPRS, UMTS, etc…); such functions must be mapped to this
group.
Messaging – the group represents permissions to any function that allows sending or receiving messages (for example, SMS, MMS, etc.)
Application Auto Invocation – the group represents permissions to any function that allows a MIDlet to be invoked automatically (for example, push, timed MIDlets, etc.)
Local Connectivity – the group represents permissions to any function that activates a local port for further connection (for example, COMM port, IrDa, Bluetooth, etc.)
User-privacy-related groups:
Multimedia recording – the group represents permissions to any function that gives a MIDlet the ability to capture still images, or to record video or audio clips.
Read User Data Access – the group represents permissions to any function that gives a MIDlet the ability to read a user's phone book, or any other data in a file or directory.
Write User Data Access – the group represents permissions to any function that gives a MIDlet the ability to add or modify a user's phone book, or any other data in a file or directory.
Whenever new features are added to the MIDP they should be assigned to the appropriate function group. In addition, APIs that are specified elsewhere (that is, in other JSRs) but rely on the MIDP security framework should also be assigned to an appropriate function group. If none of the function groups defined in this section is able to capture the new feature and reflect it to the user adequately, however, then a new function group MUST be defined in this document.
If a new function group is to be added, the following should be taken into consideration: the group to be added MUST not introduce any redundancy to the existing groups, the new group MUST be capable of protecting a wide range of similar features. The latter requirement is to prevent introducing narrowly scoped groups.
It is the function groups and not the individual permissions that should be presented when the user is prompted. Furthermore, it is the function groups that should be presented to the user in the settings of a given MIDlet suite.
Table 1 presents the policy that must be enforced using the security framework as defined in MIDP 2.0. The table specifies the available permission settings for each function group defined. Settings that are effective at the time the MIDlet is invoked for the first time, and remain effective until the user changes them in the MIDlet's configuration menu, are called "default settings." Settings available to the user in the configuration menu, to which the user can change from a default setting, are called "other settings." Together, default and other settings form a pool of available configuration settings for the MIDlet. Default and other settings are presented for each function group and each protection domain. The naming of the function groups is implementation-specific but MUST follow the guidelines of the function-group names defined in this document as well as the definitions of these groups.
Tables 2 through 5 present individual permissions defined in the MIDP 2.0 and other JSRs, and map to the function groups specified in this section. An individual permission MUST occur in only one function group.
It is not mandatory for manufacturer and operator-trusted
applications to adhere to the settings defined in the following
tables, as the necessary user prompts should be given by the
application itself. It is recommended that the manufacturer and
operator-trusted applications adhere to the permission guidelines
provided in the tables, and present appropriate prompts to the user
for the functions identified as security-protected.
Table 1: Function groups and user settings
|
Function group |
Trusted Third-Party domain |
Untrusted domain |
||
|
Phone Call |
default setting |
Oneshot |
default setting |
Oneshot |
|
other settings |
No |
other settings |
No |
|
|
Net Access |
default setting |
Session |
default setting |
Session |
|
other settings |
Blanket, No |
other settings |
No |
|
|
Messaging |
default setting |
Oneshot |
default setting |
Oneshot |
|
other settings |
No |
other settings |
No |
|
|
Application Auto Invocation |
default setting |
Oneshot |
default setting |
Oneshot |
|
other settings |
Blanket, No |
other settings |
No |
|
|
Local Connectivity |
default setting |
Session |
default setting |
Session |
|
other settings |
Blanket, No |
other settings |
Blanket, No |
|
|
Multimedia recording |
default setting |
Session |
default setting |
Oneshot |
|
other settings |
Blanket, No |
other settings |
Session, No |
|
|
Read User Data Access |
default setting |
Oneshot |
default setting |
No |
|
other settings |
Session, Blanket, No |
other settings |
No |
|
|
Write User Data Access |
default setting |
Oneshot |
default setting |
Oneshot |
|
other settings |
Session, Blanket, No |
other settings |
No |
|
The device MAY enhance and simplify the user experience by applying a single set of configuration settings (default or other), not just to a single MIDlet, but to all MIDlets for a given signer. This option MUST NOT compromise the function groups and available settings defined in Table 1. If such an option exists, the user will be prompted to save the settings and reuse them in future for applications from the same source. Such a feature MAY also inform the user that a given source has already been accepted and has an alias to the saved configuration settings.
For each trusted or untrusted application, the implementation MAY read requested permissions from the MIDlet-Permissions and MIDlet-PermissionsOpt attributes, notify the user which capability the application requires, and prompt the user to accept or reject installation of the application.
Note: For applications in the Third-Party or the Untrusted domain, if any of the groups Net Access,
Messaging, and Local Connectivity has a Blanket permission, neither
Multimedia recording nor Read User Data Access can have a Blanket
permission, and vice versa. This restriction is to ensure that
a MIDlet cannot activate both network connectivity and
user-privacy-related functions without user consent.
Similarly,
the Blanket setting for Application Auto Invocation and the Blanket
setting for Net Access are mutually exclusive. This constraint is to
prevent an application from auto-invoking itself, then accessing a
chargeable network without the user being aware.
In the event that Net Access is given Blanket permission in any of these combinations of permissions, it MUST be downgraded to Session permission.
For each Phone Call and Messaging action, the implementation MUST present the user with the destination phone number before the user approves the action. For the Messaging group, if the implementation maps a single API call to more than one message (that is, the implementation supports disassembly/reassembly), the implementation MUST present the user with the number of messages that will actually be sent out. This requirement is to ensure that the user always understands the network costs associated with running the program, whatever API calls are involved.
Table 2: Assigning permissions specified in MIDP 2.0 to function groups
|
MIDP 2.0 – JSR 118 |
||
|
Permission |
Protocol |
Function group |
|
javax.microedition.io.Connector.http |
http |
Net Access |
|
javax.microedition.io.Connector.https |
https |
Net Access |
|
javax.microedition.io.Connector.datagram |
datagram |
Net Access |
|
javax.microedition.io.Connector.datagramreceiver |
datagram server (without host) |
Net Access |
|
javax.microedition.io.Connector.socket |
socket |
Net Access |
|
javax.microedition.io.Connector.serversocket |
server socket (without host) |
Net Access |
|
javax.microedition.io.Connector.ssl |
ssl |
Net Access |
|
javax.microedition.io.Connector.comm |
comm |
Local Connectivity |
Table 3: Assigning proposed permissions and
API calls specified in the Personal Information Management Package of
the PDA Profile to function groups
Editor’s Note: The current PIM API package does not specify a write-only API. The necessary permissions to protect the PIM API are not specified in the PIM package either. This table will be updated once these changes are incorporated into the PIM API package.
|
PDAP PIM Package API (JSR75) |
||
|
Policy File Identifier |
Permitted Java API Calls |
Function group |
|
javax.microedition.pim.PIM. |
PIM.listContactLists() |
Read User Data Access |
|
javax.microedition.pim.PIM. |
PIM.listContactLists() |
Write User Data Access |
|
javax.microedition.pim.PIM. |
PIM.listEventLists() |
Read User Data Access |
|
javax.microedition.pim.PIM. |
PIM.listEventLists() |
Write User Data Access |
|
javax.microedition.pim.PIM. |
PIM.listToDoLists() |
Read User Data Access |
|
javax.microedition.pim.PIM. |
PIM.listToDoLists() |
Write User Data Access |
Implementation MUST ensure that the user is informed of the nature of user data an application has access to (for instance, events or to-do lists) before allowing the application access to these functions. Whenever a MIDlet adds a new PIM entry, the implementation MUST display it to the user for acknowledgement.
Table 4: Assigning proposed permissions and API calls specified in the Bluetooth API to function groups
|
Bluetooth API– JSR 82 |
||
|
Policy File Identifiers (Proposed Permission) |
Permitted API calls |
Function group |
|
javax.microedition.io.Connector.bluetooth.client |
Connector.open(“btspp://<server
BD_ADDR>…”) |
Local Connectivity |
|
javax.microedition.io.Connector.obex.client |
Connector.open(“btgoep://<server
BD_ADDR>…”) |
Local Connectivity |
|
javax.microedition.io.Connector.obex.client.tcp |
Connector.open(“tcpobex://<server IP_ADDR>…”) |
Net Access |
|
javax.microedition.io.Connector.bluetooth.server |
Connector.open(“btspp://localhost:…”) |
Local Connectivity |
|
javax.microedition.io.Connector.obex.server |
Connector.open(“btgoep://localhost:…”) |
Local Connectivity |
|
javax.microedition.io.Connector.obex.server.tcp > |
Connector.open(“tcpobex://:<PORT>”) |
Net Access |
|
javax.microedition.io.PushRegistry.bluetooth.server |
PushRegistry.registerConnection(“btspp://<server
BD_ADDR>:<channel ID>”) |
Application Auto Invocation |
|
javax.microedition.io.PushRegistry.obex.server |
PushRegistry.registerConnection(“btgoep://<server BD_ADDR>:<channel ID>”) PushRegistry.registerConnection(“irdaobex://???…”) |
Application Auto Invocation |
|
javax.microedition.io.PushRegistry.obex.server.tcp |
PushRegistry.registerConnection(“tcpobex://:<PORT>”) |
Application Auto Invocation |
Note: The permissions proposed for Bluetooth API are yet to be defined in JSR82.
Table 5: Assigning proposed permissions and API calls specified in the Wireless Messaging API to function groups
|
Wireless Messaging API – JSR 120 |
||
|
Policy File Identifier (Proposed Permission) |
Permitted API calls |
Function group |
|
javax.microedition.io.Connector.sms.send |
Connector.open("sms://…", WRITE) |
Messaging |
|
javax.microedition.io.Connector.sms.receive |
Connector.open("sms://…", READ) |
Messaging |
|
javax.microedition.io.Connector.sms |
Connector.open("sms://…") |
Messaging |
|
javax.microedition.io.Connector.cbs.receive |
Connector.open("cbs://…") |
Messaging |
Note: The permissions for Wireless Messaging API are yet to be defined in JSR120.
Table 6: Assigning proposed permissions and API calls specified in the Mobile Media API to function groups
|
Mobile Media API–JSR 135 |
||
|
Policy File Identifiers (Proposed Permissions) |
Permitted API calls |
Function group |
|
javax.microedition.media.RecordControl.startRecord |
RecordControl.startRecord ( ) |
Multimedia recording |
|
javax.microedition.media.VideoControl.getSnapshot |
VideoControl.getSnapshot (…) |
Multimedia recording |
Note: The permissions for Mobile Media API are yet to be defined in JSR135.
Implementations MUST ensure that I/O access from the Mobile Media API follows the same security requirements as the Generic Connection Framework, as specified in the package documentation for javax.microedition.io. Example methods include javax.microedition.media.Player.start, javax.microedition.media.Player.prefetch, etc. When these methods are used to fetch the content for the player via an HTTP connection, the implementation MUST enforce the security requirements specified for HTTP.
When the user grants permission to a function group, this action effectively grants access to all individual permissions under this function group to which a MIDlet was authorized. This MUST not include all the individual permissions from the group. For example, if a MIDlet was authorized to make an HTTP connection and was not authorized to access any other protected functions from the Net Access group, Blanket permission to a Net Access means permission to make HTTP connections only. Individual permissions that were not granted to the MIDlet by the MIDP authorization framework will not be granted by a user allowing Net Access, as function groups are served for the user representation only.
Implementation notes:
An implementation MUST guarantee that a Security exception is thrown when the caller does not have the appropriate security permissions.
If a messaging group is granted a Oneshot
permission, it translates into a Blanket permission for
javax.microedition.io.Connector.sms and
javax.microedition.io.Connector.cbs, as well as to permissions that
enable receiving the messages. Permission for sending the
messages is still Oneshot, however; that is, the user grants
permission to each message sent out by the MIDlet within an open
connection. The
same applies to the Session permission: functions related to sending
the messages get Session permission, but other functions get Blanket
permission."
Blanket permission and No permission granted to the Messaging group
apply to all individual permissions under this group.
If a MIDlet uses the capabilities defined in MIDP and other APIs, the following rules MUST apply:
As defined in the "Security for MIDP Applications" section of the MIDP 2.0 specification, MIDlet suite permissions are effectively the intersection of the domain permissions Midlet-Permission and Midlet-Permission-Opt found in the JAR manifest. The way in which a MIDlet's granted permissions are presented to the user is implementation-specific, but the following rules must apply:
A device MUST maintain security-related data for each installed MIDlet, in addition to generic MIDlet information such as MIDlet name and version number. The data MUST include at least the following:
A device MUST be able to present information related to the application signer in a user-friendly manner.
The following rules MUST be followed in order to ensure informed user consent to MIDlet actions:
All previously authorized and installed MIDlets MUST act in accordance with the device policy when the device is roaming, or when the device smart card is changed. Newly downloaded MIDlets are authenticated to the root certificates currently available in the certificate store and are authorized in accordance with the device policy.
If device roaming or a smart-card change causes failure to access network resources that the MIDlet was previously authorized to access, then the implementation MUST NOT throw a SecurityException. This failure is not related to MIDlet authorization, so the implementation MUST throw an IOException instead.
The permissions assigned to MIDlets installed in the Manufacturer, Trusted Third-Party, and Untrusted domains are not affected by changes of the (U)ICC [(U)ICC], but MIDlets installed in the Operator domain MUST NOT execute if, after a smart-card change, the SIM no longer holds the certificate containing the operator root public key that was used to authenticate the MIDlet to the Operator domain (the "authenticating root"; see Section 3.2, "Operator Domain").
Whether a MIDlet in the Operator domain can be executed depends on a comparison of "root key hash" values, computed as the 20-byte SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits) of a root certificate. The decision process SHOULD follow the following mechanism:
Note: In this mechanism, there are two steps the device performs after the smart card has been changed: 1) computing the new Operator-domain root key hashes; 2) for each MIDlet in the Operator domain, checking whether its authenticating root key hash belongs to the set of new Operator-domain root key hashes. An implementation MAY perform these two steps at any time, provided NO Operator-domain MIDlet is executed after a smart card change if its authenticating root key hash does NOT correspond to one of the new Operator-domain root key hashes. Step 2 MAY be performed right after Step 1; alternatively, Steps 1 and 2 MAY be separated in time, in which case the implementation SHOULD store the results of Step 1 securely so they will be available in Step 2.
If the Operator-domain root certificate is not present at the specified location, the user MUST be informed that the application cannot be executed without the authorizing root certificate. The device SHOULD also give the user the option to get information on the root certificate that was used to authenticate the application to the Operator domain. This information SHOULD include the Subject field of the root certificate.
Although it is mandatory only to check whether authenticating roots are still present in the smart card when the smart card is changed, an implementation MAY choose to check on more occasions and, accordingly, to disable applications in the Operator domain as specified.
If a MIDlet cannot be executed because the authenticating Operator root public key is absent, the device MUST NOT delete the application. The device MAY inform the user in advance via an appropriate mechanism whether an application could execute or not, for example using a "disabled" look-and-feel in the display. However, the user MUST be able to delete these disabled applications.