Legacy Compatibility for Previous Versions

Overview

Several new features in MEEP 8 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.

Underlying Configuration

IMP-1.0 applications require CLDC 1.0 as underlying configuration, that's why the Microedition-Configuration attribute as used in the JAD and JAR manifest MUST have the value "CLDC-1.0" for IMP-1.0 applications (while for MEEP applications the vlaue has to be the same as defined in microedition.configuration system property). Otherwise the installation MUST fail.

IMP-NG applications require CLDC 1.0 or CLDC 1.1 as underlying configuration, that's why the Microedition-Configuration attribute as used in the JAD and JAR manifest MUST have the value "CLDC-1.0" or "CLDC-1.1" for IMP-NG applications (while for MEEP applications the vlaue has to be the same as defined in microedition.configuration system property). Otherwise the installation MUST fail.

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.

As MEEP runs on top of CLDC 8, calls to System.getProperty() require a granted java.lang.PropertyPermission via the MIDlet-Permission-<n> JAR/manifest attribute in order to be performed successfully. Otherwise a SecurityException would be thrown. IMP applications run per definitionem on CLDC 1.1 or below, where no permission was required for that. In order to maintain compatibility, implementations therefore MAY add appropriate PropertyPermissions into security policies and MAY assume that those are implicitly requested by legacy application suites having CLDC-1.1 or below as the value of their Microedition-Configuration attribute.

Legacy applications may require the javax.microedition.midlet.MIDlet.install permission that is defined in IMP-NG. As this permission is unknown in MEEP, Security Policy Providers MUST ignore this request if it appears in legacy application suites. This is an explicit exception from the rule that "if any of the requested critical permissions are unknown to the device, then the application suite MUST NOT be installed." as it is defined in the Security for Applications Chapter.

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 an IMP-NG like security domain. The Security Policy File 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 are allowed to not explicitly request permissions explicitly in the JAR manifest or application descriptor. The Security Policy Provider SHALL therefore assume that Untrusted IMP 1.0 application suites implicitly request all permissions allowed in the protection domain of the Untrusted Client. Note though that this rule does not apply but to MEEP Untrusted application suites.

Security for IMP-NG Application Suites

IMP-NG defined the domain security model based on Named Permissions.

MEEP 8 introduces the concepts of Authentication Providers and Security Policy Providers. Those concepts are generalizations of well-known concepts in IMP-NG.

The Application Suites Trust Model Using X.509 PKI as used in IMP-NG is the default implementation of an Authorization Provider, and for the necessary compatibility to run IMP-NG applications, a MEEP 8 implementation must use this default instead of using an alternative definition. The Protection Domains as defined in IMP-NG are similar to the Client Protection Domains as defined in MEEP 8.

The Certificate-Based Security Policy as used in IMP-NG is the default implementation of an Security Policy Provider, and for the necessary compatibility to run IMP-NG applications, a MEEP 8 implementation must use this default instead of using an alternative definition.

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 are allowed to not request permissions explicitly in the JAR manifest or application descriptor. The Security Policy Provider SHALL therefore assume that Untrusted IMP-NG application suites implicitly request all permissions allowed in the protection domain of the Untrusted Client. Note though that this rule does not apply but to MEEP Untrusted application suites.

The handling of permission attributes is similar to the one for MEEP 8 applications as described in the Security for Applications chapter.

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", it is enough if each of the following attributes is present in either the application descriptor or JAR manifest:

The installation MUST NOT fail because one of these attributes appears only in one of the both, application descriptor and JAR manifest.

Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.