Legacy Compatibility for Previous Versions

Overview

Several new features in MEEP-1.0 require some level of adaptation to retain backward compatibility with IMP-1.0 and IMP-NG. This chapter defines these areas of adaptation, the requirements placed on implementations to accommodate legacy content, and the behaviors that legacy content can expect when running in a this environment.

Security Compatibility for Previous Versions

The IMP 1.0 specification constrained each application suite to operate in a sandbox wherein all of the APIs available to the applications would control access to sensitive APIs or functions of the device. The IMP 1.0 Security section below specifies the security related behaviors of IMP 1.0 IMlet suites that are identified with the attribute and value MicroEdition-Profile: IMP-1.0.

IMP-NG introduced the concept of trusted applications that are permitted to use APIs that are considered sensitive and are restricted by device policy. If and when a device determines that an application suite can be trusted, then access is allowed as indicated by the domain policy. The IMP-NG Security section below specifies the security related behaviors of application suites that are identified with the attribute and value MicroEdition-Profile: IMP-NG.

Security for IMP 1.0 Application Suites

Every IMP 1.0 compliant application suite MUST be able to run as an untrusted application suite. The sandbox concept defined in those ME profile versions mapped to a security domain. The Security Policy Chapter defines the policy for untrusted application suites. Every implementation of this specification MUST support running untrusted application suites.

For backward compatibility, IMP 1.0 Untrusted application suites do not request permissions explicitly in the JAR manifest or application descriptor; permissions are granted according to the policy for untrusted applications.

Security for IMP-NG Application Suites

IMP-NG defined the domain security model based on Named Permissions. Each permission, if requested and granted, enables access to an API or function. Named Permissions have a hierarchical organization similar to Java package names. The names of permissions are case sensitive. If the permission is for a function of a specific class in the package, then the permission name MUST include the package and classname. The set of valid characters for permission names is the same as that for package and class names. The conventions for use of capitalization in package names SHOULD be used for permission names. For example, javax.microedition.io. Following the permission name, whether by package or class, additional modifiers may be appended with a separator of "." (Unicode U+002E).

For backward compatibility, IMP-NG Untrusted application suites do not request permissions explicitly in the JAR manifest or application descriptor; permissions are granted according to the policy for untrusted applications.

For each application suite that is identified with the attribute and value MicroEdition-Profile: IMP-NG, the following permission attribute processing rules apply :

Named Permission to Class Permission Mapping

The Configuration ([CLDC] defines the Permission classes that allow access to networking protocols in the Generic Connection Framework.

Table 9-1 : Named Permission to Class Permission Mapping

Named Permission

Permission

javax.microedition.io.Connector.socket

javax.microedition.io.
SocketProtocolPermission(“socket://*:*”)

javax.microedition.io.Connector.serversocket

javax.microedition.io.
SocketProtocolPermission(“socket://:*”)

javax.microedition.io.Connector.http

javax.microedition.io.
HttpProtocolPermission(“http://*:*”)

javax.microedition.io.Connector.https

javax.microedition.io.
HttpsProtocolPermission(“https://*:*”)

javax.microedition.io.Connector.ssl

javax.microedition.io.
SSLProtocolPermission(“ssl://*:*”)

javax.microedition.io.Connector.datagram

javax.microedition.io.
DatagramProtocolPermission(“datagram://*:*”)

javax.microedition.io.Connector.datagramreceiver

javax.microedition.io.
DatagramProtocolPermission(“datagram://:*”)

javax.microedition.io.Connector.comm

javax.microedition.io.
CommProtocolPermission(“comm:*”)

javax.microedition.io.PushRegistry

javax.microedition.io.
PushRegistryPermission (“*”, “static,dynamic,alarm”)

Example Mapping Named Permissions to Class Permissions

For example, if the application attributes for an IMP-NG application suite included the following :


    MicroEdition-Configuration: CLDC-1.1
    MicroEdition-Profile: IMP-NG
    MIDlet-Permissions: javax.microedition.io.Connector.http,
                        javax.microedition.io.Connector.https
            

The security mechanisms and policy are evaluated as specified in Granting Permissions to Application Suites using the equivalent permissions as if the application attributes were :


    MicroEdition-Configuration: CLDC-8
    MicroEdition-Profile: MEEP-1.0
    MIDlet-Permission-1: javax.microedition.io.HttpPermission "http://*:*"
    MIDlet-Permission-2: javax.microedition.io.HttpsPermission "https://*:*"
            

Recommendation for Permissions for Optional Packages

Each API that provides access to a protected function defines the needed Permissions. For APIs defined outside of this specification there must be a single document that specifies the permissions and the behavior of the API when it is implemented on IMP-NG. Optional package specifications must also specify the mapping from IMP-NG named permissions to the corresponding Permissions.

JAR Signature

For each application suite that is identified with the attribute and value Microedition-Profile: IMP-NG the following rules apply when processing the signature attributes:

Attribute Overrides in Application Descriptor

When installing an application suite with the attribute Microedition-Profile equal to "IMP-NG" that is a Trusted Application Suite the value of each attribute that appears in both the manifest and application descriptor MUST be identical. If not identical, the installation MUST fail and return Status Code 905 (Attribute Mismatch) in the Status Report.

For Untrusted Application Suites, including those with Microedition-Profile equal to "IMP-1.0", or "IMP-NG" the value of an attribute that appears in the application descriptor overrides the corresponding attribute value, if any, in the manifest. The value used and returned by the MIDlet.getAppProperty method will be the value from the application descriptor, otherwise the value, if any from the manifest is used.

The following attributes MUST have identical values if they appear in both the application descriptor and JAR manifest for all IMP 1.0, and IMP-NG application suites. If not identical, the installation MUST fail and return Status Code 905 (Attribute Mismatch) in the Status Report.

When installing an application suite with the attribute Microedition-Profile equal to "IMP-1.0", or "IMP-NG" installation MUST NOT fail due to the absence of the attributes below as long as each attribute is present in either the application descriptor or JAR manifest :

Application Attributes Compatibility

Some of the application attributes defined in Table A-1 : Application Descriptor Attributes are also defined in earlier versions.

For each application suite that is identified with the attribute and value Microedition-Profile: IMP-NG in the JAD or JAR Manifest, if the following attributes also are present, and any of the attribute values contain are new definitions in this specification, then installation MUST fail and return Status Code 905 (Attribute Mismatch) in the Status Report.

Table 9-2 : Application Attribute Compatibility

Attribute Name

IMP-NG Allowed Values

Allowed Values

MIDlet-<n>

The name, icon and class of the nth application in the JAR file, separated by a comma.

The name and class of the nth application in the JAR, separated by a comma.