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.
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.
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.
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.
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.
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:
If there exists one or more instances of the
MIDlet-Jar-RSA-SHA1-<n>
attribute in the JAD, then any instances of MIDlet-Jar-RSA-SHA1
MUST be ignored.
If there exist no instances of MIDlet-Jar-RSA-SHA1-<n>
attribute in the
JAD, then the IMP-NG specific attribute
MIDlet-Jar-RSA-SHA1: <Base64 encoding of Jar signature>
MUST be processed when it appears in the JAD. If the application
descriptor contains more
than one certificate chain, all the signing certificates in
the application descriptor
are assumed to contain the same public key.
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.
Microedition-ProfileMicroedition-Configuration
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:
Microedition-ProfileMicroedition-ConfigurationMIDlet-<n>Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.